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
