Anyone know how to draw a polygon in opengl ?

The following code should display a flat T shape, but openGL decides to
ignore the second vertex and renders a diagonal line from point one to point
three. Change the mode to line and it all works OK.

    glPolygonMode(GL_FRONT_AND_BACK,GL_FILL);
    glBegin(GL_POLYGON);
          glVertex3f(0,4,0);
          glVertex3f(4,4,0);   <------- This vertex ignored
          glVertex3f(4,2,0);
          glVertex3f(6,2,0);
          glVertex3f(6,4,0);
          glVertex3f(10,4,0);
          glVertex3f(10,6,0);
          glVertex3f(0,6,0);
          glVertex3f(0,4,0);  <----- makes no difference closing the polygon
or not.
    glEnd();


Tried this on 2 machines with differing graphics cards, same result.

"Andy Kaye" <andyk@mil003.fsnet.co.uk> wrote in message 
news:dtl76r$j7m$1$8300dec7@news.demon.co.uk...
> Anyone know how to draw a polygon in opengl ?
>
> The following code should display a flat T shape, but openGL decides to
> ignore the second vertex and renders a diagonal line from point one to 
> point
> three. Change the mode to line and it all works OK.
>
>    glPolygonMode(GL_FRONT_AND_BACK,GL_FILL);
>    glBegin(GL_POLYGON);

GL_POLYGON refers to a "convex polygon", an unfortunate
misnomer for the enum.  Your polygon is not convex.  You
need to decompose it into convex polygons.  The simplest
way to do this generally is to triangulate it.  Convex
decomposition into a minimum number of convex polygons
is tractable, but the algorithms are quite complex.

--
Dave Eberly
http://www.geometrictools.com

You may also try GLU tessellator. It can convert a concave polygon to
the convex polygon and tessellate self-intersecting polygon too.
==song==

Thanks for the info,

Pretty Naff though, thought drawing polygons would be a pretty basic
operation, if it can't even do that- doesn't bode well for more complex
operations.

Does Direct3D do it any better ?

Andy

"Dave Eberly" <dNOSPAMeberly@usemydomain.com> wrote in message
news:C1qLf.2890$5M6.2378@newsread2.news.atl.earthlink.net...
>
> "Andy Kaye" <andyk@mil003.fsnet.co.uk> wrote in message
> news:dtl76r$j7m$1$8300dec7@news.demon.co.uk...
> > Anyone know how to draw a polygon in opengl ?
> >
> > The following code should display a flat T shape, but openGL decides to
> > ignore the second vertex and renders a diagonal line from point one to
> > point
> > three. Change the mode to line and it all works OK.
> >
> >    glPolygonMode(GL_FRONT_AND_BACK,GL_FILL);
> >    glBegin(GL_POLYGON);
>
> GL_POLYGON refers to a "convex polygon", an unfortunate
> misnomer for the enum.  Your polygon is not convex.  You
> need to decompose it into convex polygons.  The simplest
> way to do this generally is to triangulate it.  Convex
> decomposition into a minimum number of convex polygons
> is tractable, but the algorithms are quite complex.
>
> --
> Dave Eberly
> http://www.geometrictools.com
>
>

Andy Kaye wrote:
> Anyone know how to draw a polygon in opengl ?
> 

Me!

> The following code should display a flat T shape, but openGL decides to
> ignore the second vertex and renders a diagonal line from point one to point
> three. Change the mode to line and it all works OK.
> 
>     glPolygonMode(GL_FRONT_AND_BACK,GL_FILL);
>     glBegin(GL_POLYGON);
>           glVertex3f(0,4,0);
>           glVertex3f(4,4,0);   <------- This vertex ignored
>           glVertex3f(4,2,0);
>           glVertex3f(6,2,0);
>           glVertex3f(6,4,0);
>           glVertex3f(10,4,0);
>           glVertex3f(10,6,0);
>           glVertex3f(0,6,0);
>           glVertex3f(0,4,0);  <----- makes no difference closing the polygon
> or not.
>     glEnd();
> 
> 
> Tried this on 2 machines with differing graphics cards, same result.
> 

