For large world > 50km, we choose to move all objects so that camera is always small range from origin.
Unfortunately, when there is a lot of objects, it’s too costly.
So the best solution is to add a cell system to only move objects around the camera, or when they pop into the world.
By the way a cell system is needed as soon as there is a lot of objects, because the unity lod group is far from sufficient to get good performances.
1 Like
Which method are you using to move those objects? Have you tried TransformAccessArray?
We use a classic game object transform translation. For now we are using Unity 2021 builtin and game objects. We plan to pass on unity 6000 URP and use more BatchRendererGroups and less game objects, so it should improve this kind of process.
1 Like
Updated: Although I have not found documents that HDRP has native “origin shift,” the document on camera relative rendering does explain a fair bit about the workings of HDRP automatic process.
It does not, however, sound like a thershold-based origin-shift (like the old unity wiki described), but more like a continuous method.
If it is threshold based, how do you script the shift threshold?
The big issue I have with all this is that it is not logically possible for the rendering pipeline to do as described: " The Mesh faces of distant GameObjects that are close to one another may appear in the same place and produce z-fighting artfacts. To fix this issue, camera-relative rendering replaces the world origin with the position of the Camera."
The reason why this is not logical is that jitter (error) in real-world mesh positions that is created in the application pipeline(before rendering stage)
cannot be corrected by the rendering pipeline. I have tested this and there is still jitter: between the meshes.
@arnaud-carre does state that the non rendering steps are not covered, however, this is also the very reason why positional error that propagates into the rendering pipeline cannot be fixed by it.
1 Like