What's with trees this generation?

Cyan

orange
Legend
Supporter
I am playing Red Dead Redemption on the X360 lately, I arrived in the West Elizabeth area just recently and I have been wandering around just to enjoy the landscape and get used to the map.
 
So I traveled the Great Plains and some other places of that region, and there is a specific part of West Elizabeth called Tall Trees...

There is a thick and lush forest there and when I went deeper into the woods and was surrounded by trees I noticed the framerate decreased so suddenly, not so much, but still very noticeable. It went from 30 fps to what seemed to be like 20 fps.

Other than that, RDR has a flawless framerate 99% of the time.
 
There are games like Halo 3 where the vegetation, the ferns and conifers were very detailed, but you didn't have a massive number of trees, they were scattered around, plus the map in the wooded areas was not open at all, so the game didn't suffer.
 
The same happens with other games featuring overgrown and leafy forests, but usually in the distance, you can't get there and the game plays just fine.
 
There is something about the trees that can make your console crawl, I think.
 
Another game I liked a lot this generation and I still proudly have, despite of being a PS2 port for the most part, is Alaskan Adventures. :D
 
The game doesn't match the definition of sandbox but it has some very open parts where you can roam freely at will.
 
Particularly in the Yukon Delta, there is an area with a tangle of vegetation and then a very lush forest filled with tall trees.

Well, when you get relatively close to those trees and you look at them, the console literally CRAWLS.

The branches of those trees in particular look a bit weird, as it they were rendered with some kind of "smoke from a candle" occluding them. I can't find the words to define it exactly. (as if some pixels come and go if you move the camera) :oops:
 
It's like it bends its knees and goes from a standard 30 fps to 2 fps. I am not exaggerating a bit.

If you turn around and you look somewhere else all is fine and dandy, the framerate fully recovers, but when you look to those trees the console certainly starts crying.

Every console suffers from having some games with a jerky framerate, but the trees just take that to a whole new level.

I wonder, what so computationally intensive about rendering them for consoles to have such difficulties to render the trees?
 
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.
 
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.
That is definition of what I was trying to describe but couldn't explain properly. Yes, in Alaskan Adventures the trees' branches in that area of the Yukon Delta looked like a mess after each slight camera movement. They looked like they were overlapping and transparent.

One single simple answer...

Overdraw...
Thanks archangelmorph, your response and the previous one got my bases covered.

I wonder how a game like Alaskan Adventures can suffer from overdraw when developers say the PS2 is an overdraw monster, and the game was ported to the Xbox 360 which has plenty of eDRAM bandwith, unlike the original Xbox -as recently mentioned by a developer-.

In my opinion, those games try to have truly realistic trees while other games fake the geometry with solid trees, and the leafs aren't transparent at all.

Lots of modern games come to mind, even the most technologically advanced ones, where the branches and leafs don't look convincing.

In Alaskan adventures that part in particular looked very realistic and just screamed brick-shitting amazement that made it worth, and I expect a similar approach next generation when PS4, X720 and WiiU come out.

Despite the technological improvements in games, it is certainly an unresolved matter. At least not as satisfactorily as in Alaskan Adventures and the likes despite the framerate.
 
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:

 
There is something about the trees that can make your console crawl, I think.
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...
 
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 :(
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 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.
RDR has a very good impostor system designed specially for tree rendering. They have used many nice tricks in it :)
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.
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.
 
Problem is that all tree leaves tend to move slightly differently in wind, and rebuilding the whole acceleration structure every frame costs a lot.

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.
 
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.
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.
 
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.
 
Back
Top