Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 3 of 6 FirstFirst 12345 ... LastLast
Results 21 to 30 of 53

Thread: Open GL should support konkave polygons directly

  1. #21
    Member Regular Contributor
    Join Date
    Jun 2013
    Posts
    474
    Quote Originally Posted by mhagain View Post
    • 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. #22
    Intern Newbie
    Join Date
    Dec 2012
    Posts
    42
    Quote Originally Posted by GClements View Post
    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. #23
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    578
    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.
    I am going to try (again) to help you LuisAK.
    • 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.
    Last edited by kRogue; 08-23-2013 at 08:50 AM.

  4. #24
    Intern Newbie
    Join Date
    Dec 2012
    Posts
    42
    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. #25
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,136
    Quote Originally Posted by LuisAK View Post
    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. #26
    Intern Newbie
    Join Date
    Dec 2012
    Posts
    42
    Quote Originally Posted by mhagain View Post
    ...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. #27
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,136
    Quote Originally Posted by LuisAK View Post
    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. #28
    Intern Newbie
    Join Date
    Dec 2012
    Posts
    42
    Quote Originally Posted by mhagain View Post
    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. #29
    Intern Newbie
    Join Date
    Dec 2012
    Posts
    42
    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. #30
    Intern Newbie
    Join Date
    Dec 2012
    Posts
    42
    Quote Originally Posted by mhagain View Post
    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
  •