You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OpenCSG transforms vertices (and hence produces depth values) using the legacy OpenGL fixed pipeline.
On common GPUs (Tested modern Intel iGPU and nVidia), the fixed function pipeline produces slightly different vertex positions than the programmable pipeline. Since OpenCSG relies on applications rendering final images using a GL_EQUAL depth test, this causes z buffer tearing for applications rendering using a programmable pipeline.
A valid bug. But in OpenCSG, just switching to a different of pipeline will not help, since this would introduce the same problem for applications using the fixed pipeline.
Probably this means that there must be some kind of hook to control how OpenCSG transforms the vertices. That hook would optionally activate some programmable shader.
Question is whether one hook is sufficient, and if this must be fully controlable from the calling application.
Yeah, there are still, but hopefully very few, apps who still use legacy OpenGL. A compile-time flag might be the easiest option, but that will cause challenges for packaging, but will work for embedding.
An alternative to a hook could be to add an initialization function to OpenCSG. That could also help solve the GLEW issue (#10).
OpenCSG transforms vertices (and hence produces depth values) using the legacy OpenGL fixed pipeline.
On common GPUs (Tested modern Intel iGPU and nVidia), the fixed function pipeline produces slightly different vertex positions than the programmable pipeline. Since OpenCSG relies on applications rendering final images using a GL_EQUAL depth test, this causes z buffer tearing for applications rendering using a programmable pipeline.
For more info, see openscad/openscad#4595
The text was updated successfully, but these errors were encountered: