Fri, 04/28/2017 - 05:13
We have a point cloud that when displayed in a position near 0,0,0, look pretty good (see image 1), but when translated far from the origin, let's say 50000,50000,50000 the visual appearance is really jerky (see image 2).
We are using a Graphic3d_ArrayOfPoints to display those point, and at some point the coordinate (which are double precision) are cast to a single precision float (see image 3). Image 4 show the lost in precision and probably why the display in image 2 is jerky.
So my question is: it's there another way, a workaround or something I am missing that will allow me to have this point cloud near the 50000,50000,50000 coordinate look like the one in image 1.
Fri, 04/28/2017 - 06:49
We had similar issue - see here https://tracker.dev.opencascade.org/view.php?id=26863. The referred issue (#24393) apparently contains more details but is not publicly accessible. Perhaps the OCC team could shed some light in this thread.
Fri, 04/28/2017 - 10:31
We've sent to you a private reply - please, check your mailbox.
Sat, 04/29/2017 - 13:31
As most of 3D engines, OCCT 3D Viewer uses single precision floats for vertex data and for matrix operations on GPU side. There are important considerations upon this choice - true double precision floats become available on GPU not a long time ago and still might be unavailable (e.g. on mobile devices).
And even hardware supporting double precision, might do this with huge performance penalty (regardless higher memory footprint) - it might be 16 and 24 times slower on GPUs designed for games (professional GPUs usually have better coefficients; probably performance of game cards is truncated intentionally in this aspect), see small overview here:
Thus, GPU performance is major argument why NOT using double precision floats on GPU without really good reasoning.
There is, however, much more simple argument for not doing this - in fact, single precision float is more then enough for most applications (for visualization purposes first of all). Application should just define the sensible limits for the model area - considering the precision / size of minimal element, you can estimate the maximum / minimum zoom level as well as panning limits in 3D view.
But even if application needs to go further, it is still possible to keep using single precision float for presentation data with some extra tricks, known as Relative To Center and Relative to Eye techniques. Many 3D engines support such trick - here is how it defined as glTF extension. OCCT 7.1.0 supports this kind of functionality, but to take effect application needs to be adapted.
Tue, 05/02/2017 - 10:53
Thank you very much for offering insights and links.
When you are referring to
do you mean use of Z-layers (par. 4.4.15 in Visualization User's Guide) or something else ? Do you happen to have demonstrating these capabilities in DRAW/ViewerTest ? I went through its use and did not find demonstration of that specific use case but chances are that I can be missing something, so would appreciate your reference.
Tue, 05/02/2017 - 11:38
So far there is only one test case tests/v3d/glsl/double_precision playing with new Layer option.
Tue, 05/02/2017 - 12:05
Sat, 04/29/2017 - 14:31
Thank you for the replay Roman and Kirill!
You're right Roman, we have the exact same behavior with the viewing part and the selection part.
Using PrsMgr_PresentableObject::SetLocalTransformation() with a Location near the center of the point cloud, we solve the viewing part (but not the selection part). So one of our use case is correctly viewed now using that technique.
I agree with Kirill that single precision float is more then enough for most applications, even where I work, those use cases that I am talking about are not the majority yet, but we are dealing with team more and more frequently now.
Another use case can't be improve using this technique. To reproduce the use case, simply distribute 20 millions points over a 20 millimeters line, this will give you a lot of points over a small area! Now, the problem appear again: one end of the curve is fine (see image 1) since it is close to the Location, the other end (see image 2) show the same problem as before.
So I wonder if the Relative To Center and Relative to Eye techniques could be use here. If so, I guess the OCC Team could help us in that direction?
Sat, 04/29/2017 - 14:51
Yes, for sure - OCCT team will help using existing features or might improve OCCT, if needed for new use cases.