We have a project at work where we deal in Solar System sized simulations, but at the same time deal with small objects too (satellites, rockets, etc.), so we needed double precision position accuracy. Since Unity uses single precision position vectors, we got around this limitation by incorporating a “floating origin”, where the camera stays at 0,0,0 and everything else moves around the camera (instead of the camera moving around the scene).
This works, but we’ve noticed that when moving Terrains around we experience really bad lag where the frame rate will go from, say, 60 fps down to 5 to 10 fps or so. We understand the Unity Terrain system is producing terrain LOD calculations on the fly, but figured this was a relative thing between the camera and the terrain, so the performance should be similar whether you’re moving the camera around, or as in our case, keeping the camera still and moving the terrain instead.
Obviously this is not the case. Something extra is going on when you actually move the terrain as apposed to moving the camera relative to the terrain. We were hoping somebody (maybe even Unity developers) had some insight into what is causing this and, hopefully, can offer a workaround.
Thanks for any information.
I’m just having a wild hunch, but are you using the “floating origin” to move this whole world about? or do you move all objects seperately?
in the latter case, i dare bet that moving the many, many objects can cause a massive overhead in assigning new coördinates/moving the objects, instead of moving a single player and camera.
I’f all objects moved are under a single parent and you’d move that, possibly unity will have to rewrite less values and thus cost less performance.
Also, moving all objects instead of the camera would be likely to cost extra due to every world-oriented calculation will have to be performed again (in theory, in practice unity could be handling these things differently)
I’m not sure how unity handles the exact mechanics i mentioned, but that would be the direction i’d point my arrows at.
Do you happen to have PRO? then you can also use the profiler to see what consumes most computation time 
We move all objects individually. Our project is essentially a simulation playback, where every object in the simulation has it’s position/orientation updated every frame due to a telemetry. The number of objects moving in the simulation is not very large, one example would have about 50 or so. We can run these simulations either using this “floating origin” method, or normally where the camera moves around the scene. The only difference is whether the objects positions are updated relative to World origin or the Camera’s origin - but you run into accuracy issues and “spatial jitter” when you move too far away from the World origin (“floating origin” fixes that). In either case, the performance is pretty much identical, except when a Terrain is in the scene (Terrains aren’t always part of the simulations).
We do have Pro and I’ve used the profiler to track down where the lag is occurring. 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. So whatever is going on, it’s going on in the internal Unity C++ core. If I had to guess, by moving the Terrain object I somehow invalidate a pre-computed setup or something that must then be re-computed, causing the lag. Just wish I knew what, specifically, was causing it and if there were any way around it (avoid it).