I have this project at work where we are displaying certain simulations (Solar System sized) and need double precision accuracy. Since Unity only uses single precision, we have incorporated a “Floating Origin” system where the camera stays at 0,0,0 and the objects move around the camera, instead of the other way around.
This all works great when we are just moving standard GameObjects, but when we start moving Terrains, the performance is significantly degraded. Going from about 60fps down to 5 or 10fps. If we were to run our simulations the normal way, no floating origin and the camera moves about the scene as usual, the performance stays at 60fps or so. We just get the spatial jitter when played this way, so we prefer the floating origin approach.
I know the Terrain system does some dynamic LOD switching based on heightmapMaximumLOD, heightmapPixelError, and other parameters, as you move about, but I would think those calculations are done based on the camera’s relative position/orientation to the terrain and it shouldn’t matter if you move the camera or the terrain.
I’ve been able to track down where the lag occurs using the profiler. Inside the Terrain.CullAllTerrains() call there is a call to a TerrainRenderer.RenderStep3(), which is a wrapper to an internal call that I cannot look inside to see what is going on.
I was wondering if anybody knows what may be causing this and has a possible work around? I would think the performance of moving the camera relative to a terrain vs moving the terrain relative to the camera would be the same. Apparently it isn’t.
I have made a simple fix where I allow the camera to move a certain threshold from the origin and then reset the origin when needed, which allows the terrain to stay in place more often and therefor keeps performance up most of the time. But this isn’t ideal and it would be nice to know why the terrain system doesn’t like to be moved.
Sorry for the long-winded question… and thanks for any information.
That's an interesting idea, thank you. We are currently using Unity 3.5 and are about to upgrade soon, so I'll keep that in mind as a possibility. That would probably give much better performance than Unity's Terrain engine LODing too. Unfortunately, we will also be deploying on Macs so that may limit our deployment a bit. From what I can gather, there isn't any plan for Unity to support OpenGL 4 in the near future. Would be nice though.
– whebert