Hi Frederic,
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.
Interpolation is done when you have GL_SMOOTH shade model. If shade model is
GL_FLAT you can have per face binding. See OpenGL help on glShadeModel
function.
Wojtek
----- "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
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
