This means that three.js cannot carry large-scale scene space
This is not the case - this is just the nature of floating point value precision and the fact that GPUs use 32bit numbers in calculations.
You have a jitter problem caused by insufficient accuracy
This question should not be in the same category as mine
The source of the problem is fundamentally the same. You’re using very large values in calculations where there is insufficient precision.
You can see the same type of issue if you set an instanced mesh matrix to use a large translation, as well (see here). You’ll have to be aware of which matrices are uploaded in which form to the GPU in order to address this generally and ensure that as much of the large value matrix multiplication is happening in Javascript where 64bit precision is used. Both bone world matrices and instance matrices are uploaded to the GPU for calculation so you’ll want to adjust your scene to make sure those values are closer to 0 if you’re seeing this kind of jitter.
4 Likes
one detail, not the bone model, does not have this issue
one detail, not the bone model, does not have this issue
As I’ve explained - this will only occur when matrices of large values are used in calculations on the GPU. The mesh world matrices model-view matrices are computed in Javascript where 64 bit floats are used so this will not as easily occur with regular mesh objects.
If you have further problems you’ll have to make an effort to share a working example of the issue you’re having. You’re leaving a lot of guessing to people who are trying to help you.
1 Like
Why doesn’t this issue appear in the official three.js editor? I adjusted the coordinates of this sphere to (0, 5000000000000.000, 5000000000000.000), then double-clicked on the sphere, and the camera automatically focused on the sphere, but I did not see any incorrect model.
Blockquote
Edit fiddle - JSFiddle - Code Playground
I would guess that because as @gkjohnson explained… the modelView matrix is computed on the CPU with 64bit floats… so by the time it gets into the shader, the matrices are now back in the usable range of 32 or 16 bit float. modelView matrix is the matrix of the model relative to the camera, so it won’t be 5bajillion units away… it will only be camera position - object position units away.
2 Likes
You are right
---- Replied Message ----
From | Michael Schlachter via three.js forumnotifications@threejs.discoursemail.com |
- | - |
Date | 04/03/2024 17:03 |
To | firstgis@163.com |
Cc | |
Subject | [three.js forum] [Questions] Large coordinates |
| manthrax
April 3 |
I would guess that because as @gkjohnson explained… the modelView matrix is computed on the CPU with 64bit floats… so by the time it gets into the shader, the matrices are now back in the usable range of 32 or 16 bit float. modelView matrix is the matrix of the model relative to the camera, so it won’t be 5bajillion units away… it will only be camera position - object position units away.
Can i ask how you solve this problem finaly?
@samsRich
@Manthrax @PavelBoytchev @gkjohnson have already described it. This is an issue of precision. The CPU works with 64 bit, but the GPU only works with 32 bit. This means you can resolve cm differences from Earth on Pluto in the CPU. But the GPU with its 32 bits cannot even resolve meter differences on the earth’s surface when viewed from the center of the earth.
But this is not an insurmountable hurdle! The solution are coordinate transformations. The GPU is accurate to the 7th place but everything that comes after that are rounding errors. The fact that the GPU only works with 32 bits makes it faster but limits the precision range. That’s why as a developer you have to carry out coordinate transformations when working with larger scales and everything is fine. However, not everyone likes coordinate transformations as they can be quite demanding.
@wayne2000 you can work with very large numbers without any problems. The problems come when you want to resolve differences starting from the 7th digit. You can use 500000000000 without any problems. The GPU can distinguish this from 500000100000 but no longer from 500000001000. This then leads to exactly the ugly effects that were previously posted.
Here is a screenshot from my app in which you can see how huge scale differences harmonize.
The sun is a 3D sphere object with a radius of almost 700,000 km at a distance of approximately 220 million km.
Mars is full scale (3390 km radius). Without coordinate transformation, the surface would look exactly like the image with the totally deformed model above. And the surface would never be able to be texturized with a UV range of 0 to 1 because I need the range (20,000 km) to be resolved down to the millimeter range. So 1 / 20000000000. The GPU cannot resolve such small differences.
That’s why it’s important to be aware of the precision limits as a developer. So if you want to avoid coordinate transformations, you have to make sure that the differences you want to resolve don’t become too small. This applies to both, very large and very small numbers. What is crucial is the difference in the values to be distinguished. And since the matrices are also rounded as manthrax had already mentioned, the precision can slips from the 7th to the 6th place.
GPU precision is one of the most challenging topics. The easiest thing is to avoid large scale differences.
Here an example from me:
The camera is over 1 million away from the origin in the z direction. x and y are almost 0. The model is about 20 in the z direction in front of the camera. Since the x and y coordinates of the camera are small, the differences between the x and y coordinates of the model relative to the x and y of the camera are quite large so that there are no problems in x and y. With a camera position of 10000000 and the model position 9999980, the vertex position differences of the model in the z direction are far too small to be resolved by the GPU. And that’s why they jump to the next value that the GPU can understand. If I were to move the camera to z equal to 1000 and the model moved with it, it would look right because the GPU could resolve the differences again.
It is therefore best to avoid large scales. Otherwise, you will unfortunately not be spared more complex transformations. I hope this helps understanding
5 Likes
