Improve display appearance of translated object - Forum Open Cascade Technology

Francois Lauzon
Fri, 04/28/2017 - 05:13

Forums:

Hello,

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.

Thanks,

Francois.

Attachments:

Roman Lygin
Fri, 04/28/2017 - 06:49

Hi Francois,

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.

Thank you,

Roman

Forum supervisor
Fri, 04/28/2017 - 10:31

Hello Francois,

We've sent to you a private reply - please, check your mailbox.

Best regards,

Forum supervisor

Kirill Gavrilov
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:

For example, on a GTX 780 Ti, the FP64 performance is 1/24 FP32. Which means in an ideal case, running the same code by only changing float types to double types, would yield the single precision run time to be about 1/24th of the double precision time (time(FP32) = time(FP64)/24).

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.

Roman Lygin
Tue, 05/02/2017 - 10:53

Hello Kirill,

Thank you very much for offering insights and links.

When you are referring to

OCCT 7.1.0 supports this kind of functionality, but to take effect application needs to be adapted.

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.

Best regards,

Roman

Kirill Gavrilov
Tue, 05/02/2017 - 11:38

So far there is only one test case tests/v3d/glsl/double_precision playing with new Layer option.

Roman Lygin
Tue, 05/02/2017 - 12:05

Thank you!

Francois Lauzon
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?

Thanks,

Francois.

Attachments:

image1_0.PNG

image2_0.PNG

Kirill Gavrilov
Sat, 04/29/2017 - 14:51

If so, I guess the OCC Team could help us in that direction?

Yes, for sure - OCCT team will help using existing features or might improve OCCT, if needed for new use cases.