I'm on an OpenGL project.
I have some objects (just say 2) made of the same transparent material (alpha = 0.2, for example). The two objects intersect.
How can I make the intersection part look the same as other part (without border, no different color), so the too objects will look like as one?
I'm not sure if you would really want to do it. I will answer anyway, but first let me tell you why I think you don't want that.
In real life, imagine a red stained glass and a blue one. If you look at them in a way that they partially overlap, the overlapping part clearly has a different color (purple). If you get 2 red glasses and look at them so that they have overlap, the overlapping part is more red. That's exactly what is happening in your OpenGL program.
Now in general, when you have multiple transparent objects, you need to sort them based on their distance from your eye and the direction you are looking at. Then you draw them from farthest to closest. This is not a simple task by itself! Think of 2 objects that cross.
One way of achieving what you want is to sort the transparent objects, but draw from closest object to the farthest. This way, you practically don't allow transparency on the same pixel to be done twice. Not a good idea.
Another way would be to do something very specific to these objects of special kind. I say special kind because apparently two of them overlapping doesn't make any changes! You can do what you want by drawing to the stencil buffer instead of the draw buffer, then draw a rectangle with the color you want over the whole screen, but matching only that stencil.
Related
In the image above, the trees are drawn in a batch and I'm trying to draw the small tree in front of the bigger tree using its z position and regardless of the order they are added for drawing. I'm also using an orthographic projection.
Unfortunately, I'm using an unknown game engine where the devs are either inactive or just doesn't care that's why I'm hoping someone here can help but the gist is this:
start batch drawing
draw small tree at location: x, y, 1 // 1 to make it appear in front
draw big tree at location: x, y, 0
end batch drawing
In an OpenGL / glsl application, what are the things to do in general to make something like this work?
I've already tried the equivalent of
glEnable( GL_BLEND );
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
The problem you seem to be having is the difference between "drawn with non-opaque alpha values" and "actually being transparent".
OpenGL (and most other simple alpha-based rendering techniques) cannot do the kind of transparency where drawing behind an already drawn element makes part of the newly drawn element (partially) visible.
The color of any newly-drawn, non-opaque pixel is a mixture of its own color and the color already on that place. I.e. only two input values exist.
The mixture is controlled by the alpha value of the newly drawn pixel.
The color "already on that place" has lost information on involved colors and alpha values.
The problem visible in your picutre is caused by the fact that in addition to the alpha-controlled mixture there is also the z-controlled influence of other elements closer to the observer. Alpha values do not influence that mixture, the foremost elements simply wins. And this includes the partially, or even fully "transparent" parts of those closer elements, which have already been drawn (with or without allpha influence).
So the gist of this is, as mentioned in comments already,
with the simple alpha-rendering mechanisms, you have to sort rendering chronologically by distance.
I guess my second comment is not clear. I've already found the problem and it's solution.
Problem: the alpha is not discarded in the fragment shader
Solution:
if(gl_FragColor.a < 0.5)
discard;
I don't know if it's the best solution but it's enough for pixel art sprites.
Thank you everyone for your time.
Background:
I am creating a game that presents the world in an isometric perspective, achieved by drawing isometric tiles. My current implementation is naive, using the painter's method, drawing from back to front, from bottom to top, using surface blits from tile images.
The Problem:
I'm concerned (maybe unduly so, please let me know if this is the case) about overdraw. Here's a small snapshot of a single layer of tiles:
The areas hi-lit in pink are the areas where the back-to-front, bottom-to-top method blits pixels to the canvas more than once. This is a small and contrived example, but in practice I hope to accomplish something more along the lines of this:
(image credit eBoy)
With an image as complex as this, and a tile-based implementation, each screen pixel is drawn to several times before the final image is composited, which feels like it's really inefficient. Since these are just 2D images with, in the end, one-bit alpha masks, there aren't as many concerns as there would be with 3D (e.g. no wasted lighting or transform math) but it still seems there should be a more elegant way of determining whether a pixel should be drawn or not based on whether or not it would be occluded in the final composition.
Solutions?
The best solution I've come up with so far is to:
Reverse the drawing order and draw front-to-back, top-to-bottom.
Keep a single bit per pixel fake z buffer that records whether or not a pixel has been drawn yet.
Only draw a tile if some of the pixels it covers haven't been drawn yet.
Is there a better way to do this? Are blit operations superefficient and I'm tilting at windmills here?
Windmills. Especially if you're using OpenGL-accelerated SDL2 blits.
Where can I get an algorithm to render filled triangles? Edit3: I cant use OpenGL for rendering it. I need the per-pixel algorithm for this.
My goal is to render a regular polygon from triangles, so if I use this triangle filling algorithm, the edges from each triangle wouldn't overlap (or make gaps between them), because then it would result into rendering errors if I use for example XOR to render the pixels.
Therefore, the render quality should match to OpenGL rendering, so I should be able to define - for example - a circle with N-vertices, and it would render like a circle with any size correctly; so it doesn't use only integer coordinates to render it like some triangle filling algorithms do.
I would need the ability to control the triangle filling myself: I could add my own logic on how each of the individual pixels would be rendered. So I need the bare code behind the rendering, to have full control on it. It should be efficient enough to draw tens of thousands of triangles without waiting more than a second perhaps. (I'm not sure how fast it can be at best, but I hope it wont take more than 10 seconds).
Preferred language would be C++, but I can convert other languages to my needs.
If there are no free algorithms for this, where can I learn to build one myself, and how hard would that actually be? (me=math noob).
I added OpenGL tag since this is somehow related to it.
Edit2: I tried the algo in here: http://joshbeam.com/articles/triangle_rasterization/ But it seems to be slightly broken, here is a circle with 64 triangles rendered with it:
But if you zoom in, you can see the errors:
Explanation: There is 2 pixels overlapping to the other triangle colors, which should not happen! (or transparency or XOR etc effects will produce bad rendering).
It seems like the errors are more visible on smaller circles. This is not acceptable if I want to have a XOR effect for the pixels.
What can I do to fix these, so it will fill it perfectly without overlapped pixels or gaps?
Edit4: I noticed that rendering very small circles isn't very good. I realised this was because the coordinates were indeed converted to integers. How can I treat the coordinates as floats and make it render the circle precisely and perfectly just like in OpenGL ? Here is example how bad the small circles look like:
Notice how perfect the OpenGL render is! THAT is what I want to achieve, without using OpenGL. NOTE: I dont just want to render perfect circle, but any polygon shape.
There's always the half-space method.
OpenGL uses the GPU to perform this job. This is accelerated in hardware and is called rasterization.
As far as i know the hardware implementation is based on the scan-line algorithm.
This used to be done by creating the outline and then filling in the horizontal lines. See this link for more details - http://joshbeam.com/articles/triangle_rasterization/
Edit: I don't think this will produce the lone pixels you are after, there should be a pixel on every line.
Your problem looks a lot like the problem one has when it comes to triangles sharing the very same edge. What is done by triangles sharing an edge is that one triangle is allowed to conquer the space while the other has to leave it blank.
When doing work with a graphic card usually one gets this behavior by applying a drawing order from left to right while also enabling a z-buffer test or testing if the pixel has ever been drawn. So if a pixel with the very same z-value is already set, changing the pixel is not allowed.
In your example with the circles the line of both neighboring circle segments are not exact. You have to check if the edges are calculated differently and why.
Whenever you draw two different shapes and you see something like that you can either fix your model (so they share all the edge vertexes), go for a z-buffer test or a color test.
You can also minimize the effect by drawing edges using a sub-buffer that has a higher resolution and down-sample it. Since this does not effect the whole area it is more cost effective in terms of space and time when compared to down-sampling the whole scene.
I'm working on an OpenGL 3 renderer for a GUI toolkit called Gwen. I nearly have everything working, but I'm having some issues getting everything to blend correctly. I've sorted the triangles by which texture they use and packed them into a VBO, so with the Unit Test, it basically boils down into 3 layers: Filled Rects with no texture, Text, and the windows, buttons, etc that use a skin texture.
The Filled Rects are usually drawn on top of everything else and blended in, but the background behind everything is also a Filled Rect, so I can't count on that. There is a Z-value conflict if you draw them last (ex: the windows have a textured shadow around the edges that turns black because the background fails the depth test) and a blending/z-value conflict if you draw them first (ex: some of the selection highlights get drawn on top of instead of blending like they're supposed to).
I can't count on being able to identify any specific layer except the Filled Rects. The different layers have a mix of z-values, so I can't just draw them in a certain order to make things work. While writing this, I thought of a simple method of drawing the triangles sorted back to front, but it could mean lots of little draw calls, which I'm hoping to avoid. Is there some method that involves some voodoo magic blending that would let me keep my big batches of triangles?
You're drawing a GUI; batching shouldn't be your first priority for the simple fact that a GUI just doesn't do much. A GUI will almost never be your performance bottleneck. This smells of premature optimization; first, get it to work. Then, if it's too slow, make it work faster.
There is no simple mechanism for order-independent transparency. Your best bet is to just render things in the proper Z order.
I have textures that i'm creating and would like to antialias them. I have access to each pixel's color, given this how could I antialias the entire texture?
Thanks
I'm sorry but true anti-aliasing does not consist in getting the average color from the neighbours as commented above. This will undoubtfully soften the edges but it's not anti-aliasing but blurring. True anti-aliasing just cannot be done properly on a bitmap, since it has to be calculated at drawing time to tell which pixels and/or edges must be "softened" and which ones must not. For instance: imagine you draw an horizontal line which must be exactly 1 pixel thick (say "high") and must be placed exactly on an integer screen row coordinate. Obviously, you'll want it unsoftened, and proper anti-aliasing algorithm will do it, drawing your line as a perfect row of solid pixels surrounded by perfect background-coloured pixels, with no tone blending at all. But if you take this same line once it's been drawn (i.e. bitmap) and apply the average method, you'll get blurring above and below the line, resulting a 3 pixels thick horizontal line, which is not the goal. Of course, everything could be achieved through the right coding but from a very different and much more complex approach.
The basic method for anti-aliasing is: for a pixel P, sample the pixels around it. P's new color is the average of its original color with those of the samples.
You might sample more or less pixels, change the size of the area around the pixel to sample, or randomly choose which pixels to sample.
As others have said, though: anti-aliasing isn't really something that's done to an image that's already a bitmap of pixels. It's a technique that's implemented in the 2D/3D rendering engine.
"Anti-aliasing" can refer to a broad range of different techniques. None of those would typically be something that you would do in advance to a texture.
Maybe you mean mip-mapping? http://en.wikipedia.org/wiki/Mipmap
It's not very meaningful to ask about antialiasing in terms this vague. It all depends on the nature of the textures and how they will be used.
Generally though, if you don't have control over the display environment and your textures might be scaled, rotated, or composited with other elements you don't have any control over, you should use transparency to indicate where your image ends and where it only partially fills a pixel.
It's also generally good to avoid sharp edges and features that are small relative to the amount of scaling that might be done.