Largest World Size? Spatial Jitter fixes?

Hi. I recently encountered an issue when trying to make a large world. If you make a terrain and move your camera to a position that is around 2000 units away from 0 0 0 you get serious spatial jitter on your view models as well as the shadows in deferred rendering mode, It gets worse the further you go. (See this webplayer : http://dl.dropbox.com/u/19800122/jitter/WebPlayer.html )

Basically from what I can see it means the effective world limit for unity is no bigger than 2km^2 which is pretty small.

I've come up with several ideas such as segmenting the world into smaller grid sections and re-centering the active grid section to 0 0 0 as you move through the world but I'm not sure what would happen to occlusion culling and the navmesh. We're considering some solutions for fixing the viewmodel jitter via some custom shaders but due to the restricted access of unity it's hard to come up with a solution for the shadowing jitter. It should be noted that while the viewmodel jitters in all cases, the shadows only do so in deferred mode (forward rendering shadows seem to be ok)

Any insight on any of these issues would be appreciated. Thanks.

 

Have you considered using a different scale? Something like 1 unit = 10 meters.

 

what is your average object scale?

The regular stuff shouldn't jitter at that sizes unlike your objects don't follow the unity default scales (Unity characters are normally 4 units in height, thats considered about 6 ft I think or the height of an adult human). Cause the problem is not the 'absolute scale of the world' but 'max value / min value', so if you use the default fbx import 0.01 scales and alike you get tiny worlds.

The shadow on the other hand is a thing you might be able to solve without severly limiting the shadow distinct but thanks to dual lightmapping that should be far less of a problem than it might look at first. But that depends on the usage scenario

 

I am using 1 unit = 1 meter. I'm using the bootcamp character which is 2 units high, which is 6 feet.

My objects are imported at 1.0

Scaling it down would not have any affect, I believe it's about floating point resolution. If I scaled the objects down to be 10 times smaller, then the rate at which the jitter would happen would be 10 times sooner. There are probably issues with the transform*view*proj matricies being multiplied and losing resolution and might need to pass through doubles or the transforms generated for the objects need to be offset from 0 0 0 and the camera rendering at 0 0 0 rather than from it's real world position (I think). The lightmaps would a be ridiculously huge (in disk space) for a large world. The fact that forward rendering works and deferred rendering exhibits the jitter issue says to me it's a bug, I'm not sure we have the right access to fix it, however. I appreciate the suggestions thus far though

 

Any control based jitter thats due to float point limitations wouldn't trigger in on desktops before 70k away from 0,0,0 normally.

Do you use custom shaders that chain a large amounts of matrix multiplications that could be opted to less / far less multiplicative operations through usage of basic linear algebra and numerical math principles to reorder the calculations so you can limit this explosion of error from matrix-matrix ops?

After replaying the webplayer here on my MBP 2011 I'm rather confident that the player jitter is not unity itself, because in that case the trees would suffer it too (all goes through the same world transformation etc). Its either a problem of the model (which has a variety of visual bugs so thats very well possible. Something like incorrectly baked modifiers or non reset transformations) or a shader / piece of code that operates on it and modifies it on each step to 'align the hand' or whatever (making it point towards a fictive target point through an numerically instable IK implementation for example)

That won't impact the shadows though, getting that 'under control' can at times be an absolute nightmare

 

There aren't any custom shaders in the webplayer demo.
The model hierarchy could be considered complex, as it uses a full bone rig for the hands with maybe 15 levels. However the jitter is apparent with simply a unity cube parented to the camera. When you parent more cubes to that cube, the deeper you go, the worse the jitter is on the children cubes.

I agree I shouldn't be noticing this at 2-10k away from 0 0 0 but none the less I am. You can try it yourself, simply create a project attach a a heirarchy of cubes to the main camera in first person controller and move to 2k by 2k. The tree jitter happens even as low as 1k by 1k away from 0 0 0


I think the world is infact suffering from it (the trees) however it is not nearly as noticable because the offsets would be less than one pixel once you get a certain amount of units from the camera resulting in no visual feedback of the issue. Also trees are not part of a heirarchy so the issue would further be less pronounced.

 

Here's a demo posted with capsules instead of my model with a heirarchy (from right to left) like this :



http://dl.dropbox.com/u/19800122/jitter2/WebPlayer.html


As you can see you get the same jitter, so it has nothing to do with issues in the model itself. It's very easy to see if you simply tap 'W' quickly, you can see how brutally it jitters around. The demo is at 10k units from 0 0 0

 

Hey Dreamora

We aren't using any custom shaders but your absolutely correct about matrix multiplication. The more children a object has the more it jitters. We've corrected it slightly by using a double version of Matrix4x4, Vector3/4 and quaternion for multiplication and other fp sensitive operations like inverse. Then finally casting the result back to a Matrix4x4 leaves a much better matrix.

However we can only do this for the view ( camera.worldToCameraMatrix ) and projection matrices -- which does help but we have no control over unity's internal world/modelview matrix setup. 70K is pretty easy to achieve at 2k out when you consider proj. matrix * view matrix * world(modelview) matrix * [parent matrices ..n] when actually going through the steps to get the final matrix.

But if you have any ideas on how we could affect the world matrices that'd be great. What we are going to try and do is make versions of the shaders the weapon uses that will avoid the view matrix entirely, treating 0 0 0 as the view matrix origin ect. but that still doesnt fix shadows, where we may have to modify the prepassshadowcollect shader or similar.

The reason it is is more visible/noticeable on the weapon is because its much closer to the camera. It does happen on anything with a somewhat deep hierarchy though. The more matrix multiplication going on ( the deeper child count) the more jitter/error is made. And tree's are not game objects either (afaik) but rather treated specially by the terrain system.

 

I guess you missunderstood me here.
I mean normally when you just leave it as is with normal unity 'humanoid scale' as a base like you have it, then anything within the [-50000,50000] interval on all 3 coordinate axis is normally running fine. Not after the transformation matrices applied, pure unity 3d world coordinates.
No problem, no jitter on the physics and transforms.
Beyond that it becomes a bit hardware dependent yet the transform jitter which always manifests itself first on the rotational component due to the involvement of cos and sin, which is also was plagues your player, is then normally correctable by going the Futurama Way: "We don't move the ship, we move the universe". Might sound stupid but thats how its done, translate the whole world by the inverse of what you wanted to move the player, either continously or at 'virtual grid borders' like MineCraft does it.

Thats though the common thing.

In your case the problem is really the depth of the hierarchy and I would recommend to handle it through something far less deep.
Is there a reason why you need it that way? Is it impossible to handle it with direct transform references on a monobehaviour which controls it or something with at least some broader levels? Perhaps we can offer you a solution to that side of the things which will automatically remove the rest.

Also keep in mind that if you intend to go to mobile with the concept (or even flash) that will not even remotely work anymore like this.

 

What would happen to occlusion culling and navmesh data if you moved the world I wonder..

 

We don't get any sort of NavMesh or Occlusion Root object (or scene root which they are attached to) so I imagine they would flip the hell out and be all "hey I told you I was static".

 

I'm seeing the exact same behavior with a hierarchy of meshes in a world that is 15km x 15km. Though the visual jitter (including the shadow z-fighting) is solved by centering the camera at the origin, rigidbodies will now act strangely unless they are kinematically controlled. This really seems like a huge limitation to me.

Essentially to move the world, not the ship, I have to roll my own physics.

 

Heya,
I have this problem with an airship game I'm building. Sadly unity does not allow you to move the worlds origin.

Some notes:
-At least in VR anything over 9999 meters in unity shakes a lot. I think that unity is losing a decimal in their VR integration as shake happens sooner then it should. I've talked to Oculus about this, they seamed to agree.
See this thread:
https://forums.oculus.com/developer/discussion/comment/343114/#Comment_343114

-Floating point errors are relative, scaling everything down WILL NOT help you. e.g. a 1 meter object at 10000 meters will have the same jitter the same as a 1 cm object at 1000 cm.

There are a few options to get around this but it really depends on your requirements.
1) design your levels with transition points that hide the pop and move your level ONLY when hitting these transition points (particles and such wont move)
- you can't have nav meshes move with the level.
-you can't have occlusion culling, you'll need to set this up manually.

2) split your world up and load new levels when you get too far from origin.

3) Split your visible objects such as the weapons to a separate camera location that does not really move but stays at 0,0,0. This helps get around that relative issue I was talking about above as closer smaller objects are where you first notice the jitter. ( I do this on my airship game and gain a decimal before jitter becomes noticeable)

4) load unload "landblocks" as you move around. Again you will lose occlusion culling. Check out a solution like this:https://www.assetstore.unity3d.com/en/#!/content/36486

5) move the world (I would not recommended this in Unity for most game types)

5) move to a new engine that better handles large worlds

6) get unity source and modify it. ( If you need source this is probably not the right engine for you)