Open GL should support konkave polygons directly

[mhagain]

in #25 you write:
"...or 8 years in the past. This happened for every major OS a long time ago."

and in #27 you write
"Because the "simple graphics API" is slow and implemented in software."

so that you show in #27 that your own statement in #25 is wrong !

in #25 :
"...or 8 years in the past. This happened for every major OS a long time ago."
-> This didn´t happen ! OK ?

No.

The "simple graphics API" you're referring to is GDI, which Windows maintains support for on account of backwards compatibility, but which it no longer uses for it's main drawing.

Your´e talking about the present, I´m talking about the future - what could be. (Suggestions for the next release)

So you're talking about taking everything that OpenGL is and has worked towards for the past 20 years and throwing it out?

Really, you have no idea what you're talking about. You should learn this stuff before you go mouthing off.

You don't want OpenGL, you want a high-level abstraction. So just use a high-level abstraction instead, OK?

[Nowhere-01]

...

Why do you keep responding and elaborating to someone, who clearly ignores all of your explanations, refuses to be educated(keeps assuming, that he knows everything better) and keeps posting repetitive, utter nonsense and mumbling? It's obvious, that he's either a troll or a complete dumbass. It's also so clear, that he's not trying to learn API or to produce something. Do you really want threads like this on this forum, especially in suggestions?

I said exactly the same thing in his previous topic about 6 month ago. And now it's the same. A bunch of over-tolerant people trying to educate an obvious troll or extremely dense, ignorant person. And why do you want any of them educated or treated well? Why do you educate in the first place? Maybe you're helping potential developers, because you want OpenGL to be more popular and used in some future projects and to have decent, mature community and support? Do you think he's able to contribute to that? You keep writing thousands of words, keeping attention to this stupid thread, instead of showing ability for good judgment and just saying GTFO in response to ovid ignorance and thickness. It's good, then community shows no tolerance for bullshit, it keeps itself clean and intelligent that way. And if he's actually not a troll, he may review his attitude and try to understand things he's being told over and over. Why don't you just report him for trolling\flaming\flooding on suggestions forum and wait until these threads are (re)moved? And spend your time on someone, who's actually willing to be educated and has any potential.

[kRogue]

This is my last post to this thread and as a rule now, I am not going to try to help you LuisAK; you have repeatedly ignored what anyone has said, you have repeated the same statement although multiple contributors have given counter arguments for those statements.

If you really want to suggest functionality to find its way into the hardware here are some tips:

• Have a clear way to implement said functionality in a highly parallel fashion
• Have a clear notion of what the input and output are. Your request for "draw concave polygons" in no way addresses what the output should be: what are the interpolates, what happens if the line loop defining the polygon is self intersecting.
• Be aware of various constraints, i.e. the tradeoff between flexibility and speed; generally speaking more flexible implies slower.

Nothing of what you have suggested (font support or rendering of simple polygons beyond triangles) has done ANY of the above.

Going further, to repeat what mhagain said: OpenGL is a low level API; it is supposed to map naturally and directly to GPU commands. If one looks at GL, one sees essentially that each command is one of the following:

• Define data store (be it buffer objects or textures)
• Set values of data store directly (i.e. glTexSubImage2D for example)
• Set GL state to determine from what data stores to fetch data (binding textures and buffer objects for example)
• Set GL state to what data stores to write (framebuffer objects and transform feedback for example)
• Set GL state for parameters of fixed functionality (depth test, stencil test, color, depth, stencil masking and blending for example)
• Specify how to process input vertex stream into values for the data store rights, i.e. define GLSL programs
• Limited query (samples passed, syncs)
• memory barriers (for random read/writes introduced in GL4 hardware).
• Execute draw commands

None of that is high level except for the creation and compiling of GLSL (and that is implemented on CPU, with compiles caches often and is done only once per GLSL program/shader essentially).

There are plenty of interesting places to explore; for example that which is fixed function how much can it be made more flexible.

Other issues are related to API-niceties to make the GL API easier to work with (almost always after a new spec is release a begging for DSA comes).


I am out of this now; this is my last post to ANY thread you start LuisAK.

[LuisAK]

I am not going to try to help you LuisAK;

I didn´t ask for help here, I just talked about suggestions.

And if you have a look PhysX, you can see, that the graphics hardware ist far away from low-level abstraction

[LuisAK]

To render concave polygons directly is very easy.
Here an example:

This concave polygon is rendered on pixel-level how it could be done by the graphics hardware
as efficient as triangles. Of course, there are a few little aspects in my algorithm, to detect the cross-points.
But in summary its much more efficient than triangulation.

My evidence is provided.

[Alfonse Reinheart]

Because I enjoy feeding idiocy on this forum:

My evidence is provided.

Drawing a picture is not evidence. Anyone can draw a picture of an algorithm. That's not evidence that this algorithm can be implemented in hardware or implemented efficiently in hardware.

Unless you demonstrate an understanding of how this stuff is implemented in hardware, you cannot claim any kind of knowledge of whether this could be implemented reasonably.

And to preempt your linking me to PhysX or some other GPGPU library, let me stop you right there. That's all just executing programs on the GPU. You are not talking about shaders. You are talking about changing the rasterizer. The rasterizer is not done via shaders; it's hard-coded into the GPU.

What you are talking about is the equivalent of wanting to change how the division opcode on a CPU works. The fact that you can make the CPU do amazing things with a good compiler or other system has nothing to do with the feasibility of whatever else you wanted.

Lastly, you continue to miss the important question. Could IHVs implement this? Absolutely. WHY SHOULD THEY?! Nobody except you wants this. This solves a problem that nobody except the most lazy programmers have. Why should IHVs invest precious transistors solving a problem that nobody needs solving? That will be useful for one thousandth of a percent of their customers.

Why should they invest in this rather than anything else they could be doing? Like programmatic blending (rather than the user-heavy image load/store form). And so forth.

Every time you post a response that doesn't address this important question, I will simply repeat the question.

[LuisAK]

Because I enjoy feeding idiocy on this forum:

Ok, when arguments go, you continue with insults.

Drawing a picture is not evidence. Anyone can draw a picture of an algorithm. That's not evidence that this algorithm can be implemented in hardware or implemented efficiently in hardware.

Where sould be the problem ?
You draw some lines ( something the hardware can already)
and then you fill the pixels inside with color (something the hardware can already do with triangles).

[LuisAK]

It could be done efficiently:

Also in the "Hardware" because there is only a very little trick.

[mhagain]

It could be done efficiently:

Also in the "Hardware" because there is only a very little trick.

Drawing flat-shaded polygons that are fully on-screen is nice. You're still completely failing to answer these questions:

• How do you interpolate texcoords, colours and other vertex attribs across a concave polygon?
• How do you split a concave polygon that's partially clipped?
• How do you deal with cases where vertices of the polygon are not all on the same plane?

These are utterly trivial with triangles. If you're claiming that concave polygons are just as easy, then you must have answers to these questions too. Or did they even occur to you?

[LuisAK]

[*]How do you interpolate texcoords, colours and other vertex attribs across a concave polygon?

You can interpolate them by the surounding rectangle

[*]How do you split a concave polygon that's partially clipped?

Therefore the stencil-buffer is existing

[*]How do you deal with cases where vertices of the polygon are not all on the same plane?

When they are projected to the screen they are all flat, but normaly they are on a plane.

These are utterly trivial with triangles. If you're claiming that concave polygons are just as easy, then you must have answers to these questions too. Or did they even occur to you?

Whats that ?