sort polygons for blending?

Started by
7 comments, last by pauljan 18 years, 4 months ago
If the nearest transparent polygons are drawn first, blending doesn't work. Is there any other way than sorting all polygons by depth to make the blending work? If you have a large scene, the sorting would be very time consuming.
Advertisement
I'm pritty sure there's an algorithm that would calculate the result as if the latter drawn polygon had been drawn first (assuming it is on top, ie un-sorted), it may or may not be called 'peeling'. Other than that sorting is your only way to get robust results, everyones doing it.
Some people use additive blending to get around the sorting problem... This is not recommended because it only gives the expected results in very particular circumstances.

Additive blending works by just adding the source color to the destination color. Because addition is commutative, the polygons can be rendered in any order. This sounds like a brilliant idea, until you try it out and discover that it only works in situations where the background is very dark. It might work in a dark dungeon (maybe) but not in an outdoor scene with a bright blue sky. You'd think it would work in a space game, but then the white stars in the background will shine right through looking very strange. The reason is that white + any other color = white.

Edit:
Oh wait, were you saying that you thought you had to sort ALL of the polygons in the scene? I'm pretty sure that you could get away with just rendering the transparent ones last and sorting them, like what Gavinl is saying.
This is an idea i thought off, but haven't had the time to test to see if it works. Maybe you could try it.


Place all the polygons in a queue.

start popping them one by one. If it is not transparent, draw it. If it is transparent, push it in a differnet queue. When you have popped all the polygons from the first queue. Start popping the second queue that has all the transparent polygons.



-------------------------------------Physics Labhttp://www.physics-lab.netC++ Labhttp://cpp.physics-lab.net
egads no!
That would be terribly slow..

Firstly, forget polygon sorting and forget polygon drawing, its far far too slow.
Instead you should be drawing objects (or parts of objects in the case of multiple materials and textures on one object) at a time.

Firstly, you draw all the non-transparent parts of the objects, for some this will be the whole objects for others it'll be most of, preferably in more or less a front to back order.

Then you draw the objects again, this time telling them its a transparent pass, so only the transparent parts of the objects are drawn. Now, if you do this twice, you can employ a little trick to make it look more or less right.

On the first pass you set backface culling so that it firstly culls the front faces and then culls the back faces. This gives you more or less correct rendering of the transparancy.

Ofcourse, this does all depend somewhat on your scene and the speed of camera movement, it might be possible, with a slow moving camera, to properly sort everything and then reuse the results between frames, so you only have to make small changes each frame.
Thanks for the ideas.
I'll give phantom's idea a try. (in another project i'm working on)

But for the modelling program i'm writing now, i think it would be better to wait with the blending stuff untill the rest works fine.
Phantom: the simple trick of rendering backfaces first than frontfaces, without any additional sorting, works nicely if you are rendering a single convex transparent object.

However, in a general modeler (like the thing Kwak is apparently working on), one of the first thing people seem to try to do is things like placing two (similar facing) windows in a row. Not a very uncommon case. In that case, you'll need to at least implement a depth-sort at the object level (for objects with transparent parts only). Unless I am seriously mistaken, in that case just beat me with your admin stick and call me silly :P

I'd say that in the average scene only a very small percentage of all faces rendered is actually transparent. Doing a bulk render on the solid polygons, then a little depthsort+backfrontpass render of the transparent polygons will get you a long way without being too costly. Sorting is relatively cheap.

If the scene has lots of transparent polygons, sorting will become a lot more expensive, but not sorting will also have more evident artifacts.

Hint to Kwak: if you then offer the possibility to merge both window objects into a single (obviously not convex) object like we do in our modeler, you are basically screwed :)
Quote:you are basically screwed

isn't supposed to be a professional modeler anyway :p
Well, it definitely does look like a modeler, but with a very distinct color scheme :D. Make sure to post an IOTD at some point, would be great to see the progress!

This topic is closed to new replies.

Advertisement