Hi Sukender,

What for ? If we agreed on Primitive meaning a single Triangle from TriangleStrip then we don't need to change the enums. Current binding smenatics are valid:

PER_PRIMIITIVE means per triangle
PER_PRIMITIVE_SET means per triangle strip

and of course

PER_VERTEX means per vertex
OVERALL means the same attrib (normal/color) for all primitive sets in geometry.

Why change that ?

Wojtek


-----Original Message----- From: Sukender
Sent: Monday, January 10, 2011 9:59 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] BIND_PER_PRIMITIVE broken?

Hi Wojtek,

Allright. So what about changing the terms we use? Say BIND_PER_SHAPE / BIND_PER_PRIMITIVE, or BIND_PER_ELEMENT / BIND_PER_PRIMITIVE?

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/

----- "Wojciech Lewandowski" <lewandow...@ai.com.pl> a écrit :

Hi, Sukender,

I think we fully agree both on whats a 'Primitive' and binding
interpretations. I actually like your interpretation of primitive
term.
Primitive is always a Triangle and Triangles, TriangleFans and
TriangleStrips are just a methods of passing vertices. But I avoided
using
word Primitive because I had the feeling that it can have slightly
different
semantics in OpenGL docs and different in Performer docs and different
in
OSG.

Wojtek

-----Original Message-----
From: Sukender
Sent: Monday, January 10, 2011 9:22 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] BIND_PER_PRIMITIVE broken?

Hi all,

Interesting discusssion. I didn't guess that it wouyld bring so much
comments!

Well this cannot be a regression as I'm implementing it! I just need
to make
it work "the old style" way.
However, I would expect that a primitive is one of {point, line,
triangle,
quad}, even id OpenGL says a strip is also a primitive (is there a
naming
issue there? Should we have something like "elements", "primitive" and
"primitive set"???). So, for me, PER_PRIMITIVE is a binding for them,
and
PER_PRIMITIVE_SET is a binding for a "bunch" of them :
TRIANGLES, TRIANGLE_STRIP, TRIANGLE_FAN : primitive = one triangle /
primitive set = all triangles
QUADS, QUAD_STRIP : primitive = one quad / primitive set = all quads
Once again, that's only my point of view.

Actually, OpenGL can do this binding (even if it's slow), so why not
supporting it if it's not that difficult? Should we name it
differently?

Thank you all for your comments and ideas.
Cheers,

Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/

----- "Jason Daly" <jd...@ist.ucf.edu> a écrit :

> On 1/8/2011 6:19 AM, Robert Osfield wrote:
> > Hi All,
> >
> > Perhaps we should be asking the question what was the behavior
> prior
> > to the refactor to I did for GL3/OpenGLES support.   Sukender did
> your
> > Geometry work previously?  Is this a regression or just a
behaviour
> > that you weren't expecting?
>
> Good question!
>
> ---------------
>
> Somehow I missed Wojtek's post, so I'll reply to that here:
>
> >> glBegin(GL_TRIANGLE)/glEnd() code with 2 triangles and one
normal.
> It will
> >> be correct OpenGL code. Would you say that two triangles
correspond
> to one
> >> OSG primitive or two OSG primitves in this case ? And if you do
not
> pass
> >> normal before second triangle, OpenGL will use last normal passed
> (ie the
> >> one from first triangle):
> >>
> >> glBegin(GL_TRIANGLE);
> >>   glNormal3f(...);
> >>   glVertex3f(...); //1
> >>   glVertex3f(...); //2
> >>   glVertex3f(...); //3
> >>   // no normal and its no error !
> >>   glVertex3f(...); //4
> >>   glVertex3f(...); //5
> >>   glVertex3f(...); //6
> >> glEnd();
>
> It's two primitives.  Yes, you can use the same normal for two
> separate
> triangles, but that doesn't mean it's not two primitives.  Actually
> your
> code is slightly incorrect, the glBegin() line should read:
>
> glBegin(GL_TRIANGLES);
>
> I'm not pointing this out just to be pedantic.  It's evidence to
> support
> my position that it's actually two primitives (i.e.:  two triangles)
> in
> that case  :-)
>
>
> >> In the same way OpenGL assumes that last passed normal is used
for
> the
> >> triangle in triangle strip. Triangle Srip is just another method
of
> passing
> >> vertices to OpenGL and each triangle may have its own unique
> normals/colors.
> >> If you don't agree, just do a reverse test: see if below would
> render both
> >> triangles with the same color or different colors. They will
> differ, and
> >> this is also correct OpenGL code:
> >>
> >> glShadeModel( GL_FLAT );
> >> glBegin(GL_TRIANGLE_STRIP);
> >>   glColor4f( 1, 0, 0, 1 ); // RED
> >>   glVertex3f(0, 0, 0);
> >>   glVertex3f(0, 1, 0);
> >>   glVertex3f(1, 0, 0);
> >>   glColor4f( 0, 1, 0, 1 ); // GREEN
> >>   glVertex3f(1, 1, 0);
> >> glEnd();
>
> Yes, I mentioned that in my previous post.  It doesn't take away
from
>
> the fact that the triangle strip is considered a single primitive.
>
> I actually wonder what the colors would look like here.  Did you
> actually run this code?  My guess would be that the final vertex is
> green, but the final triangle would blend from red to green across
its
>
> surface, because its two other vertices were red (as specified in
the
>
> code).   I could be wrong (I haven't run the code myself), but
that's
>
> what I would expect.  Even if you consider each triangle in the
strip
> a
> different "primitive", you still couldn't get a set of completely
red
>
> triangles, followed by a completely green triangle, which is what
the
> OP
> is looking for.
>
> >> Last argument is actually a postulate for OSG clarity. We have
> >> BIND_PER_PRIMITIVE_SET flag. Shouldn't this flag be rather used
for
>  the
> >> situation where we want to one normal / one color etc for all
> triangles in
> >> tristrip ?
>
> If I understand you correctly, then yes.  BIND_PER_PRIMITIVE in the
> case
> of triangle strips should mean the same normal/color for each entire
> triangle strip (that's how Performer used to treat it as well).  If
I
>
> remember correctly, the OP was looking to get different normals for
> each
> triangle in the strip (to produce a faceted appearance, I think).  I
> don't believe this is possible even in pure OpenGL.  The only way to
> do
> it is to use distinct triangles for primitives.
>
> --"J"
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to