Solvespace: Poor precision of Z-buffer

[prototype99]

System information

SolveSpace version: 3.0~dcdfdec5

Operating system: Gentoo 17.0

Expected behaviour

I can zoom into fine details in my model

Actual behaviour

In this case, I am trying to insert the Huawei plug into the left plug socket. I very quickly find that zooming in far enough causes artefacts to start appearing, and the 'compass' disappears.

I assume this could be due to the wall being in the way however there seems to be no true way to hide a group, so unless I can find a hidden gem in terms of patches I may need to break up the model more than I really need to just to avoid the camera bug. this problem was also present in 2.3, hence I tried building a later version to see if the issue was fixed in the upcoming release.

Additional information

room-plan.zip

[whitequark]

I assume this could be due to the wall being in the way however there seems to be no true way to hide a group

"Suppress this group's solid model" ?

[whitequark]

More generally, the issue you're hitting is poor Z-buffer resolution, and I don't know of any good way to solve it.

[Symbian9]

is poor Z-buffer resolution, and I don't know of any good way to solve it.

As I know, in Blender if projection set to "Orthographic" you will never got such issue.

[prototype99]

I assume this could be due to the wall being in the way however there seems to be no true way to hide a group

"Suppress this group's solid model" ?

ah admittedly I didn't see that

More generally, the issue you're hitting is poor Z-buffer resolution, and I don't know of any good way to solve it.

I did wonder if going through the effort of expanding every measurement to millimetres (I've been doing it in centimetres because I'm using a tape measure) would help, but then the same issue doesn't manifest on the individual models prior to assembling.

[Symbian9]

I did wonder if going through the effort of expanding every measurement to millimetres (I've been doing it in centimetres because I'm using a tape measure) would help,

SolveSpace has no "centimeters" dimensions units; only "milimeters", "meters" or "inches".

but then the same issue doesn't manifest on the individual models prior to assembling.

You could import parts in assembly scaled (so no need remodel each part from mm to m manually)

[whitequark]

More generally, the issue you're hitting is poor Z-buffer resolution, and I don't know of any good way to solve it.

That has nothing to do with the units or dimensions in your design--it's purely a rendering artifact that depends on the relative sizes and distances with regards to the viewport.

[prototype99]

SolveSpace has no "centimeters" dimensions units; only "milimeters", "meters" or "inches".

this is true, so dimensions are technically entered at 1/10th scale

That has nothing to do with the units or dimensions in your design--it's purely a rendering artifact that depends on the relative sizes and distances with regards to the viewport.

I think I understand what you're saying. so basically the renderer internally uses relative measurements based on the largest measurement, thus it treats the zoom level as such a small fraction that errors are more likely to happen?

[whitequark]

so basically the renderer internally uses relative measurements based on the largest measurement, thus it treats the zoom level as such a small fraction that errors are more likely to happen?

More or less, yes. See this page, and in particular this answer.

I would classify this as a bug in SolveSpace, but not a high priority one, or one with a straightforward fix. There are a few relatively easy solutions one could try, like floating point Z-buffer (easy to add, poor hardware support, unexpectedly low payoff because of precision issues elsewhere in the rendering pipeline) and logarithmic Z-buffer (a bit more complex to add since it requires changes to shaders). Any enthusiastic graphics programmer who would like to help is welcome to look into this.

[Evil-Spirit]

Also, this can be projection / modelview matrix issue. not correct Znear / Zfar or loosing precision during computation.