Sure, here is the link to the PDF: http://www2.disney.co.uk/cms_res/blackrockstudio/pdf/Foliage_Rendering_in_Pure.pdf

On this page you can find the slides and some videos, too: http://www.bungie.net/News/content.aspx?type=topnews&link=Siggraph_09

Quote:
What do you mean with "primitives" in this case and what exactly is not supported?


Triangles are basic primitives and the engine does not sort the triangles for you. The problem is that the Z buffer prevents from drawing pixels that are behind things that have already been drawn. Generally, that's pretty convenient - but when the thing in front is translucent, you NEED to see things that are behind it.

The first fix - upon which all the other fixes depend is to make sure you draw all your opaque polygons before you draw any translucent ones --- remember PASS_SOLID? Thats JCL magic. And that solves most of the problems. The only thing that remains is when you try to render one translucent polygon behind another, though, for many applications there are so few translucent objects that this is "good enough", but for forests and grass, well, you all know what happens and how it looks like...

The next thing that most people consider is to sort the translucent polygons as a function of Z depth. To be perfect - even sorting them isn't enough. You may have to split polygons up on-the-fly to get a perfect rendering. Imagine a large triangle of a tree entity intersecting another large triangle of another tree entity... ouch. There are so many cases of intersecting polygons that it is impossible to render them properly without splitting up at least on polygon. Worse still, if you decide to split and sort polygons - what key do you sort on? The center of the polygon? The nearest vertex? The furthest? You *will* get errors for any acceptable realtime algorithm. AFAIK, Gamestudio has no algorithm like this implemented - for good reasons, which are Simplicity and Speed. Especially nowadays everyone is rendering tons of polygons each frame, more than once maybe... so, it makes more sense to use postprocessing solutions, like the one I mentioned above.