Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AC: Triangulate quads and polygons #1302

Open
wants to merge 1 commit into
base: OpenSceneGraph-3.6
Choose a base branch
from

Conversation

amalon
Copy link

@amalon amalon commented Feb 15, 2024

I'm a bit unclear whether there's any interest in accepting fixes, especially for use of newer GL features, and what branch it makes sense to apply them to, so I've just left this one on OpenSceneGraph-3.6.5 for now. It stems from me playing around with instanced geometry shaders for single-pass multiviewport rendering in osgXR / FlightGear (where work is ongoing to switch to GL core profile), since mesa on my AMD GPU doesn't support the OVR_multiview2 extension.

The AC plugin creates geometry containing quads and polygons, neither of which can be handled with geometry shaders, resulting in GL_INVALID_OPERATION errors from glDrawElements when geometry shaders are in use.

This is fixed by generating a single DrawElements of triangles from both _triangles and _quads (triangulating the quads as if each is a triangle fan), and treating convex polygons (in _polygons) as triangle fans.

Concave polygons (in _toTessellatePolygons) are already converted into triangle modes by a Tessellator object.

The AC plugin creates geometry containing quads and polygons, neither of
which can be handled with geometry shaders, resulting in
GL_INVALID_OPERATION errors from glDrawElements when geometry shaders
are in use.

This is fixed by generating a single DrawElements of triangles from both
_triangles and _quads (triangulating the quads as if each is a triangle
fan), and treating convex polygons (in _polygons) as triangle fans.

Concave polygons (in _toTessellatePolygons) are already converted into
triangle modes by a Tessellator object.
@robertosfield
Copy link
Collaborator

I'm so busy with the VSG project and associated client work right now I don't have time to review and merge submissions and make releases for the OSG. Once I have some quiet time I will look at making a new OSG-3.6.6 release from the OSG-3.6 branch, and an OSG-3.8 release after that.

Projects looking at porting to OpenGL Core Profile would probably be better off just moving the VulkanSceneGraph, it support for shader based scene graphs is far better than the OSG. OpenGL is a dead end, not touched by Khronos since 2017. Vulkan is the future, it's much faster and more capable than OpenGL. The VSG is much faster than the OSG even before adding in the Vulkan advantage.

@amalon
Copy link
Author

amalon commented Feb 15, 2024

Okay, thanks. No problem.

Yeh I get that Vulkan is the future. The core profile is I believe needed for the FG pretty HDR pipeline to work on certain GPUs/drivers, and is a much smaller transition than to vulkan/VSG.

@robertosfield
Copy link
Collaborator

OpenGL Core Profile was a mistake that Khronos made, screwing over legacy applications and forcing them to break old code and rewrite to something that wasn't really fit for purpose. It was meant to get OpenGL closer to what Vulkan is now but fell far short of actually support modern hardware in the way that it actually works.

Far better would have been to maintain OpenGL for legacy applications without breaking them and just get folks to adopt a modern Vulkan if they wanted modern hardware support.

Porting to Vulkan/VulkanSceneGraph is a bigger task but the end result is far better and has a future. OpenGL Core Profile is just as much as dead end as the rest of OpenGL.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants