It can be even simpler: fill one or more rectangles which collectively cover the triangle, discarding a fragment if any of its barycentric coordinates are negative.
To render a concav Polygon is so simple:
- Draw a rectangle around the concave polygon.
- Draw the polygonlines.
- Scan the rectangle fom xmin to xmax and in this loop from ymin to ymax
- If you pass the first line you get inside the polygon, at the next line you get outside an so on …
- Inside, you set the pixels, and so the concave polygon will be drawn.
To render a concav Polygon is so simple:
- Draw a rectangle around the concave polygon.
- Draw the polygonlines.
- Scan the rectangle fom xmin to xmax and in this loop from ymin to ymax
- If you pass the first line you get inside the polygon, at the next line you get outside an so on …
- Inside, you set the pixels, and so the concave polygon will be drawn.
I am going to try (again) to help you LuisAK.
[ul]
[li]What are going to be the values of the interpolates? Not only does one need to cover correctly where a polygon is on the screen, one needs to compute the interpolates on the interior. Here is an example, you have a simple polygon comprising of N points (p[1],p[2], …, p[N]) each vertex has a color value given by (c[1],c[2],…,c[N]); i.e. vertex p[i] has color c[i]. For a point within the polygon what is the correct color value to use? For the case of a triangle one uses essentially barycentric coordinates.[/li][li]The algorithm you give is not exactly efficient as it involves essentially counting edge crosses iteratively. It does not parallize well and thus maps poorly to a GPU. It is essentially a poor man’s edge counter. If you detect edge crosses by tests against drawing the edges, that algorithm is going to break; if you do an analytic test, extra care is needed for horizontal or vertical edges (depending on if by cross you mean cross by changing y or changing x) and additional corner cases that come along the way.[/li][/ul]
Now if you really, really want to draw any polygon in GL now you can one of the two:
[ul]
[li]Triangulate it and then feed those triangles to GL[/li][/ul]
OR
[ul]
[li]use the stencil trick to compute the interior of a polygon. This trick also works with general paths with some limitations. The trick is this: 1) clear the stencil buffer. 2) pick a point, any point will actually work call this point P. Set the stencil operation as invert. Draw a triangle fan centered at P using the vertices of the polygon for the non-center point of the fan, ie. draw the triangles (P,p[1],p[2]), (P, p[2], p[3]),…, (P, p[i], p[i+1]),… (P, p[N], p[1]) . Where the stencil is non-zero is “inside” (according to the odd-even fill rule) and where it is 0 it is outside. For simple polygons, odd-even fill rule is equivalent to non-zero fill rule. Going further, one can use increment and decrement with wrapping to do a non-zero fill rule for general paths (subject to the complexity not exceeding 127).[/li][/ul]
That 2nd option has been in the OpenGL Red book for over a decade . You really need to start some reading, not doing so is going to leave you ignorant.
[ul]
[li]http://fly.cc.fer.hr/~unreal/theredbook/ (old online version of the Red book)[/li][li]http://www.opengl.org/registry/doc/glspec44.core.pdf The OpenGL specification, a must read.[/li][li]http://bps11.idav.ucdavis.edu/talks/04-realTimeRenderingArchitecture-BPS2011-houston.pdf excellent presentation explaining current desktop GPU architectures[/li][li]http://www.arcsynthesis.org/gltut/ (in Alfhonses signature, a tutorial to get started doing 3D graphics with OpenGL)[/li][/ul]
Thanks, but I don`t need your help, maybe you could help the guys designing the next hardware for OpenGL.
I red the OpenGL-Superbible 14 years ago and I know, what I´m talking about, when I make some suggestions.
You know ? - Suggestions!
My next suggestion: The whole Graphic-API of a operating system (Windows, Linux …) should base on a 3D-System like OpenGL or Direct 3D.
There should be no difference between 3D and 2D. What does it matter, if the z-coordinate is 0 at 2D
Therefore I also suggested that Fonds should be supported by a 3D-System therefore the fonds should be supported by the hardware.
Here you can see, what graphics-hardware is able to do.
Regarding all these abilities my suggestions easily should be possible.
You have to know, that I´m often 20years in the future.
“Eppur si muove!”
Have a nice day
[QUOTE=LuisAK;1254248]My next suggestion: The whole Graphic-API of a operating system (Windows, Linux …) should base on a 3D-System like OpenGL or Direct 3D.
There should be no difference between 3D and 2D. What does it matter, if the z-coordinate is 0 at 2D
You have to know, that I´m often 20years in the future. [/QUOTE]
…or 8 years in the past. This happened for every major OS a long time ago.
happened ? Maybe, there are a few aspects but not consequently!
- Why can the simple Graphic API render polygons and OpenGL can´t ?
API: Polygon function (wingdi.h) - Win32 apps | Microsoft Learn
C#: Graphics.FillPolygon Methode (System.Drawing) | Microsoft Learn - Why can´t OpenGL supply directly Fonts
:
:
[QUOTE=LuisAK;1254250]happened ? Maybe, there are a few aspects but not consequently!
- Why can the simple Graphic API render polygons and OpenGL can´t ?
API: http://msdn.microsoft.com/en-us/library/windows/desktop/dd162814(v=vs.85).aspx
C#: http://msdn.microsoft.com/de-de/library/vstudio/89sks199.aspx - Why can´t OpenGL supply directly Fonts
:
:[/QUOTE]
Because the “simple graphics API” is slow and implemented in software. OpenGL isn’t. As I said in my very first reply to this thread - OpenGL is not the tool for what you want to achieve here.
Also note that the “simple graphics API” is a high-level abstraction, OpenGL is a low-level abstraction. The “simple graphics API” doesn’t render things directly, what it does is decomposes things (in software) into lower-level primitives which are then rendered by a lower-level abstraction.
You don’t want OpenGL. You want a high-level API. OpenGL is not that API.
Let’s get this really straight. There will always be a need for a low-level abstraction. At the very least, one is needed to sit under the high-level abstraction you want (and that you seem to think OpenGL is - or should be). You’re looking for high-level functionality in a low-level API and you’re disappointed when you don’t find it. Guess what? You’re just looking in the wrong place. If you want to draw fonts, or concave polygons, or whatever, then just use a high-level abstraction and be done with it. OpenGL is not the solution you need for this.
[QUOTE=mhagain;1254212]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.
[/QUOTE]
it seems that your`e talking about a hardware from 1985
as you can see in the following pages, the actual “hardware” is a system of parallel processing systems:
Therefore the two suggestions I made (Direct Font support, and rendering of polygons like the simple Grapics API can do)
easily could be implemented in the “hardware” and OpenGL could support the interface,
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 ?
Your´e talking about the present, I´m talking about the future - what could be. (Suggestions for the next release)
[QUOTE=LuisAK;1254253]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 ?[/QUOTE]
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.
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?
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.
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:
[ul]
[li]Have a clear way to implement said functionality in a highly parallel fashion[/li][li]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.[/li][li]Be aware of various constraints, i.e. the tradeoff between flexibility and speed; generally speaking more flexible implies slower.[/li][/ul]
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:
[ul]
[li]Define data store (be it buffer objects or textures)[/li][li]Set values of data store directly (i.e. glTexSubImage2D for example)[/li][li]Set GL state to determine from what data stores to fetch data (binding textures and buffer objects for example)[/li][li]Set GL state to what data stores to write (framebuffer objects and transform feedback for example)[/li][li]Set GL state for parameters of fixed functionality (depth test, stencil test, color, depth, stencil masking and blending for example)[/li][li]Specify how to process input vertex stream into values for the data store rights, i.e. define GLSL programs[/li][li]Limited query (samples passed, syncs)[/li][li]memory barriers (for random read/writes introduced in GL4 hardware).[/li][li]Execute draw commands[/li][/ul]
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.
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
To render concave polygons directly is very easy.
Here an example:
[ATTACH=CONFIG]496[/ATTACH]
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.
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.
[QUOTE=Alfonse Reinheart;1254301]Because I enjoy feeding idiocy on this forum:
[/QUOTE]
Ok, when arguments go, you continue with insults.
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).
It could be done efficiently:
[ATTACH=CONFIG]497[/ATTACH]
Also in the “Hardware” because there is only a very little trick.
[QUOTE=LuisAK;1254305]It could be done efficiently:
[ATTACH=CONFIG]1120[/ATTACH]
Also in the “Hardware” because there is only a very little trick.[/QUOTE]
Drawing flat-shaded polygons that are fully on-screen is nice. You’re still completely failing to answer these questions:
[ul]
[li]How do you interpolate texcoords, colours and other vertex attribs across a concave polygon?[/li][li]How do you split a concave polygon that’s partially clipped?[/li][li]How do you deal with cases where vertices of the polygon are not all on the same plane?[/li][/ul]
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?
[QUOTE=mhagain;1254306]
[li]How do you interpolate texcoords, colours and other vertex attribs across a concave polygon?
[/li][/QUOTE]
You can interpolate them by the surounding rectangle
[QUOTE=mhagain;1254306]
[li]How do you split a concave polygon that’s partially clipped?
[/li][/QUOTE]
Therefore the stencil-buffer is existing
[QUOTE=mhagain;1254306]
[li]How do you deal with cases where vertices of the polygon are not all on the same plane?
[/li][/QUOTE]
When they are projected to the screen they are all flat, but normaly they are on a plane.
[QUOTE=mhagain;1254306]
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?[/QUOTE]
Whats that ?
[ATTACH=CONFIG]498[/ATTACH]