Jump to content

Large world performance - Hints and tips


photo

Recommended Posts

Rob, this is indeed the same problem i am tackling right now, and we have had to make some compromises purely because of our tight schedule, it is a testament to Unigines content creation power that we have been able to create a stretch of terrain 170km long at 1m resolution in a few days.

 

However as you say draw distance of foliage in these circumstances is a real issue... i believe custom content with billboards for final lod will be the answer, however we do not have the time to build this custom content.

 

We have had to make compromises by using only one bush type, with random scale and rotation. This i have a lod distance for the last lod of 300 and a fade of 70. the cluster settings are the same. Yes there is some fade in, but we will live with it in our case.

It does bother me that you cannot see the foliage at a great distance, but i guess this you cannot have everything. Also we are using very sparse settings.. i would love to be able to add more, however if i turn up density the framerate does not drop too much, however i get very bad stuttering and hangs at certain times... unacceptable for a simulator.

 

unigine has a lot of performance tuning options, but that can be its downfall at times, it is a balancing act between many different systems and many different settings. all of them seeming magic in the way the work and exist with eachother.

 

 

I would love to see a complete guide to world content creation at some time in the future for large world handling.

 

It would be great hear if anyone has an idea on how to setup many many trees on a contrasting coloured terrain that are visible at a great distance.

 

What I did for the "small" foliage is create a grass node with a texture with 4 collumns this way you can have 1 grass node with 4 different types of plants as you have a mask with 4 channels,

ive set the texture of this to a billboard so it always faces the player, the distance is set to 300 and fade to 400 this way you can still see something in the distance instead of just stuff popping up on the fly

 

For the trees which I only have a handfull atm around a small oasis part of the level ive set up 3 LOD levels, 1 detailed model of about 1300 tris, a second LOD with 400 tris and crossed planes mesh with only 8 tris,

For this I just set up the LOD's so they wont pop in and gradually fade into the next LOD and for the very last LOD I set up a grass node again which uses the same mask as the mesh clutter for the palm trees,

By using the grass node again you can use this 1 grass node for 4 different tree types and you can set the distance all the way up as you will barely notice a performance drop

 

This is the same way Unigine did it in the valley demo and to me this is the best way as you have enough detail in your trees by using the LOD's and then use the grass node as the final most distant LOD

 

Only downside of using the grass node is that the trees arent in the exact same position of the original trees so you see some popping but it definately beats having no trees on your horizon

 

Ive added an example screenshot of our level, note that the foliage is a placeholder atm

Our world is running about 100 fps using a resolution of 1920x1080, but I do notice framedrops and stutters every now and then

post-509-0-92346800-1346247761_thumb.jpg

Link to comment

Update with some new findings:

-With World clutter we were experiencing major render stalls, framerate drops and generally poor performance.

-Switching to Object Mesh Clutter got rid of most of these issues and also allowed us to increse the visibility range and amount of objects substantially.

-I would reccomend using Mesh Clutter over World Clutter in all cases.

 

Question for Unigine: In what cases should you use World Clutter then over mesh clutter, and why does it still exist if mesh Clutter is better performing? is this purely for backwards compatability?

Link to comment

WorldClutter is able to place any node in the world including physics, particles, sounds...

ObjectMeshClutter is able to place only mesh geometry but in the extremely efficient way.

Link to comment

Shane, I was wondering how you place the tracks

Is it 1 mesh placed on the terrain and then split into multiple pieces?

 

And how did you onyl use a coarse texture and normal for the terrain without patch surfaces? Just removed them?

 

I was also wondering what the performance gain would be by using mipmaps, anyone tried it?

Atm I havent generated any mipmaps yet but I doubt ill see a huge performance gain

Link to comment

Hi Rob - in answer to you questions, our track generation is a custom tool that reads a track definition file (xml), then builds it automatically from dynamic meshes. Our terrain is then imported and we have tool to pull the terrain to the trackbed so that it all matches up.

 

basically we have created a whole custom toolkit to extend Unigine, focused purely on building Train Simulator graphics.

 

With the coarse maps we again wrote our own terrain importer based on the unigine one - we just removed the parts that generate patches. All we generate is a coarse diffuse, the normal maps are generated from Unigine once all the terrain importing and pulling to track stage is done.

 

I am in the process now of doubling the size of our world to 300km this is 197 tiles at 8193 x 8193.. i hope it works :D

Link to comment

Also we are using very sparse settings.. i would love to be able to add more, however if i turn up density the framerate does not drop too much, however i get very bad stuttering and hangs at certain times... unacceptable for a simulator.

The chosen cell size here is of extreme importance (combined with density and the visible distance). Our tech artists manage to avoid stalls in our projects. Yep, a balancing act between these.

 

unigine has a lot of performance tuning options, but that can be its downfall at times, it is a balancing act between many different systems and many different settings. all of them seeming magic in the way the work and exist with eachother.

It's payoff for high flexibility. Another side of the coin. But you get a chance to set up many aspects to find the optimum depending on the scale or purpose of your project.

 

Only downside of using the grass node is that the trees arent in the exact same position of the original trees so you see some popping but it definately beats having no trees on your horizon

If you use ObjectMeshCluster, it's possible to generate ObjectBillboards (not individual ObjectBillborad!) on the same positions, break them up into squares (or into some other kind of clusters) - and you'll get the most distant billboard LOD with precise positioning. Grass and ObjectBillboards are more or less comparable in speed.

Link to comment
  • 5 weeks later...
  • 1 month later...

What is, from the point of the view best performance, solution for colliders for trees in forest? Mesh clutter does not support colliders, so If i understand it well, I must use world cluster with same mask as mesh clutter to place these colliders. How big is performance impact for this? Wouldnt be better to support colliders in mesh clutter (for majority of games each tree must have collider anyway). Or is there any better approach? Thanks.

Link to comment

What is, from the point of the view best performance, solution for colliders for trees in forest?

WorldClutter

 

Wouldnt be better to support colliders in mesh clutter (for majority of games each tree must have collider anyway)

Then ObjectMeshClutter would be a WorldClutter object :)

 

The speed advantage of ObjectMeshClutter is mainly caused by exactly the fact that it does not have to provide physics interaction. Therefore it can render just the geometry in larger batches very quickly. On the other hand for having physical interactions WorldClutter actually has to instanciate dynamically object nodes (with optional collission support) in the world around the current viewer position. This is a much heavier operation, but cannot be avoided.

 

See this post for a forrest example where the trees with collision geometries are placed via WorldClutter, while the ground vegetation is placed without collision geometry. As stated in the post remaining key problem is the smooth transition of tree geometry instances to billboard representations. This feature has been requested for years (e.g. this post)

 

UNIGINE already announced at the beginning of the year, that there will be a modified version of ObjectGrass to support this kind of smooth billboard transition. This is a key requirement also for their planned Valley demo. Unfortunately the release date of the final version of the demo including this functionality is still unclear. The release has been delayed several times since initial announcement

Link to comment

Thanks. Anyway wouldnt be better to have trees placed by mesh clutter and place colliders on the same place by world clutter in very close distance around camera (you dont need colliders in the full visibility)? Or this is automatically done and visibility does not equal range of placed colliders?

 

Btw, it is really necessary to solve collisions for trees by physics? What about using information about tree position from vegetation map and only dont allow character controller to step on such place? For big objects like stones this wouldnt work without specifying radius of placed meshes (information in veg. map is point), but for barks of trees this can work quite easily and maybe such calculation would be much faster than physics.

 

I also agree with importance of billboard solution for vegetation, in current situation solution is far from "user friendly", also we cant use billboards from closer distance (it is too much visible), which means far bigger performance impact of vegetation.

Generally engine should be automatically able to generate atlas for given tree (object) from various angles, build "cross" from such planes and render always the most appropriate plane according to camera position. This is very important, because tree is not always symetrical.

Link to comment

Well, you could try to test your assumptions on better performance by doing it on your own, but this sounds a little bit like reinventing the wheel: actualy the engine is designed for this task and already provides this functionality and I would assume that it will do it much more efficiently than any script based implementation except in some very special situations.

 

BTW you can set a much smaller physics distance (e.g. 20m) than visibility distance and WorldClutter distance, so the overhead for collision testing can be further reduced according to your needs.

Link to comment
  • 4 weeks later...

I would expect that this depends on the clutter distribution within area. If the area is mostly evenly covered by clutter (=no need for high-resolution mask texture) than single WorldClutter should perform better. Things might change if you have very sparse distribution with high detail requirements (=large mask texture consuming a lot of memory

). In this case multiple smaller WorldClutter instances with smaller mask textures might be a better solution (at least in regard to total texture consumption)

 

So as always for performance issues: it depends on the actual scenery and assumptions have to be tested.

Link to comment
  • 3 weeks later...

Agreed with Ulf, it highly depends on the scene and a mask resolution you need. Plus it depend on whether we're talking about a Mesh or Word clutter:

  • Mesh clutter has a tree inside, so having multiple mesh clutter nodes can result in some performance decrease, though not high.
  • For World clutter that does not store a tree and only deals with a given radius around the camera, it is of no difference if you have one or several of them.
Link to comment
×
×
  • Create New...