# Thread: Open GL should support konkave polygons directly

1. Originally Posted by mhagain
• Filling a triangle can be as simple as starting at one edge and drawing a line until you meet another edge.
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.

2. Originally Posted by GClements
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:
1. Draw a rectangle around the concave polygon.
2. Draw the polygonlines.
3. Scan the rectangle fom xmin to xmax and in this loop from ymin to ymax
4. If you pass the first line you get inside the polygon, at the next line you get outside an so on ..
5. Inside, you set the pixels, and so the concave polygon will be drawn.

3. To render a concav Polygon is so simple:
1. Draw a rectangle around the concave polygon.
2. Draw the polygonlines.
3. Scan the rectangle fom xmin to xmax and in this loop from ymin to ymax
4. If you pass the first line you get inside the polygon, at the next line you get outside an so on ..
5. Inside, you set the pixels, and so the concave polygon will be drawn.
• 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.
• 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.

Now if you really, really want to draw any polygon in GL now you can one of the two:
• Triangulate it and then feed those triangles to GL

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

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.

4. 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.
http://de.wikipedia.org/wiki/Grafikprozessor
http://de.wikipedia.org/wiki/OpenCL
http://de.wikipedia.org/wiki/PhysX
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
;-)

5. Originally Posted by LuisAK
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.
...or 8 years in the past. This happened for every major OS a long time ago.

6. Originally Posted by mhagain
...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!

1. Why can the simple Graphic API render polygons and OpenGL canīt ?
API: http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx
C#: http://msdn.microsoft.com/de-de/libr.../89sks199.aspx
2. Why canīt OpenGL supply directly Fonts
:
:

7. Originally Posted by LuisAK
happened ? Maybe, there are a few aspects but not consequently!

1. Why can the simple Graphic API render polygons and OpenGL canīt ?
API: http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx
C#: http://msdn.microsoft.com/de-de/libr.../89sks199.aspx
2. Why canīt OpenGL supply directly Fonts
:
:
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.

8. Originally Posted by mhagain
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.
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:
http://de.wikipedia.org/wiki/Grafikprozessor
http://de.wikipedia.org/wiki/OpenCL
http://de.wikipedia.org/wiki/PhysX

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,

9. 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 ?

10. Originally Posted by mhagain
You don't want OpenGL. You want a high-level API. OpenGL is not that API.
Yourīe talking about the present, Iīm talking about the future - what could be. (Suggestions for the next release)

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•