Repository navigation
Poor precision of Z-buffer #535
Description
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.
Activity
whitequark commentedon Dec 23, 2019
"Suppress this group's solid model" ?
whitequark commentedon Dec 23, 2019
More generally, the issue you're hitting is poor Z-buffer resolution, and I don't know of any good way to solve it.
sophietheopossum commentedon Dec 23, 2019
ah admittedly I didn't see that
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.
whitequark commentedon Dec 23, 2019
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.
sophietheopossum commentedon Dec 23, 2019
this is true, so dimensions are technically entered at 1/10th scale
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?
[-]camera doesn't work as expected / no option to actually hide groups[/-][+]Poor precision of Z-buffer[/+]whitequark commentedon May 10, 2020
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 commentedon May 13, 2020
Also, this can be projection / modelview matrix issue. not correct Znear / Zfar or loosing precision during computation.
alken1t15 commentedon Nov 3, 2026
Hello! I'm interested in investigating the Z-buffer precision issue. Is this issue still relevant and available for a new contributor to work on, or is someone already working on it? If it is available, may I take it on and discuss the approach here before starting the implementation? Thank you!