This would be an easy enough algorithm if OpenGL was a software library.

OpenGL is not a software library.

If graphics hardware does not support concave polygons, then no matter how much you may want OpenGL to support concave polygons, you can't have it.

The only way to support concave polygons is therefore to run them through a preprocessing stage that converts an arbitrary concave polygon back to multiple convex polygons. And solutions already exist for that.

This request, coupled with your previous, demonstrates that you don't actually understand what OpenGL is. It may also be the case that you have some very specific problems, you've chosen OpenGL as a solution, and now you're finding that OpenGL is a bad fit for those problems. If that's so, then rather than wishing a bad fit was made good, you should instead be looking for a more appropriate solution.

OpenGL does already support "konkave" polygons. You can make your polygons concave all you want.

So long as they're triangles.

Quads and general GL_POLYGON primitives were removed in OpenGL 3.1. Yes, compatibility mode still has them around. But the ARB is not going to make any changes to OpenGL just for some compatibility-only feature.

The only way to support concave polygons is therefore to run them through a preprocessing stage that converts an arbitrary concave polygon back to multiple convex polygons. And solutions already exist for that.

Well, OpenGL's tessellation is a hardware facility, that may be used for exactly such preprocessing. Or you can use stencil buffer. But yes, there's no native implementation of such "am easy algotythm"(i couldn't resist opening hidden OP's post. and it totally worth it) in OpenGL.

for OP:
Because almost no one actually needs it in realtime rendering and it requires either significant changes to rasterization pipeline or tessellation(which you can utilize yourself both software and hardware).

Originally Posted by mhagain

It may also be the case that you have some very specific problems, you've chosen OpenGL as a solution, and now you're finding that OpenGL is a bad fit for those problems. If that's so, then rather than wishing a bad fit was made good, you should instead be looking for a more appropriate solution.

OP is not likely to be an actual OpenGL programmer. Otherwise he would be busy actually doing something, instead of searching for flaws in API. which he fails miserably at, because of absolute lack of knowledge of any graphical API and rendering in general.

Actually it is not; triangulation of a closed non-intersecting line loop can still be tricky. I invite you to do a google search to see how deep the rabbit hole is for triangulation (admittedly triangulation of the fill of one closed line loop is much simpler than the triangulation of multiple potentially intersecting line loops). But to give you an idea, for triangulating a simple polygon, the simplest algorithm of "cutting ears" runs in O(n^2), using monotone polygons runs in O(n log n); getting faster than O(n log n) gives pretty damn complicated algorithms.

I think the OP's issue is the following: the OP does not realize that OpenGL is not a library but rather a standardized interface to GPU's. I suspect once the OP learns that, the OP's posts won't be quite so bad.

I said it before and I'll repeat - no matter how much you want it, no matter how much you think it's a "simple algorithm", if hardware cannot do it, then it's not a suitable feature.

To be perfectly fair (even though this idea doesn't deserve it), it is entirely doable on 4.x-class hardware. The OpenGL implementation could use a compute shader to implement the division, write out the triangles to a buffer, and then feed that buffer in to the rendering pipeline.

Now that's way too high level for OpenGL to do, and it's really stupid besides (since you can do it just once on the CPU). But it could be done.