I have a question regarding the terrain rendering. In my game Lunar Flight I have several maps, 2 of which run over >60 FPS but one of them is have significant performance issues(<30 FPS) and the only thing I can think it is is the heightfields topology.
The Canyon map which has heaps of steep ravines runs slower, I’m guessing this is because the dynamic LOD system has to use more triangles to maintain the shape of the terrain. In addition to this there is lots of overdraw due to the layering of the terrain when viewed from inside the canyon across the map. The terrain culling does not factor in line of sight so it is rendering all the terrain even when you cannot see it.
Will the improved PVS of the occlusion culling system deal with this?
The current pvs already does all that already, the improved one isn’t gonna change anything on that end I guess it will only enable you to bake larger terrains than at the time. Also PVS will not just magically work but require baking. there is no dynamic pvs only static offline generated one
The performance hit you get is from the massive amount of detail your terrain requires and the pretty large heightmap, Unitys adaptive GeoMipmapping terrain (or how they internally call it, its clearly GMM based though and not ROAM or anything really dynamic) generates a massive amount of geometry to handle in realtime … from what I see I would assume that you easily reach or exceed the 2M at worst in view which even for high end hardware is a hard pill to swallow.
@Eric: Yeah I’ve played with those settings but they are the same in all the maps and I dont want to go too low because then you start to see really obvious LOD changes.
"We are working with the Umbra guys on a complete rewrite of the PVS solution which works much better.
It’s unfortunate that the Occlusion culling system was shipped in the state it was in, but it’s one of those things we and the Umbra guys just took a slightly off approach. It works for some scenes, and breaks down in others. If it fails there isn’t that much you can do about it unfortunately, except for wait until we have it fixed.
In any case, we have a completely rewritten occlusion culling system which is almost done, which is much more robust and much faster."
Thats what I assumed, that the detail is too high for baking the terrain at static itself. In that case 3.5 hopefully will help with the fixed sPVS generator.
BUT: you are going to have problems anyway as long as that second camera remains there. Cause the occlusion culling works for the primary camera only (the one tagged as Main Camera, also referenced in Camera.main), any other camera will not use OC anyway so your overhead camera will need some restrictions on how far it can go out or it just kills the performance on its own
Has there been any tests to confirm that the OC will only work with the main camera rendering? It would logically make sense that any camera could use the OC data to look up visibility independently…
My game can actualy have upto 6 cameras rendering the scene at once, believe it or not even with this I can get an average of 40 FPS on a mid spec PC.
Then whats the problem at all if you can overdo it that much and have fluent framerates?
Its unknown how 3.5 will change the OC handling and thats whats going to matter if you want to use terrains (even if they were flat OC wouldn’t build potentially)
