A huge problem！
I am building a huge scene using three.js
So the coordinate value of the item will be very large
for example：position.set(200000, 3, 200000);
When such large coordinate values are set, the model deforms, especially the bone model
But when I set the coordinate values low, they return to normal：position.set(2000, 3, 2000);
Is there a limit on the maximum coordinate value for three.js?
If so, how to make it support such large coordinate values！
Changing the camera near and far values should do the trick.
1 Like
Thank you very much for your reply
But I have already adjusted the camera cropping plane, and no matter how you adjust it, it cannot solve this problem
There is another phenomenon here
When the position coordinates are not set too large, the model can display smoothly no matter how many times I reduce it
However, when I set the position coordinates to a large size and then scale again, the model will continue to deform and become sharper as I scale
Have you tried using updateMatrix() and updateMatrixWorld() on your model after moving to larger distances?
Thank you very much for your reply
I have already done this operation for matrix update, but it did not have any effect
I think this is a flaw in Three’s support for large coordinates, which reminds me of UE5, which was just supported
OK interesting, is the mesh itself inside a parent Object3D? If not have you tried adding the mesh to a parent and moving the parent?
Put it in a scene or a group, I’ve tried it all, and it’s still wrong
Does this need to be related to the skeleton? I am not familiar with the skeleton model, or the weight of the skeleton model will affect the scale of the model?
I’ve had a similar experience in the past. It was caused by the floating precision in the shaders. Too big numbers may cause problems, especially if they take part in calculation of normals, distances and other values that require raising to the power of 2. Scaling does not resolve the issue, because in the shader the values are still big. The only solution at that time was to use highp precision and to reduce the magnitude of the values (in all steps in the calculation). Note, I had to do both things.
Having this said, it does not mean your case is the same. I’m just giving a possible hint… and advice to try and use smaller numbers.
2 Likes
Thank you very much for your suggestion. As you mentioned, I have encountered the conversion between single precision and double precision when using cesium. js. However, I think three. js is not an issue because it is not a jitter issue. The key is that if it is not a bone model, its display is correct. Only bone models have this issue
would it be too crazy to implement your own version of whatever library function is doing bad calculations? that kind of plan often turns out easier and faster than it initially looks like
This plan is indeed good, but our current task is not yet to determine the cause of the problem. If the cause is not determined and the source code is modified directly, it will waste the team’s valuable time. Once the cause is determined, it will be quite simple
1 Like
I think if you adjust these in javascript, you have much more precision.
I think using Logarithmic depth buffer would help
The camera near/far is only helpful if both the camera and models are “far away” (but close to one another) from the origin
Anyways this example shows that very large scenes work fine - three.js examples
So at least you can narrow down the problem by looking at it and trying to see how your scene is configured differently.
From Wikipedia about half-precision floating-point format:
The minimum strictly positive (subnormal) value is 2−24 ≈ 5.96 × 10−8. The minimum positive normal value is 2−14 ≈ 6.10 × 10−5. The maximum representable value is (2−2−10) × 215 = 65504.
Your coordinates are an order of magnitude greater.
1 Like
As a reply to myself, here is a simple demo. There is a column and a plane. If the plane is too big, it jitters (see line 71):
new THREE.PlaneGeometry( 200000, 200000, 1, 1 ),
If I add intermediate vertex, it works fine:
new THREE.PlaneGeometry( 200000, 200000, 2, 2 ),
Live demo here:
https://codepen.io/boytchev/full/abRJMgK
And this is a video of the jittering:
Thank you very much for your suggestion
Logarithmic depth buffer,I have tried and still haven’t solved it
I still think there is a problem with the bone nodes
I understand your question
You have a jitter problem caused by insufficient accuracy
This question should not be in the same category as mine