OpenGL can't draw concave polygons.


-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

> Pretty Naff though, thought drawing polygons would be a pretty basic
> operation, if it can't even do that- doesn't bode well for more complex
> operations.
>
> Does Direct3D do it any better ?

No, you'll have exactly the same problem.  Splitting it into
tris is by far your best bet.

- SamB

"Andy Kaye" <andyk@mil003.fsnet.co.uk> wrote in message 
news:dtle13$bq7$1$8302bc10@news.demon.co.uk...
> Thanks for the info,
>
> Pretty Naff though, thought drawing polygons would be a pretty basic
> operation, if it can't even do that- doesn't bode well for more complex
> operations.
>
> Does Direct3D do it any better ?

No.  Any graphics system has the same problem.  Rasterization
of polygons is easy to do when the polygons are convex.  When
the polygons are not convex, your only recourse is to split them
into convex ones.

When you say it "doesn't bode well for more complex operations",
I think that is a somewhat negative stance to take.  A lot of
art content is generated by artists, the result being triangle
meshes.  You can feed these directly to the graphics API by
specifying an array of vertices (position, color, texture coordinates,
etc.) and an array of indices into the vertex array, each triple of
indices representing a triangle.

In your case, the "art content" consists of nonconvex polygons.
Triangulate them and feed them to the graphics API.  Done.
I believe you will find that most people agree the problem with
nonconvex polygons is considered a problem with the "art pipeline"
and not the "graphics pipeline".

At any rate, you should be able to find freely downloadable
source code to triangulate polygons.  A Google search should
do the trick.

--
Dave Eberly
http://www.geometrictools.com

Does that means it is impossible to generate a generic routine to draw
filled non-intersecting polygons. ?

Windows seems to do a good job on 2D polygons!

If the tessellation routines are to be used why does the api not do it
automatically when required?

Andy

"Dave Eberly" <dNOSPAMeberly@usemydomain.com> wrote in message
news:9jrLf.2919$5M6.2599@newsread2.news.atl.earthlink.net...
> "Andy Kaye" <andyk@mil003.fsnet.co.uk> wrote in message
> news:dtle13$bq7$1$8302bc10@news.demon.co.uk...
> > Thanks for the info,
> >
> > Pretty Naff though, thought drawing polygons would be a pretty basic
> > operation, if it can't even do that- doesn't bode well for more complex
> > operations.
> >
> > Does Direct3D do it any better ?
>
> No.  Any graphics system has the same problem.  Rasterization
> of polygons is easy to do when the polygons are convex.  When
> the polygons are not convex, your only recourse is to split them
> into convex ones.
>
> When you say it "doesn't bode well for more complex operations",
> I think that is a somewhat negative stance to take.  A lot of
> art content is generated by artists, the result being triangle
> meshes.  You can feed these directly to the graphics API by
> specifying an array of vertices (position, color, texture coordinates,
> etc.) and an array of indices into the vertex array, each triple of
> indices representing a triangle.
>
> In your case, the "art content" consists of nonconvex polygons.
> Triangulate them and feed them to the graphics API.  Done.
> I believe you will find that most people agree the problem with
> nonconvex polygons is considered a problem with the "art pipeline"
> and not the "graphics pipeline".
>
> At any rate, you should be able to find freely downloadable
> source code to triangulate polygons.  A Google search should
> do the trick.
>
> --
> Dave Eberly
> http://www.geometrictools.com
>
>

Andy Kaye wrote:
> Does that means it is impossible to generate a generic routine to draw
> filled non-intersecting polygons. ?
>
> Windows seems to do a good job on 2D polygons!
>
> If the tessellation routines are to be used why does the api not do it
> automatically when required?
>
> Andy
>

Because it is slower, and doesn't normally occur in hardware.  Since
most 3D accelerators will only directly rasterise convex polygons,
having the API demand that all possible polygons render well would mean
that it would run in software, and very slowly.  It shouldn't really be
that much work to use GLU to tesselate the polygons, if speed isn't a
big concern.  If speed is a big concern, then preprocess everything so
that it doesn't need to be tesselated at run time.

