So im doing some graph drawing using GL_LINE_STRIP's and i am using a multisampled buffer so the lines dont look so jagged. the problem is i have some lines in the background of the graph that act as a legend. The multisampling kind of screws the lines up cause they are meant to be exactly 1 pixel thick, but because of the multisampling, it will sometimes put the line spread over 2 pixels that are slightly dimmer than the original colour, making the lines look different to each other.
Is it possible to render those legend lines directly to the resolved frame buffer, then have the multisampled stuff drawn on top? this will effectively not multisample the background legend lines, but multisample the graph lines.
Is this possible? I just want to know before i dive into this and later find out you cant do this. If you have some demo code to show me that would be great as well
It would be much easier if the legend came last: You could just resolve the MSAA buffers into the view framebuffer and then normally render the legend into the resolved buffer afterwards. But the other way won't be possible, since multisample resolution will just overwrite any previous contents of the target framebuffer, it won't do any blending or depth testing.
The only way to actually render the MSAA stuff on top yould be to first resolve them into another FBO and draw that FBO's texture on top of the legend. But for the legend to not get completely overwritten, you will have to use alpha blending. So you basically clear the MSAA buffers to an alpha of 0 before rendering, then render the graph into it. Then you resolve those buffers and draw the resulting texture on top of the legend, using alpha blending to only overwrite the parts where the graph was actually drawn.
Related
I have issue setting up an Openlayers map with vector tiles served from Geoserver. The lines gets screwed up along the edges of the tiles. It looks like the lines are first clipped and then styled instead of the opposite. This makes wide lines look ugly.
Changing the renderBuffer in the OL client doesnt make any difference.
I have similar issues with labels and perhaps the solution is pretty much the same in both cases.
EDIT: The geojson in QGIS shows that there is a buffer around the tiles:
geojson output in QGIS
EDIT 2: I have been doing som more research on the phenomenom and I think both Geoserver and Openlayers are to blame for the artifacts. As seen below, Geoserver does render with a buffer (the pink polygons(1 and 2) contains the black bordered tile extent) but does not include features that lies outside of the tile but inside of the buffer, like the green line(3) in the circle.
That makes the tile rendered with a jack as in the left circle below.
However, even when you have a line in a tile that goes close to the tile border, styled with quite a thick stroke, Openlayers wont render enough of the line outside the tile to make it styled without a jack. Like the right circle below. I have mote obvious examples of that bahviour. This could probably easily be fixed by setting a higher buffer/tolerance value for the tilerendering.
Question is in the title:
[ActionScript3.0] How to get color (uint) of pixel at coordinates? (Stage3D, Flare3D)
I am using Flare3D library to render 3D scene on an iPad2. I need to get color values at 768 different coordinates every time screen is redrawn. Previously, on simple stage (2D), I could just draw it on 1x1 bitmaps translated to specified coordinates, now it does not work on stage3D. Plus, I am a bit worried weather it will kill the performance since I really need to do it as often as possible - actually every time screen is drawn.
It would be really nice if that currently displayed screen was like a bitmap somewhere, so I could access it like simple array...but yeah, I am not holding my breath:)
Since Stage3D renders to back-buffer and one can't directly access it, you also need to render to BitmapData using Context3D.drawToBitmapData() method. Rendering to a bitmap is very slow, especially if the viewport is large. As you only need to access those 768 pixels, you could use Context3D.setScissorRectangle to render scene 768 times with the size of scissor rectangle set to 1x1 along with needed coordinates. I haven't tested that myself so I don't know if rendering scene 700 times won`t be slower than rendering it once, but you may want to try that. :)
I'm drawing some cars. They're Bitmap's, loaded from PNG's in the library. I need to be able to color the cars-- red ones and green ones and blue ones, whatever. However, when you paint the car green, the tires should stay black, and the windows stay window-color.
I know of two ways to handle this, neither one of which makes me happy. First, I could have two bitmaps for each car; one underneath for the body color, and one on top for detail bits. The underneath bitmap gets its transform.colorTransform set to turn the white car-body into whatever color I need. Not great, because I end up with twice as many Bitmap's running around on screen at runtime.
Second, I could programmatically search-and-replace "white" with "car-body" color when I load the bitmap for each car. Not great either, because the amount of memory I take up multiplies by however many colors I need.
What I would LIKE would be a way to say "draw this Bitmap with JUST THE WHITE PARTS turned into this other color" at runtime. Is there anything like this available? I will be less than surprised if the answer is "no," but I figure it's worth asking.
You might have answered the question yourself.
I think your first approach would need only two transparent images: one with pixels of the parts that need to change colour, one with the rest of the image. You will use colorTransform or ColorMatrix filter by case. It might even work with having the pixels the need the colour change covered with Sprite with a flat colour set on overlay ?
The downside would be that you will need to create a 'colour map'/set of pixels to replace for each different item that will need colour replacement.
For the second approach:
You might isolate the areas using something like threshold().
For speed, you might want either to store the indices of the pixels you need to replace in an Vector.<int> object that could be used in conjuction with BitmapData's getVector() method. (You would loop once to fetch the pixel indices that need to be replaced)
Since you will use the same image(same dimensions) to fill the same content with a different colour, you'll always loop through the same pixels. Also keep in mind that you will gain a bit of speed by using lock() before your loop to setPixel() and unlock() after the loop.
Alternatively you could use Pixel Bender and try some green screen/background subtraction techniques. It should be fast and wouldn't delay the execution of the rest of your as3 code as Pixel Bender code runs in it's own thread.
Also check out Lee's Pixel Bender subtraction technique too.
Although it's a bit old now, you can use some knowledge from #Quasimondo's article too.
HTH
I'm a little confused where you see the difference between your second approach and the one you would like to have. You can go over your loaded bitmap pixel by pixel and read out the color. If it turns out to be white replace it with another color. I do not see occurence of multiplied memory consumption.
You might want to try my selective color transform: http://www.quasimondo.com/archives/000614.php - it's from 2006, so some parts of it could probably be replaced by a pixel bender filter now.
Why not just load the pieces separately, perform the color transform on the one you want to change, then do a BitmapData.copyPixels() with the result? The blit routine runs in machine code, so is wicked fast. Doing it pixel by pixel in ActionScript would be glacially slow in comparison.
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display/BitmapData.html#copyPixels()
I am trying to cut a mesh in half or at least be able to delete faces from it in real-time.
How to go about doing this i wonder?
Lock the vertex buffers, memset the selected face or vertex to 0, does not work for me.
has anyone a solution or a tutorial on this i really want this feature in my program!
Cheers
Oh - that one is easy. There is no need to modify the mesh. D3D can already do this for you!
Set the clip-plane via IDirect3DDevice9::SetClipPlane, then enable the plane via the D3DRS_CLIPPLANEENABLE renderstate. You can even set multiple clip-planes at the same time if you want to..
Here is a link to the msdn-entry: http://doc.51windows.net/Directx9_SDK/?url=/directx9_sdk/graphics/reference/d3d/interfaces/idirect3ddevice9/setclipplane.htm
And if you do a google search on "D3D SetClipPlane" you will find lots of discussions and example codes how to use it.
If you need to dynamically delete triangles from a mesh the best/fastest way is to use indexed triangles. When you create the index buffer, use the 'D3DUSAGE_DYNAMIC' flag. When you want to delete triangles, lock it with the 'D3DLOCK_DISCARD' flag. Write the entire new list of indices into the buffer, leaving out the triangles you want to delete.
The index buffer will be much smaller than the vertex buffer, so re-uploading only indices won't be as much of a drag on the system as the vertex buffer would be. But if it would be a big problem for you to convert to indexed triangle lists, then doing these stame operations using the vertex buffer instead is probably your next best option.
You say that setting the vertex to 0 doesn't work. In what way doesn't it work?
If you set the position of all the verticies of a triangle to (0.0, 0.0, 0.0) then the resulting triangle will be of zero size and shouldn't be drawn. Just to be sure you could set it to an offscreen position instead of zero.
Imagine you are drawing a map of county borders. You are given a set of polygons, one for each boundary, and you draw each polygon.
In places where two counties share a border you just end up drawing the border twice. In the absence of partial transparency effects, and with a solid pen, this is no problem.
But, on maps, borders of this kind are customarily shown by dash-dotted lines. In this case, situations like the one depicted below can happen:
Notice how the dash pattern, which normally is dash-dot-dot, gets screwed up where the two areas share a border. In this case, it happened to become a longdash-dot pattern, but in general it could do anything from coincidentally looking normal to creating a solid line.
How does/should map rendering software prevent artifacts of this kind from occuring?
The artifact is due the fact that the piece of border is drawn twice. Instead of trying to supress such artifacts, you could try to not draw border sections twice, by keeping a list of segments already drawn in memory, and if you encounter a stretch that's already drawn, you don't draw it again.
Your brush pattern colors some pixels black and leaves some pixels alone. Instead of leaving the pixel alone, can you set up your brush pattern to color those pixels white (or whatever your background color is)?
Another possibility is to always draw your county borders twice -- once with a solid white pattern, and again with the brush pattern of your choice.
I suppose they break their border lines into segments, then remove the overlaps.
This is mostly a geometric problem, not a drawing problem.
Instead of going with a dashed line, you could do it Zip-a-tone style, like this:
Zip-a-tone was this graphic art stuff that was basically a sticky sheet of plastic with a regular (printable) pattern of dots on it. To use it, you would lay a big sheet of it over your drawing and cut it around the areas on your drawing that you wanted zip-a-toned, and then peel off the parts you didn't want.
For this image, I just went with an alternating checkerboard pattern, with the lines two pixels wide. Because all the lines are drawn from one big (virtual) block of this checkerboard pattern, you never have to worry about weird artifacts at the joints or any overlap effects.
Angled lines are a bit tricky, but basically you imagine the edges of the line sort of cutting through pixels, and thus you draw them at the appropriate shade of grade instead of full black (in the case of the 45 degree line here, the pixels are drawn with RGB(170, 170, 170), but any angle could be rendered with appropriate shades).
I'm not sure if GDI+ could do this easily using the textured brushes, but maybe. Otherwise you'd have to custom-code it. The advantage of this method over just solid gray lines would be that this would allow some of the background to show through.
This is an interesting question that I never really thought about. I think the only real solution is to render the entire complex figure as a series of lines or paths that do not overlap anywhere. I'm not surprised that GDI+ doesn't handle this situation in any automatic way.