Hi Robert, Jason,
I am lazy guy, and I agree with both of you, its only neccessary to make it
backward compatibile ;-)
However, for purely academic reasons I will respond to Jason. But don't
treat my post as call for revolution. Its just my opinion how PER_VERTEX,
PER_PRIMITIVE, PER_PRIMITIVE_SET should be resolved for Triangle strips.
But, I will state it again, if it was differently done before, then lets
keep it as it used to be.
Now lets get to our academic discussion:
In Jason's post BIND_PER_PRIMITIVE does the same as BIND_PER_PRIMITIVE_SET
for Triangle strips. Note that if this was correct behaviour then
TriangleStrips with BIND_PER_PRIMITIVE binding could use fast paths.
Instead, IMHO thats how these bindings should be translated to glBegin/glEnd
OpenGL code:
// Color BIND_PER_VERTEX : N vertices, N colors
glBegin(GL_TRIANGLE_STRIP);
glColor4f( ... ); // set color for each vertex
glVertex3f( ... );
glColor4f( ... );
glVertex3f( ... );
...
glColor4f( ... );
glVertex3f( ... );
glEnd();
// Color BIND_PER_PRIMITIVE : N vertices, N-2 colors
glBegin(GL_TRIANGLE_STRIP);
glVertex3f( ... ); // two verts without colors
glVertex3f( ... );
glColor4f( ... ); // starting from third vertex, we pass color for each
provoking vertex of triangle
glVertex3f( ... );
glColor4f( ... );
glVertex3f( ... );
...
glColor4f( ... );
glVertex3f( ... );
glEnd();
// Color BIND_PER_PRIMITIVE_SET : N vertices, 1 color
glColor4f( ... ); // set color once
glBegin(GL_TRIANGLE_STRIP);
glVertex3f( ... ); // no need for colors
glVertex3f( ... );
...
glVertex3f( ... );
glEnd();
With above interpretation, only PER_PRIMITIVE binding cannot be done with
fast paths DrawArrays. So general recommendation to avoid
BIND_PER_PRIMITIVE as slow path trigger, still makes sense.
Second: I would not treat Performer as ultimate reference for resolving all
doubts. Performer did not offer PER_PRIMITIVE_SET binding and also had
additional PFGS_FLAT_LINESTRIPS, PFGS_FLAT_TRISTRIPS in addition to classic
PFGS_LINESTRIPS, PFGS_TRISTRIPS we have in OSG.
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.
I ran it and yes you can. I guess, thats what PFGS_FLAT_TRISTRIPS was doing
in Performer. With flat shading (activated in example), one triangle is red
and second is green. With smooth shading second triangle is colored wtih
red -> green gradient.
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.
Well... what you write sounds like you don't agree with me, because I
postulate that that BIND_PER_PRIMITIVE should differ from
BIND_PER_PRIMITIVE_SET and BIND_PER_VERTEX. And yes I will say that again,
its possible to make faceted apperance with triangle strips in OpenGL. Thats
was my point in my first post and thats what this short example I posted was
doing. Btw good point about GL_TRIANGLES instead of GL_TRIANGLE ;-)
Highest Regards ;-)
Wojtek
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org