Hi Sukender,
> 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?
it is my understanding that OpenGL can only do BIND_PER_VERTEX natively.
There is no such thing as a face normal or color. There is only linear
interpolation between values at vertices. So when you share vertex data
in a primitive, you can only share also normal, color and other attributes.
So emulating hypothetical BIND_PER_FACE requires a change in primitive
type for STRIP and FAN
Regards,
-Fred
----- "Sukender" a écrit :
> 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
