What's with trees this generation?

Trees are very complex. Either you model every leaf with geometry, which is an awful lot of polygons, or you render larger quads with leaves alpha masked, and rendering lots of overlapping transparent polygons is a real killer for a conventional renderer.

 

One single simple answer...

Overdraw...

 

The more they can be done with geometry, the better I think. Many trees are currently still done with transparent bitmaps, often of not too great quality/resolution. I liked the forests in Uncharted 2, Motorstorm 2, and the forests in Assassin's Creed 3 (and Liberation) look pretty good too. And the trees I've seen so far in Red Dead are very nice too actually, but I'm only just into the game (and on PS3).

EDIT: first example of Uncharted 2 jungle I could find:

 

Trees are... bad... I have seen profile captures of scenes where rendering of two trees took more time than rendering of the whole terrain mesh (and terrain is huge = 2 kilometer view range and lots of polygons).

Basically the biggest problem with trees is overdraw. If you do the trees with fine grained geometry you will have slightly less overdraw compared to trees that have billboard leaves (lots of them) and geometry only for trunk/branches, but then you have massive amount of geometry to transform, and still you have lots of overdraw. Single billboard trees are not high quality enough for closeups, and closeups are the worst when fillrate is considered (tree covers huge area of the screen). I have seen 20x overdraw from a single tree. It's really that bad.

If your renderer is using forward rendering, you will light the pixel 20 times (with multiple light sources). ALU cost goes trough the roof, and TEX/BW cost as well if you have shadow maps on those lights... If you try to render those pesky trees to g-buffers (deferred rendering), you will be fill rate bound faster than you realize. Each extra MRT reduces the fill rate. Four MRTs = 1/4 fill rate... and you have 20x overdraw... Not a good combination

That's why trees are evil

 

Great post Sebbi! I remember Rockstar (and Crytek) saying RDR was more difficult for the team to create with high standards than GTAIV, and vegetation with big draw distance was probably a reason why. RDR game is full of trees, bushes and grass and they don't pop up very often once installed. Lots of polys and bandwidth went in that direction. I know I was seriously impressed with trees in RDR, and now when I look at ACIII they stick out like sore thumb.

Curious about console performance of Crysis 3, the trees they got there are great. Maybe lower LOD...

 

How are the trees done in Crysis? How is crysis performance on consoles with those many trees?

 

My professor at University is into this very topic. Less so in terms of realtime rendering, but more in terms of "correctness" (if you want to read about it, there are a lot of papers at his faculty page http://cms.uni-konstanz.de/informatik/deussen/publikationen/).

 

heres an old thing of mine, I was aiming for pixar like quality
http://www.flipcode.com/archives/02-27-2005_veg.shtml
I wouldnt mine seeing that run on some of todays hardware. IIRC on a gf6600 & amd 1core 2ghz it was ~30fps 1024x768 or something.
the scene was constructed anew every single frame, no caching, thus every blade of grass & leaf was animated.

 

I think raytracing would be the best solution with a 1:1 ratio of surfaces rendered per pixel (well, sample in case of AA), although you'd have a mask test per ray, unless it was all geometry.

 

RDR has a very good impostor system designed specially for tree rendering. They have used many nice tricks in it

Raytracing though a soup of large (1 bit) alpha masked polygons requires texture sampling for each polygon you pass, even if the pixel is fully transparent (you don't know that before you sample the texel from the alpha map). So basically you pay the same overdraw cost here. Of course if you spend more geometry to have less fully transparent areas in polygons, you will get almost 1:1 ratio of surfaces per pixels sampled. If you have a good acceleration structure for raytracing, the high polygon count doesn't matter that much. Problem is that all tree leaves tend to move slightly differently in wind, and rebuilding the whole acceleration structure every frame costs a lot.

 

Raytracing also has the benefits of massive instancing... but there are other types of costs. The most important is that an offline rendering approach can deal with the occasional extreme high rendering time for a few frames, as it averages out in the end - but a realtime application can't afford that.

 

One possible cheat is to precalculate the deformation and cache it out, then instance it with a few frame offset. Of course this may not work with particularly strong winds and so on, but a light breeze is OK.

I believe this is close to what we did with the sunflower field in the ME3 trailer BTW.

 

Well, if you have a mask that fits in cache/local store on a CPU, it'd be one texture lookup per surface. Is it transparent? Yes > cast a secondary ray. It should be as fast as the acceleration structure can be traversed. Otherwise, if you have to keep searching large textures, then that would be crippling. And of course the issue about moving geometry still stands, as you say. Where I can see volumetric fog rendered algorithmically and circumventing the need for alpha drawn particles, I'm not sure how to get around tree rendering.

 

Also the open world of RDR, you are walking through a forest, its fairly flat and you can go in any direction. Uncharted is totally different, its not open, its corridors giving much more control of reducing overdraw.

 

Alan Wake was one with lots of trees. Not huge variety, just nice big fir trees.

 

Worst comes to worst you can always use a solid sprite like Mario 64 did

 

Would this be one case where a DX11 tessellator could help out massively?

 

Not really. You could cull geometry with it but at a granularity of pixel to sub-pixel size for each primitive it's more efficient to use the z-buffer instead. It's also no easy lunch to do dynamic adaptive tree-LODing with the tesselator, as trees have lots of holes the only simple way to down-LOD is from geometry to textures, using alpha-billboards resembling those holes. Then again you're eaten by overdraw. It may be possible to make a funky branch-geometry growth LOD system (imagine the tree gets bitten by a bee and has an alergic reaction) which starts to splat leaf-green on the branch-texture, but I doubt it is very reliable and I don't think it'd work for all tree-types.