"Andy Kaye" <andyk@mil003.fsnet.co.uk> wrote in message 
news:dtlh97$ado$1$830fa79d@news.demon.co.uk...
> Does that means it is impossible to generate a generic routine to draw
> filled non-intersecting polygons. ?
>
> Windows seems to do a good job on 2D polygons!
>
> If the tessellation routines are to be used why does the api not do it
> automatically when required?

The graphics API does not know if the polygon you give it is
convex or nonconvex.  Or simple.  Or non-self-intersecting.
Determining this information is an expensive proposition, and
you certainly do not want the API to spend time *each drawing
pass* figuring this information out.  OpenGL and Direct3D are
there to help you with hardware-accelerated drawing.  If
Windows GDI suffices for you, what then is your interest in
OpenGL?

Regarding your first question.  Pseudocode:

    create nonconvex polygons;
    triangulate nonconvex polygons to vertex and index arrays;
    while (not tired of drawing triangles)
    {
        draw triangles;
    }

It would be a waste of cycles having instead

    create nonconvex polygons;
    while (not tired of drawing triangles)
    {
        triangulate nonconvex polygons to vertex and index arrays;
        draw triangles;
    }

If it is the case that you allow users to draw the polygons, as
soon as they "commit" to their changes, at that time you can
retriangulate.  But the idle loop is still the same--do not spend
cycles triangulating and only draw.

--
Dave Eberly
http://www.geometrictools.com

Andy Kaye wrote:
> Anyone know how to draw a polygon in opengl ?
> 
> The following code should display a flat T shape, but openGL decides to
> ignore the second vertex and renders a diagonal line from point one to point
> three. Change the mode to line and it all works OK.
> 
>     glPolygonMode(GL_FRONT_AND_BACK,GL_FILL);
>     glBegin(GL_POLYGON);
>           glVertex3f(0,4,0);
>           glVertex3f(4,4,0);   <------- This vertex ignored
>           glVertex3f(4,2,0);
>           glVertex3f(6,2,0);
>           glVertex3f(6,4,0);
>           glVertex3f(10,4,0);
>           glVertex3f(10,6,0);
>           glVertex3f(0,6,0);
>           glVertex3f(0,4,0);  <----- makes no difference closing the polygon
> or not.
>     glEnd();
> 
> 
> Tried this on 2 machines with differing graphics cards, same result.
> 
> 

It is look like everything is said. But just a hint: When you make OGL 
draw a Polygon, it handles it, like it is a Triangle-Fan. That's why you 
(at least sometimes) cannot draw convex Polygons.

If you want to draw a "T" with just one GL_POLYGON you perhaps could try 
to split the above line of T into to edges, and start with the middle 
vertex. Like:

*--*--*
|     |
*-* *-*
   | |
   | |
   *-*

In your case it would be:

      glBegin(GL_POLYGON);
	   glVertex3f(5,6,0);
            glVertex3f(0,6,0);
            glVertex3f(0,4,0);
            glVertex3f(4,4,0);
            glVertex3f(4,2,0);
            glVertex3f(6,2,0);
            glVertex3f(6,4,0);
            glVertex3f(10,4,0);
            glVertex3f(10,6,0);
      glEnd();

When using this with Filled Mode it makes no difference if you use 
GL_POLYGON or GL_TRIANGLE_FAN. Try it and you will see.
Just Remember OGL has to handle everything as Triangles (more or less, 
its at least something good to imagine), even if you wont see first.

(An arrow for this case is another classic example)
So as fungus said, OGL can't handle non-convex polygons, but sometimes 
you can get it handle this right. (In your case with one more Vertex)

"Andy Kaye" <andyk@mil003.fsnet.co.uk> wrote:
>
> If the tessellation routines are to be used why does the api not do it
> automatically when required?
> 

If it had to check every polygon it would be
slower.

There's no point in penalizing all the people
who don't draw 'T's.


-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

