Forest Rendering

[ulf.schroeter]

Proposal

 

Addition of specialized ObjectForest object for optimized large-scale forest rendering.

 

Motivation

 

Based on numerous customer postings/requests on the forum there is an obvious high-priority requirement for large-scale, dense forest rendering capability comparable to implementation in other game/engines like CryEngine, Arma 2 or Leadwerks. Maybe this post can centralize discussions currently spread over several forum threads.

 

Requirements

 

Leadwerks GDC2010 presentations seems to be a good illustration of minimum required fidelity (although still showing some heavy popping on LOD switches)

 

Available UNIGINE objects like WorldClutter, WorldCluster or integrated impostor rendering already provide viable parts of required functionality as shown in the following sample which has been build based on WorldClutter and ObjectGrass.

 

Visual results at short distances are quite convincing but of course automatic and smooth 3D-geometry to billboard transition (both geometry and lighting) at larger distances is the key requirement for high-performance forest rendering with 10000++ tree instances. Available generalized impostor rendering system for sure cannot handle this special-type of large-count billboard rendering.

 

Therefore proposed ObjectForest should provide following features

 

1. Addition and removal of tree reference nodes used in forest rendering (comparable to WorldClutter approach). Tree node geometry should be regular multi-surface/-LOD geometry e.g. taken from UNIGINE content library or converted SpeedTree geometry via SpeedTree plugin.
    
   

   int ObjectForest::addTreeReference( string ref_nodefilename );
   int ObjectForest::removeTreeReference( int ref_num );
   

   
   For each tree reference ObjectForest should automatically build multi-angle diffuse color/normal map texture atlas used for correctly world-lit tree instance billboard rendering at greater distances.
    
   

2. Addition and removal of individial tree instances for each tree reference (comparable to WorldCluster). Each tree instance is specified by xyz instance position and overall scale value. Instance z-rotation could be automatically pseudo-randomized based on xyz position.
    
   

   int ObjectForest::addTreeInstance( int ref_num, vec4 position_scale );
   int ObjectForest::removeTreeInstance( int ref_num, int instance_num );
   

   
    
   

3. Streaming support for large worlds with multiple ObjectForest instances. As large count tree instance data per ObjectForest instance requires quite huge amount of memory this data should also be streamable like world mask images for ObjectGrass, WorldClutter etc.
    
   For efficient support of multiple ObjectForest instances per-reference texture atlas resources should also be shared/re-used between ObjectForest instances.
    
   
4. Interactive additon, re-positioning/-scaling and removal of individual tree instances in editor (comparable to WorldCluster).
    
   Comfortable way maybe would be if ObjectForest instance would add spawned full 3D-geometry tree instances around viewer position in editor mode as child node references. User then could select individual tree instances by simple double-click and use standard translation/scaling, node cloning and removal for instance data editing. Owning ObjectForest instance should continously track data changes of child node references and update internal instance data accordingly while in editor mode.
    
   
5. Optional automatic tree instance generation in editor based on per-reference mask/density image and distribution parameters to simplify initial forest popolution (comparable to WorldCluster generator)
    
   
6. Efficent batching of tree billboard rendering. Batch count minimization based on hierachial quad-/octree as described in Rendering of Forest Scenes seams to be good solution.
    
   
7. Efficient geometry-billboard transitions avoiding popping artifacts. SpeedTree always renders static billboard patches even if near instances are represented as 3D-geometry nodes to avoid costly buffer updates. Billboards for near-by tree instances will simply by rendered invisible by distance-dependent scaling of billboard-x/y vertices by 0.
    
   
8. Efficent line intersection support with proper per-pixel alpha-testing of tree textures/billboards instances, so line-of-sight ray casts do not stop at surfaces where hit pixel represents transparent foilage/impostor areas.
    
   

   int getIntersection(vec3 p0, vec3 p1, int surface, int ret[]);
   

   
   

 

 

Maybe this requirement summary is helpful for a full-fledged forest rendering solution. Shouldn't be too hard for UNIGINE as most building blocks are already available.

[steve3d]

ObjectForest should support two kind of operation,

1. like WorldClutter, totally random forest, controlled by a mask texture,

2. like WorldCluster, position and number are controlled by actual scene objects, but all objects must be NodeReference of speedtree objects.

[ulf.schroeter]

1. like WorldClutter, totally random forest, controlled by a mask texture,

added as requirement 5

 

2. like WorldCluster, position and number are controlled by actual scene objects, but all objects must be NodeReference of speedtree objects.

