Open GL should support konkave polygons directly

Open GL should support concave polygons directly.
I think it´s an easy algorythm which should be no problem.

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.

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).

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.

I think it´s am easy algotythm which should be no problem.

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.

Actually it is !

triangulation of polygons
http://narfation.org/alggeo/triangulation.pdf
is too overelaborated

a simple algorythm can render directly concave polygons

It still doesn’t change the fact that OpenGL is NOT a software library.

You don’t “implement algorithms” in OpenGL. All that OpenGL does is tell your graphics hardware what to do. Your graphics hardware does what you tell it.

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.

What part of that is difficult for you to understand?

“… now you have two problems” :wink:

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.

ok,
OpenGL should support concave polygons directly in the Graphics-Hardware.
To render them is as easy as triangles.

OpenGL only support triangels in the hardware, because it is thought, that they
are easylier to be renderd than concave polygons, but in fact, the concave polygons can be rendered as easy as triangles.

OpenGL should support concave polygons directly in the Graphics-Hardware.

The hardware itself has to support stuff for OpenGL to be able to expose it in the first place. You could expose all you want in OpenGL, but if the hardware hasn’t a way to do it directly, you’d need to either emulate it in the hardware or do it on the CPU. As Alfonse said, this could probably be done - the fact that it’s not there kind of speaks for itself …

concave polygons can be rendered as easy as triangles

From where did you get this? Do you guess or do you know? What are your sources?

I can’t believe I’m getting sucked in again …

From me and myself.

I know it.

I developed the sourcecode.

[QUOTE=thokra;1254205] As Alfonse said, this could probably be done - the fact that it’s not there kind of speaks for itself …
[/QUOTE]
I think, we are talking about the next release/releases.

I think, we are talking about the next release/releases.

We are. What I’m saying is that if a primitive type representing concave polygons was considered feasible by the ARB, it probably would already be in the spec by now. In contrast, the ARB has removed a great deal of primitive types in the past.

[QUOTE=LuisAK;1254203]ok,
OpenGL should support concave polygons directly in the Graphics-Hardware.
To render them is as easy as triangles.[/QUOTE]

This is utterly meaningless.

OpenGL cannot “support” anything “in the hardware”. That’s not the way things work.

The way things work is roughly like this:

Hardware has certain capabilities. These capabilities are decided by the hardware manufacturers with occasional input from others.

OpenGL is a “software interface to graphics hardware”. In other words, it provides a way to access those capabilities from software.

Hardware manufacturers implement the OpenGL specification in their drivers. You make OpenGL calls. The driver converts those calls to something that the hardware understands, then passes them on to the hardware. The hardware executes the calls.

But the fundamental requirement - that the hardware must support a feature - is absolutely nothing to do with OpenGL. It’s entirely up to the hardware manufacturers.

Do you see where this is going?

There’s no point whatsoever lobbying the OpenGL forums for this.
There’s no point whatsoever lobbying the ARB for this.

The people you need to be talking to are the hardware manufacturers. You need to talk to AMD. You need to talk to NVIDIA. You need to talk to Intel. This is nothing to do with OpenGL; you need to ask the hardware manufacturers to support concave polygons in their hardware. And you need to persuade all of them to implement concave polygons in a consistent manner. Because otherwise you’re just creating noise and wasting your own time. You want concave polygons? I’ve told you what to do. Go do it.

OK,
the Graphics Hardware should support the rendering of concave polygons
Whereby the Graphics Hardware isnt only hardware, there´s a CPU, memory and software.
And it should be easy to implement this in this Graphic-Software.

Aren´t there any guys from the ARB or companies like AMD, NVIDIA or INTEL reading this threads ?

Aren´t there any guys from the ARB or companies like AMD, NVIDIA or INTEL reading this threads ?

Are there? I highly doubt that. Why?

Because of poorly thought out suggestions like yours.

Who exactly is this going to help? The transformation of concave polygons into a series of triangles is simple enough that everyone who needs it already has the code for it. Everyone who needs it does it as a simple pre-processes to their input data, executing it before handing it off to OpenGL.

Therefore, the only legitimate benefit of this (FYI: because someone is too lazy to do it as a pre-process is not a legitimate reason to ask for something) is if you’re dynamically generating concave polygons via some process, and you are doing this on the GPU. Therefore, you want the GPU to be able to accept these polygons directly, without having to do a GPU-CPU copy to process them, then a CPU-GPU copy back.

And if that’s the case, there are two perfectly viable solutions:

1: Have your GPU process that generates the data generate triangles instead of concave polygons. That is, put whatever triangulation algorithm into the GPU process.

2: Do what I said earlier. Write a compute shader that takes individual polygons and converts them into a sequence of triangles. It’s not the easiest thing in the world to write, but it’s doable.

In short, this is a problem you can solve on your own; there is no need for a specific hardware feature or solution, besides the fact that you want it. This isn’t even like your suggestion for a font system; that at least has some clear benefits to it. It’s not going to happen for practical reasons, but there is at least an argument to be made for it. There was obvious utility to having the feature, even if it’s not appropriate for OpenGL. This concave polygon thing is just personal wishlist crap that would help nobody but yourself.

Why should the ARB, AMD, NVIDIA, or Intel waste their precious time reading suggestions that are this useless? People suggesting pet features like this is exactly why they don’t read these threads. Too much noise and not enough signal.

[QUOTE=LuisAK;1254220]OK,
the Graphics Hardware should support the rendering of concave polygons
Whereby the Graphics Hardware isnt only hardware, there´s a CPU, memory and software.
And it should be easy to implement this in this Graphic-Software.

Aren´t there any guys from the ARB or companies like AMD, NVIDIA or INTEL reading this threads ?[/QUOTE]

You’re still not getting it, are you?

You claim that concave polygons are just as easy to rasterize. Got news for you - they’re not.

Triangles have certain properties that make them ideally suitable. Some of these are common to all convex polygons, some are particular to triangles. You can’t say any of this about concave polygons.

[ul]
[li]Interpolating texcoords or colours across a triangle is just a matter of taking a weighted average from 3 points. [/li][li]All points on a triangle are guaranteed to lie on the same plane. [/li][li]Filling a triangle can be as simple as starting at one edge and drawing a line until you meet another edge. [/li][li]A triangle can be arbitrarily split in two and the result is two more triangles, the very same primitive type. [/li][/ul]

This can all be accelerated in hardware, so you need to drop your obsession with “in software” right now. An “in software” approach already exists for concave polygons - it’s called GLU tesselation and all OpenGL implementations support it. But all that it does is convert the concave polygon to triangles, which are then dealt with by the hardware. “Graphics hardware isn’t only hardware” is one of the most nonsensical things; it’s either hardware or it’s not, and triangle rasterization is currently implemented in hardware. If you want a serious competitive alternative, then it must also be implemented in hardware, otherwise forget about it.