Well I've RTFM and created the tessalation routines based on the examples
and they do work, so I now have a generic routine which I can feed my shapes
to and they appear OK.

So thanks for the comments that put me in the right direction.

I'm still a little annoyed however that I has to do it. I must be the
millionth programmer thats had to do it so I  can't understand why the
higher level API doesn't do it automatically.

I understand the low level routines provide fast access for games and the
like, so by all means provide the low level access but a higher level
generic routine should be available. I'm really not interested in the
underlying triangulation methods any more than the methods windows uses to
render its 2D polygons, I just want it to draw a polygon.

Andy


"Dave Eberly" <dNOSPAMeberly@usemydomain.com> wrote in message
news:xctLf.2981$5M6.1652@newsread2.news.atl.earthlink.net...
> "Andy Kaye" <andyk@mil003.fsnet.co.uk> wrote in message
> news:dtlh97$ado$1$830fa79d@news.demon.co.uk...
> > Does that means it is impossible to generate a generic routine to draw
> > filled non-intersecting polygons. ?
> >
> > Windows seems to do a good job on 2D polygons!
> >
> > If the tessellation routines are to be used why does the api not do it
> > automatically when required?
>
> The graphics API does not know if the polygon you give it is
> convex or nonconvex.  Or simple.  Or non-self-intersecting.
> Determining this information is an expensive proposition, and
> you certainly do not want the API to spend time *each drawing
> pass* figuring this information out.  OpenGL and Direct3D are
> there to help you with hardware-accelerated drawing.  If
> Windows GDI suffices for you, what then is your interest in
> OpenGL?
>
> Regarding your first question.  Pseudocode:
>
>     create nonconvex polygons;
>     triangulate nonconvex polygons to vertex and index arrays;
>     while (not tired of drawing triangles)
>     {
>         draw triangles;
>     }
>
> It would be a waste of cycles having instead
>
>     create nonconvex polygons;
>     while (not tired of drawing triangles)
>     {
>         triangulate nonconvex polygons to vertex and index arrays;
>         draw triangles;
>     }
>
> If it is the case that you allow users to draw the polygons, as
> soon as they "commit" to their changes, at that time you can
> retriangulate.  But the idle loop is still the same--do not spend
> cycles triangulating and only draw.
>
> --
> Dave Eberly
> http://www.geometrictools.com
>
>

Glad to hear you resolving the problem.

Tessellation is kind of pre-processing before rendering. Once a polygon
has been tessellated, you just use the tessellated polygon for
rendering and do not need do it again every frame.

By allowing only valid convex polygons for rendering, the rendering
pipeline still remains as simple as possible. For same reason, we
destroy all the previous rendered data and redraw whole things again on
new canvas even if nothing changed. It is somewhat not logical, but it
is the current design of rendering pipeline. Who know, one day, we will
have more complicate API which handle everything for us.

Andy Kaye wrote:
> I'm still a little annoyed however that I has to do it. I must be the
> millionth programmer thats had to do it so I  can't understand why the
> higher level API doesn't do it automatically.

It does. The GLU tesselator is the higher-level API that you're looking for.
AFAIK, there is no equivalent in Direct X.

Note that there is no trivial way to define the interior of an arbitrary
(e.g. self-intersecting) contour, so the problem is necessarily complicated
in the general case.

However, I don't think anyone else has mentioned that you can also use the
stencil buffer to handle winding numbers, by rendering in two passes. This
is easier than tesselating.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html

Andy Kaye wrote:

> I'm still a little annoyed however that I has to do it. I must
> be the millionth programmer thats had to do it so I  can't
> understand why the higher level API doesn't do it
> automatically. 

And that's the reason, why GLU has tesselation routines doing
this job for you. Like Dave wrote, decompositing a polygon into
triangles can be a quite difficult/complex job.

Just google "tesselation winding intersection".

OTOH all 3D modelling programs I know about create either
triangles or quads. Tesselation of parametric patches usually
goes over two variables (oftenly called U and V), which directly
decompsit into quads, which can be easyly split into two
triangles.

Wolfgang Draxinger
--