added as requirement 2

[steve3d]

I don't think all billboards need to be rendered as impostors, All SpeedTree texture-atlas can have 7 billboard textures for simple rendering, 6 billboards are vertical(rotated with camera), and one for overhead (fixed position and rotation).

 

If ObjectForest can make use of all these billboards, performance will be better.

[ulf.schroeter]

Right, that's exactly the reason why available impostor system cannot handle special-case forest rendering efficiently as it would try to generate/update impostor billboards for each individual tree instance. Not a good idea for a million tree instances.

 

Nevertheless UNIGINE should not rely on SpeedTree for more than importing/converting existing SpeedTree-Geometry (that's exactly what SpeedTree plug-in does right now). Otherwise all UNIGINE users would have to license SpeedTree (10K+ US$) for forest rendering which would be a very bad situation.

 

Best approach (also taken by all above mentioned game engines) therefore should be ObjectForest internal generation of matching multi-angle tree reference color/normal texture atlas used for correctly world-lit tree instance billboard rendering at greater distances (requirement 1).

[ulf.schroeter]

Details on C4 engine impostor forest rendering feature with full support for dynamic lighting. Maybe we will see something similar someday in UNIGINE, would be great for large outdoor scenes

[steve3d]

speedtree is ultimate solution to all this, now speedtree 6.0 has multiple platform support, hoping unigine will get full speedtree feature in next year or near future.

 

trees and vegetation is a must have feature in most outdoor scenes and it's a most important feature in virtual reality. (because, on earth, trees are everywhere except desert in our life, right? :rolleyes: )

[ulf.schroeter]

Don't be too marketing-guided. SpeedTree licence costs 10.000 US $ per platform, integration of their rendering code/shaders is horrible, default trees have far too much polygons, they do not support required intersection testing, ...., ....,

[ulf.schroeter]

[danni.coy]

found another great video on this topic and paper...

[ulf.schroeter]

yep, very impressive ! Most probably perfect for flight simulators where you do not come too close to a single tree (actually haven't seen anything better than this video for this special application)

 

For first-person applications most probably not flexible enough and 50MB+ memory requirement per tree model is quite a bit. But nevertheless big step forward in large-scale forest rendering ! These guys are really experts on planetary rendering, as they already have defined new standards for real-time atmospheric/vector terrain/ocean rendering with previous demo projects.

[alexei.garbuzenko]

Some time ago I found tree generator tool that could be useful for generating high-detailed Unigine trees without SpeedTree, Woody3d or other commercial software. It uses compatible billboard leaf cards and allows exporting to .obj format. That software was never released and still in beta/demo stage, however it is built on top if 3D Coat software by it's author, so active 3D Coat license might be needed for commercial usage. Here is a link to generator topic:

http://3d-coat.com/f...?showtopic=1003

 

Screenshot:

 

I also recorded a video to show how exactly tree model could be created and used in Unigine with this software. Unfortunatelly one more step - billboard generation - is requred for optimal performance, but Unigine does not support 360-degree tree billboards yet.

 

 

P.S. There is too aggressive optimization for LODs used in this video, so resulting model have a lot of 'LOD popping'. More precise tuning is needed for smooth transitions.

P.P.S. Tree leafs are rendered with custom shader for improved leaf lighting in deferred render mode (built-in leaf shading is broken in deferred mode).

[ulf.schroeter]

[ulf.schroeter]

[demostenes]

 

No problem to make this on Unigine too. And visual quality will be even better (!), because unigine has far better rendering capabilities:

 

http://www.endor.cz/demo/tree.png

 

 

Visual quality of these scenes is in very well made assets and huge skill in making scenes (that is almost crucial), not in engine itself (we own both packs and Unity and actually we are migrating everything from Unity to Unigine).

 

On the other side other difference will be speed, Unity has qiute optimized vegetation system, for example trees have automatical billboards, so such vegetation scenes are very fast:

 

http://www.endor.cz/demo/jungle5.jpg

 

Btw, in these scenes quality is much higher than in out of box Unity, there is used lots of 3rd party hacked vegetation/terrain shaders, where desperate community members tried to solve notorious problems like no bump mapping for terrain textures (this was added only recently in Unity 4.0), missing shadows for some kind of vegetation shaders, no animations for some kind of terrain details, etc...

[ulf.schroeter]

On the other side other difference will be speed, Unity has qiute optimized vegetation system, for example trees have automatical billboards, so such vegetation scenes are very fast.

Well, this is the reason for this thread: nearly every engine in the market - and all high-end engines without exception - provide a dedicated vegetation system with automatic geometry-to-billboard transition for highly efficient forest rendering...except UNIGINE, which is a real flaw as this functionality is required for most games and is requested by users for years

[demostenes]

Well, this is the reason for this thread: nearly every engine in the market - and all high-end engines without exception - provide a dedicated vegetation system with automatic geometry-to-billboard transition for highly efficient forest rendering...except UNIGINE, which is a real flaw as this functionality is required for most games and is requested by users for years

 

Agree, this is nowdays basic functionality. We will have around 60 square kilometres of forests in our game.

 

Generally we are waiting for two features. First some comfortable asset browser, beacuse now it is almost impossible to build scene in comfortable way, beacuse you have no preview of what you are loading (imagine you have 3000 thousands of nodes in various directories, you really dont know just from name how the object looks, also no drag and drop is causing serious frustration). Our level designers are now using Unity3d as asset browser (we have similar structure for our data in Unity3d). So imagine how comfortable (and slow) such workflow is. World building is now many times slower, than we were used to.

We will try to develop this functionality by ourselves, wa cant afford to wait for promised GUI upgrade. Second feature is automatical solution of billboarding vegetation, current solution is from my point of view just workaround, it needs some final solution.

[Guest shane.ploenges]

The last 3 Unigine based simulators we have built all had the same issues with Vegetation rendering, what we ended up doing to get long view distances without visible LOD popping was to use ony one tree type, disable all but the lowest 2 lods, and set a fiairy sparse amount of trees per tile.

 

This was far from ideal in terms of the amount of trees we could use, and the performance hit we had to suffer.

 

We are hoping at some point in the future lots of trees, and distant visible (billboard trees), without visible LOD switching will be supported.

[steve3d]

Well, I've modifid ObjectBillboards to render much more billboards in one object, each of this object can handle over 10M billboards.

 

and also I've modified the ObjectBillboards shader to cut the near distance billboards, so combined with ObjectMeshCluster, I can create a mass amount of trees in one single scene.

 

But the big problem is I'm using speedtree to generate a 360 degress of billboard atlas, and unigine don't support this, so... I have to only choose the very first of billboard image to use with ObjectBillboards, this makes most of billboards tree's looks very strange, but, with a large cut off distance like 200+ unit, the billboards looks small... (but still strange...)

[demostenes]

If you have billboards from distance like 200, then really does not matter much, how they are done. Point is, that if you have proper billboarding system, you can have billboards even from distances like 60-70, which means HUGE performance gain.

 

Btw, you wrote you modified ObjectBillboards, so I assume you have source code licence?

[steve3d]

yes, we are using the source license,

 

here, the screen shot, this is a big scene contains over 70 different trees. and we use ObjectBillboards to make the distance billboards.

 

Because speedtree also create normal altas, so... it looks strange

 

this scene use billboard distance of 120.

[ulf.schroeter]

Finally :)

[demostenes]

So, after few minutes of playing with our freshly migrated assets, I was able to achieve this:

 

http://www.endor.cz/demo/uni48.png

 

Not so bad, still needs plenty of tuning, but good start. Only problem I see now is framerate, it is cca 2x-3x lower, than it should be. Still lots of space for optimization in vegetation rendering.

[ulf.schroeter]

Excellent papers on massive virtual world rendering.

 

"Populating a Massive Game World" addresses one important feature for model/billboard vegetation rendering: manually placed tree/vegetation instances in addition to proceduraly placement fully integrated into optimized vegetation rendering

 

This is really something important missing in UNIGINE, but mandatory required e.g. for realistic strings of trees along man-made roads or individual trees in urban areas (e.g. for driving simulation). Above mentioned VBS3 Features: Biotopes also demonstrates some spline-based procedural tree placement capabilities fully integrated into general vegetation rendering.

 

This is impossible with current UNIGINE implementation using pure density mask based placement based on interdependent WorldClutter and ObjectGrass instances. While this approach allows usage of existing world/object classes the taken approach complicates vegetation setup significatly and now would require per-instance feature placement extensions on both classes which would be quite inelegant and inefficient. That was one of the key reason for suggesting a dedicated ObjectForest class.

[demostenes]

As usualy absolutely agree. In first step we made procedural generation of terrain and vegetation masks and now our lever designers are doing hand "tuning" of map because of FPS/3rd person nature of our game. And we are facing exactly this kind of problems (vegetation in cities...).