Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi all, As said in my post (a few minutes ago), it sounds like we do not all agree on what is a primitive! OpenGL says a primitive can be a strip/fan ( http://www.opengl.org/wiki/Primitives ). However, I agree it sounds very strange to have same behaviour for BIND_PER_PRIMITIVE and BIND_PER_PRIMITIVE_SET. Should we introduce BIND_PER_ELEMENT or such? Should we rename the BIND_PER_PRIMITIVE and BIND_PER_PRIMITIVE_SET? Thoughts? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Wojciech Lewandowski lewandow...@ai.com.pl a écrit : 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
Re: [osg-users] BIND_PER_PRIMITIVE broken?
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
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
Re: [osg-users] BIND_PER_PRIMITIVE broken?
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
Re: [osg-users] BIND_PER_PRIMITIVE broken?
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
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Wojtek,
Well, just to avoid confusion with the term used for OpenGL primitives :)
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Wojciech Lewandowski lewandow...@ai.com.pl a écrit :
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
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Wojtek and Frederic,
Indeed, it seems OpenGL natively reads per vertex normals, by checking the
current normal value (given with glNormal()). And when looking at
glShadeModel(), it says which vertex normal is used when doing GL_FLAT
lighting (roughly: the last vertex of the triangle/quad/polygon).
Conclusion (IMHO): BIND_PER_PRIMITIVE should do it per triangle/quad/polygon :)
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Wojciech Lewandowski lewandow...@ai.com.pl a écrit :
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
Re: [osg-users] BIND_PER_PRIMITIVE broken?
On 01/09/2011 05:37 AM, Wojciech Lewandowski wrote: 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 ;-) Ah, I wasn't considering the case of flat shading. I suppose that would make all the difference :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
On 01/10/2011 03:46 AM, Wojciech Lewandowski wrote: Hi, Sukender, I think we fully agree both on whats a 'Primitive' and binding interpretations. I don't think we agree at all... man glBegin NAME glBegin, glEnd - delimit the vertices of a primitive or a group of like primitives C SPECIFICATION void glBegin( GLenum mode ) PARAMETERS mode Specifies the primitive or primitives that will be created from vertices presented between glBegin and the subsequent glEnd. Ten symbolic constants are accepted:GL_POINTS, GL_LINES, GL_LINE_STRIP, GL_LINE_LOOP, GL_TRIANGLES, GL_TRIANGLE_STRIP, GL_TRIANGLE_FAN, GL_QUADS, GL_QUAD_STRIP, and GL_POLYGON. glDrawArrays also refers to the mode parameter as specifying what kind of primitives to render. From what I've read (I just went and did a cursory check), the OpenGL spec agrees with what the man pages. I really don't think we should be redefining what a primitive is, we should stick with OpenGL's terms. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Yes, Jason. This is why I proposed to have a BIND_PER_ELEMENT, which would do per triangle/quad (since OpenGL says a strip is a primitive). Thoughts? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Jason Daly jd...@ist.ucf.edu a écrit : On 01/10/2011 03:46 AM, Wojciech Lewandowski wrote: Hi, Sukender, I think we fully agree both on whats a 'Primitive' and binding interpretations. I don't think we agree at all... man glBegin NAME glBegin, glEnd - delimit the vertices of a primitive or a group of like primitives C SPECIFICATION void glBegin( GLenum mode ) PARAMETERS mode Specifies the primitive or primitives that will be created from vertices presented between glBegin and the subsequent glEnd. Ten symbolic constants are accepted:GL_POINTS, GL_LINES, GL_LINE_STRIP, GL_LINE_LOOP, GL_TRIANGLES, GL_TRIANGLE_STRIP, GL_TRIANGLE_FAN, GL_QUADS, GL_QUAD_STRIP, and GL_POLYGON. glDrawArrays also refers to the mode parameter as specifying what kind of primitives to render. From what I've read (I just went and did a cursory check), the OpenGL spec agrees with what the man pages. I really don't think we should be redefining what a primitive is, we should stick with OpenGL's terms. --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
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Guys, For reference on this discussion, non of BIND_PER_PRIMITIVE or the proposed BIND_PER_ELEMENT are supported by modern OpenGL/OpenGL ES, the old BIND_PER_PRIMITIVE is very much deprecated and only kept around for backwards compatibility. Given even BIND_PER_PRIMTIIVE is deprecated there is absolutely no way I'm about to merge another enum and implementation that is not supported by OpenGL and forces the OSG to use slow paths and will forever have been screaming on the list DO NOT USE THIS FEATURE as your performance will be crap Perhaps I should just remove BIND_PER_PRIMITIVE and vertex indices and provide automatic conversion for all crappy osg::Geometry? This is certainly something I'm planning to do for OSG-3.2 as the current situation is if a feature is there it will be used and abused. For OSG-3.0 the only change we should make for the BIND_PER_PRIMITIVE implementation is to make sure it's consistent with 2.8.x as it's sole purpose is for backwards compatibility to allows users to easily migrate to 3.x. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Sorry, I'm skipping around a lot. Not sure why I'm not getting a single thread here... On 01/10/2011 05:52 AM, Wojciech Lewandowski wrote: 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 Aside from the disagreement in terms with the OpenGL spec, another reason this interpretation doesn't work is in the case of DrawArrayLengths primitive sets, where you can have multiple strips in the same primitive set. In that case at least, you'd need to have PER_PRIMITIVE mean per triangle strip, and PER_PRIMITIVE_SET mean all triangle strips in the primitive set. If you really want a per-face binding in these cases, you'd have to create a new binding type. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Jason Sukender, Hmm... Maybe we could make this even more absurd ;-) Lets consider this: if you propose to use OpenGL Primitive interpretation then N GL_TRIANGLES or N GL_QUADS in one PrimitveSet should be also rather interpreted as one Primitive. Am I right ? Shouldn't we get rid of osg::PrimitiveSet name and replace it with osg::Primitive class then ? (I am not serious ;-) I actually like current OSG primitive semantics and OSG bindings more than GL primitive semantics. But thats just my taste, discussion on what Primitive should be seems rather unproductive to me, and I avoided using this word before. Besides, I am not native speaker so I would rather shut my mouth and don't talk more about this Silent Cheers, Wojtek Lewandowski -Original Message- From: Sukender Sent: Monday, January 10, 2011 5:06 PM To: OpenSceneGraph Users Subject: Re: [osg-users] BIND_PER_PRIMITIVE broken? Yes, Jason. This is why I proposed to have a BIND_PER_ELEMENT, which would do per triangle/quad (since OpenGL says a strip is a primitive). Thoughts? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Jason Daly jd...@ist.ucf.edu a écrit : On 01/10/2011 03:46 AM, Wojciech Lewandowski wrote: Hi, Sukender, I think we fully agree both on whats a 'Primitive' and binding interpretations. I don't think we agree at all... man glBegin NAME glBegin, glEnd - delimit the vertices of a primitive or a group of like primitives C SPECIFICATION void glBegin( GLenum mode ) PARAMETERS mode Specifies the primitive or primitives that will be created from vertices presented between glBegin and the subsequent glEnd. Ten symbolic constants are accepted:GL_POINTS, GL_LINES, GL_LINE_STRIP, GL_LINE_LOOP, GL_TRIANGLES, GL_TRIANGLE_STRIP, GL_TRIANGLE_FAN, GL_QUADS, GL_QUAD_STRIP, and GL_POLYGON. glDrawArrays also refers to the mode parameter as specifying what kind of primitives to render. From what I've read (I just went and did a cursory check), the OpenGL spec agrees with what the man pages. I really don't think we should be redefining what a primitive is, we should stick with OpenGL's terms. --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
Re: [osg-users] BIND_PER_PRIMITIVE broken?
On 01/10/2011 11:26 AM, Robert Osfield wrote: Hi Guys, For reference on this discussion, non of BIND_PER_PRIMITIVE or the proposed BIND_PER_ELEMENT are supported by modern OpenGL/OpenGL ES, the old BIND_PER_PRIMITIVE is very much deprecated and only kept around for backwards compatibility. Given even BIND_PER_PRIMTIIVE is deprecated there is absolutely no way I'm about to merge another enum and implementation that is not supported by OpenGL and forces the OSG to use slow paths and will forever have been screaming on the list DO NOT USE THIS FEATURE as your performance will be crap Perhaps I should just remove BIND_PER_PRIMITIVE and vertex indices and provide automatic conversion for all crappy osg::Geometry? This is certainly something I'm planning to do for OSG-3.2 as the current situation is if a feature is there it will be used and abused. For OSG-3.0 the only change we should make for the BIND_PER_PRIMITIVE implementation is to make sure it's consistent with 2.8.x as it's sole purpose is for backwards compatibility to allows users to easily migrate to 3.x. I guess that's the end of the academic discussion ;-) I'm 100% behind this idea. It's always possible to get whatever binding behavior you want by manipulating the vertex arrays to provide per-vertex data. The only real reason to have the other bindings these days is for convenience. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi all, Yeeek... think I'm gonna BIND_PER_VERTEX+GL_FLAT finally! ;p Joking apart, I agree with the fact it's deprecated and should just stick with OSG 2.8 bahaviour. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Jason Daly jd...@ist.ucf.edu a écrit : On 01/10/2011 11:26 AM, Robert Osfield wrote: Hi Guys, For reference on this discussion, non of BIND_PER_PRIMITIVE or the proposed BIND_PER_ELEMENT are supported by modern OpenGL/OpenGL ES, the old BIND_PER_PRIMITIVE is very much deprecated and only kept around for backwards compatibility. Given even BIND_PER_PRIMTIIVE is deprecated there is absolutely no way I'm about to merge another enum and implementation that is not supported by OpenGL and forces the OSG to use slow paths and will forever have been screaming on the list DO NOT USE THIS FEATURE as your performance will be crap Perhaps I should just remove BIND_PER_PRIMITIVE and vertex indices and provide automatic conversion for all crappy osg::Geometry? This is certainly something I'm planning to do for OSG-3.2 as the current situation is if a feature is there it will be used and abused. For OSG-3.0 the only change we should make for the BIND_PER_PRIMITIVE implementation is to make sure it's consistent with 2.8.x as it's sole purpose is for backwards compatibility to allows users to easily migrate to 3.x. I guess that's the end of the academic discussion ;-) I'm 100% behind this idea. It's always possible to get whatever binding behavior you want by manipulating the vertex arrays to provide per-vertex data. The only real reason to have the other bindings these days is for convenience. --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
Re: [osg-users] BIND_PER_PRIMITIVE broken?
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
Re: [osg-users] BIND_PER_PRIMITIVE broken?
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? Robert. On Fri, Jan 7, 2011 at 10:04 PM, Wojciech Lewandowski lewandow...@ai.com.pl wrote: Hi, Jason I generally agree with your post that binding per primitive is a scene graph thing, but I would disagree with such BIND_PER_PRIMITIVE interpretation: BIND_PER_PRIMITIVE is a scene graph thing, it has nothing to do with pure OpenGL. All BIND_PER_PRIMITIVE means is this: glBegin(GL_TRIANGLE_STRIP); glNormal3f(...); glVertex3f(...); glVertex3f(...); ... glVertex3f(...); glEnd(); OpenGL argument against your example: you may also write similar 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(); 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(); 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 ? Wojtek Lewandowski ___ 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
Re: [osg-users] BIND_PER_PRIMITIVE broken?
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
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Robert all,
I also got a problem with BIND_PER_PRIMITIVE (yes, I know I should not use it!
;) ). When having TRIANGLE_STRIP, with normals per primitive, I got one normal
per triangle strip, whereas OpenGL seem to say I should have one normal per
triangle. Am I wrong?
The geometry looks like :
Geometry {
// blah blah blah...
PrimitiveSets 3
{
DrawArrays TRIANGLE_STRIP 0 219
DrawArrays TRIANGLE_STRIP 219 19
DrawArrays TRIANGLE_STRIP 238 15
}
VertexArray Vec3Array 253
{
blah blah blah...
}
NormalBinding PER_PRIMITIVE
NormalArray UniqueID Vec3Array_1 Vec3Array 247
{
0 0 1
0 1 0
1 0 1
... and all other normals, which are not used at all.
}
}
In this case the first DrawArrays uses normal 0, the second uses normal 1...
I looked into ArrayDispatchers, but I was unable to find something usefult to
me.
Help, please?
Thanks.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Robert Osfield robert.osfi...@gmail.com a écrit :
Hi Don,
On Tue, Sep 21, 2010 at 12:13 AM, Don Leich d...@ilight.com wrote:
I confirmed that the bug persists in today's SVN trunk. In the
example
already supplied the overall color is not applied when normals are
given as BIND_PER_PRIMITIVE.
I've just tested svn/trunk and 2.9.3 and can confirm that there is
different behaviour.
I've also isolated the two geometries that use BIND_PER_PRIMITIVE and
they just use this binding for normals, but have no colour array
assigned at all. So... they will be inheriting their colour from
other geometries in a completely undefined way.
This to me doesn't look like a bug at all, but an issue with a
under-defined scene graph, and just by luck it's worked before.
Please assign colours to all the geometries that need it and then
re-test.
Robert.
___
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
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi again,
About my problem with triangle strips (see below), I found something strange in
Geometry::drawImplementation() :
unsigned int primLength;
switch(mode)
{
case(GL_POINTS):primLength=1; break;
case(GL_LINES): primLength=2; break;
case(GL_TRIANGLES): primLength=3; break;
case(GL_QUADS): primLength=4; break;
default:primLength=0; break; // compute later when
=0.
}
// draw primitives by the more flexible slow path,
// sending OpenGL glBegin/glVertex.../glEnd().
switch(primitiveset-getType())
{
case(PrimitiveSet::DrawArraysPrimitiveType):
{
if (primLength==0) primLength=primitiveset-getNumIndices();
If i understand well, it means that when having GL_TRIANGLE_STRIP, then
primLength is set to the length of the strip, not the length of a triangle.
Shouldn't the switch statement be extended with other types ?
case(GL_TRIANGLE_FAN):
case(GL_TRIANGLE_STRIP):
case(GL_TRIANGLES): primLength=3; break;
Or is 'primLength' used for another purpose ?
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Sukender suky0...@free.fr a écrit :
Hi Robert all,
I also got a problem with BIND_PER_PRIMITIVE (yes, I know I should not
use it! ;) ). When having TRIANGLE_STRIP, with normals per primitive,
I got one normal per triangle strip, whereas OpenGL seem to say I
should have one normal per triangle. Am I wrong?
The geometry looks like :
Geometry {
// blah blah blah...
PrimitiveSets 3
{
DrawArrays TRIANGLE_STRIP 0 219
DrawArrays TRIANGLE_STRIP 219 19
DrawArrays TRIANGLE_STRIP 238 15
}
VertexArray Vec3Array 253
{
blah blah blah...
}
NormalBinding PER_PRIMITIVE
NormalArray UniqueID Vec3Array_1 Vec3Array 247
{
0 0 1
0 1 0
1 0 1
... and all other normals, which are not used at all.
}
}
In this case the first DrawArrays uses normal 0, the second uses
normal 1...
I looked into ArrayDispatchers, but I was unable to find something
usefult to me.
Help, please?
Thanks.
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- Robert Osfield robert.osfi...@gmail.com a écrit :
Hi Don,
On Tue, Sep 21, 2010 at 12:13 AM, Don Leich d...@ilight.com wrote:
I confirmed that the bug persists in today's SVN trunk. In the
example
already supplied the overall color is not applied when normals are
given as BIND_PER_PRIMITIVE.
I've just tested svn/trunk and 2.9.3 and can confirm that there is
different behaviour.
I've also isolated the two geometries that use BIND_PER_PRIMITIVE
and
they just use this binding for normals, but have no colour array
assigned at all. So... they will be inheriting their colour from
other geometries in a completely undefined way.
This to me doesn't look like a bug at all, but an issue with a
under-defined scene graph, and just by luck it's worked before.
Please assign colours to all the geometries that need it and then
re-test.
Robert.
___
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
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Sukender,
Do you an online reference to confirm the interpretation of per
primitive binding when using triangles and quad strips?
It does sound like your suggestion of adding GL_TRIANGLE_STRIP and FAN
to the switch statement setting the primitive length might be
appropriate. Could you implement this and test it out?
Robert.
On Fri, Jan 7, 2011 at 2:16 PM, Sukender suky0...@free.fr wrote:
Hi again,
About my problem with triangle strips (see below), I found something strange
in Geometry::drawImplementation() :
unsigned int primLength;
switch(mode)
{
case(GL_POINTS): primLength=1; break;
case(GL_LINES): primLength=2; break;
case(GL_TRIANGLES): primLength=3; break;
case(GL_QUADS): primLength=4; break;
default: primLength=0; break; // compute later when
=0.
}
// draw primitives by the more flexible slow path,
// sending OpenGL glBegin/glVertex.../glEnd().
switch(primitiveset-getType())
{
case(PrimitiveSet::DrawArraysPrimitiveType):
{
if (primLength==0)
primLength=primitiveset-getNumIndices();
If i understand well, it means that when having GL_TRIANGLE_STRIP, then
primLength is set to the length of the strip, not the length of a triangle.
Shouldn't the switch statement be extended with other types ?
case(GL_TRIANGLE_FAN):
case(GL_TRIANGLE_STRIP):
case(GL_TRIANGLES): primLength=3; break;
Or is 'primLength' used for another purpose ?
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Sukender suky0...@free.fr a écrit :
Hi Robert all,
I also got a problem with BIND_PER_PRIMITIVE (yes, I know I should not
use it! ;) ). When having TRIANGLE_STRIP, with normals per primitive,
I got one normal per triangle strip, whereas OpenGL seem to say I
should have one normal per triangle. Am I wrong?
The geometry looks like :
Geometry {
// blah blah blah...
PrimitiveSets 3
{
DrawArrays TRIANGLE_STRIP 0 219
DrawArrays TRIANGLE_STRIP 219 19
DrawArrays TRIANGLE_STRIP 238 15
}
VertexArray Vec3Array 253
{
blah blah blah...
}
NormalBinding PER_PRIMITIVE
NormalArray UniqueID Vec3Array_1 Vec3Array 247
{
0 0 1
0 1 0
1 0 1
... and all other normals, which are not used at all.
}
}
In this case the first DrawArrays uses normal 0, the second uses
normal 1...
I looked into ArrayDispatchers, but I was unable to find something
usefult to me.
Help, please?
Thanks.
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- Robert Osfield robert.osfi...@gmail.com a écrit :
Hi Don,
On Tue, Sep 21, 2010 at 12:13 AM, Don Leich d...@ilight.com wrote:
I confirmed that the bug persists in today's SVN trunk. In the
example
already supplied the overall color is not applied when normals are
given as BIND_PER_PRIMITIVE.
I've just tested svn/trunk and 2.9.3 and can confirm that there is
different behaviour.
I've also isolated the two geometries that use BIND_PER_PRIMITIVE
and
they just use this binding for normals, but have no colour array
assigned at all. So... they will be inheriting their colour from
other geometries in a completely undefined way.
This to me doesn't look like a bug at all, but an issue with a
under-defined scene graph, and just by luck it's worked before.
Please assign colours to all the geometries that need it and then
re-test.
Robert.
___
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
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Thanks for your answer Robert.
About sources, I do not have (yet) an official source, but only a large bunch
of forums/discussions saying the same thing. I'd like to find a more reliable
source of info before starting.
And of course I can do it, but unfortunately not soon (= a few days).
= If anyone knows about the subject, please confirm (or not) there should be
one normal per triangle when having triangle strip (or triangle fan / quad
strip) + bind per primitive. Thanks.
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Robert Osfield robert.osfi...@gmail.com a écrit :
Hi Sukender,
Do you an online reference to confirm the interpretation of per
primitive binding when using triangles and quad strips?
It does sound like your suggestion of adding GL_TRIANGLE_STRIP and
FAN
to the switch statement setting the primitive length might be
appropriate. Could you implement this and test it out?
Robert.
On Fri, Jan 7, 2011 at 2:16 PM, Sukender suky0...@free.fr wrote:
Hi again,
About my problem with triangle strips (see below), I found something
strange in Geometry::drawImplementation() :
unsigned int primLength;
switch(mode)
{
case(GL_POINTS): primLength=1; break;
case(GL_LINES): primLength=2; break;
case(GL_TRIANGLES): primLength=3; break;
case(GL_QUADS): primLength=4; break;
default: primLength=0; break; // compute
later when =0.
}
// draw primitives by the more flexible slow path,
// sending OpenGL glBegin/glVertex.../glEnd().
switch(primitiveset-getType())
{
case(PrimitiveSet::DrawArraysPrimitiveType):
{
if (primLength==0)
primLength=primitiveset-getNumIndices();
If i understand well, it means that when having GL_TRIANGLE_STRIP,
then primLength is set to the length of the strip, not the length of a
triangle. Shouldn't the switch statement be extended with other types
?
case(GL_TRIANGLE_FAN):
case(GL_TRIANGLE_STRIP):
case(GL_TRIANGLES): primLength=3; break;
Or is 'primLength' used for another purpose ?
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- Sukender suky0...@free.fr a écrit :
Hi Robert all,
I also got a problem with BIND_PER_PRIMITIVE (yes, I know I should
not
use it! ;) ). When having TRIANGLE_STRIP, with normals per
primitive,
I got one normal per triangle strip, whereas OpenGL seem to say I
should have one normal per triangle. Am I wrong?
The geometry looks like :
Geometry {
// blah blah blah...
PrimitiveSets 3
{
DrawArrays TRIANGLE_STRIP 0 219
DrawArrays TRIANGLE_STRIP 219 19
DrawArrays TRIANGLE_STRIP 238 15
}
VertexArray Vec3Array 253
{
blah blah blah...
}
NormalBinding PER_PRIMITIVE
NormalArray UniqueID Vec3Array_1 Vec3Array 247
{
0 0 1
0 1 0
1 0 1
... and all other normals, which are not used at all.
}
}
In this case the first DrawArrays uses normal 0, the second uses
normal 1...
I looked into ArrayDispatchers, but I was unable to find something
usefult to me.
Help, please?
Thanks.
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- Robert Osfield robert.osfi...@gmail.com a écrit :
Hi Don,
On Tue, Sep 21, 2010 at 12:13 AM, Don Leich d...@ilight.com
wrote:
I confirmed that the bug persists in today's SVN trunk. In
the
example
already supplied the overall color is not applied when normals
are
given as BIND_PER_PRIMITIVE.
I've just tested svn/trunk and 2.9.3 and can confirm that there
is
different behaviour.
I've also isolated the two geometries that use
BIND_PER_PRIMITIVE
and
they just use this binding for normals, but have no colour array
assigned at all. So... they will be inheriting their colour
from
other geometries in a completely undefined way.
This to me doesn't look like a bug at all, but an issue with a
under-defined scene graph, and just by luck it's worked before.
Please assign colours to all the geometries that need it and
then
re-test.
Robert.
___
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
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Sukender, About sources, I do not have (yet) an official source, but only a large bunch of forums/discussions saying the same thing. I'd like to find a more reliable source of info before starting. And of course I can do it, but unfortunately not soon (= a few days). = If anyone knows about the subject, please confirm (or not) there should be one normal per triangle when having triangle strip (or triangle fan / quad strip) + bind per primitive. Thanks. I don't have reliable info to add, but I wonder 2 things: First, does OpenGL interpret one primitive as one draw call (= one *PrimitiveSet*) ? If so, then that's your answer, BIND_PER_PRIMITIVE would mean one normal for the whole triangle strip. Second, if BIND_PER_PRIMITIVE for a triangle strip could give you a normal for each triangle, how would OpenGL manage the 2 shared vertices between 2 triangles of the strip? I always thought in the case of triangles, one normal per primitive meant using the same normal for all 3 vertices of the triangle, but in the case of a triangle strip, the same vertex is part of 2 triangles, so which triangle's normal will be used? I guess the answer to the first question will answer the second too and will show me if my comprehension of this was totally wrong... :-) Might be interesting to do this in a pure OpenGL app. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
On 01/07/2011 10:52 AM, Jean-Sébastien Guay wrote: I don't have reliable info to add, but I wonder 2 things: First, does OpenGL interpret one primitive as one draw call (= one *PrimitiveSet*) ? If so, then that's your answer, BIND_PER_PRIMITIVE would mean one normal for the whole triangle strip. BIND_PER_PRIMITIVE is a scene graph thing, it has nothing to do with pure OpenGL. All BIND_PER_PRIMITIVE means is this: glBegin(GL_TRIANGLE_STRIP); glNormal3f(...); glVertex3f(...); glVertex3f(...); ... glVertex3f(...); glEnd(); BIND_PER_PRIMITIVE will always revert to the slow glBegin/glEnd path. This is because OpenGL has no way to do per-primitive normals or colors using glDrawArrays() or glDrawElements(). So yes, BIND_PER_PRIMITIVE means one normal for the whole primitive. In this case the primitive is the triangle strip (the argument to glBegin() ). I suppose you could change the normal in the middle of the strip with pure OpenGL, but I have no idea what it would end up looking like (might have to check an older spec for that). My guess is that it wouldn't be what you're looking for, though. I believe the primitive length question is similar. It refers to how many vertices per primitive. In this case, the primitive is the triangle strip, and the length is the number of vertices in the strip. I'm pretty sure that setting that to 3 in the switch statement you referred to is wrong. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
On 01/07/2011 11:33 AM, Jason Daly wrote: I suppose you could change the normal in the middle of the strip with pure OpenGL, but I have no idea what it would end up looking like (might have to check an older spec for that). My guess is that it wouldn't be what you're looking for, though. Thinking about this some more, it's actually not that complicated. Inside a glBegin()/glEnd() block, you specify a normal for the vertices to follow, so each of those vertices will have that normal. If your goal is to get a faceted appearance with lit geometry, you probably don't want to be using tri-strips at all. As J-S said, you'll always be sharing each normal between two of the triangles in the strip. Even in pure OpenGL, it doesn't seem like it's possible to get one normal per triangle in a tri-strip. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi, Jason I generally agree with your post that binding per primitive is a scene graph thing, but I would disagree with such BIND_PER_PRIMITIVE interpretation: BIND_PER_PRIMITIVE is a scene graph thing, it has nothing to do with pure OpenGL. All BIND_PER_PRIMITIVE means is this: glBegin(GL_TRIANGLE_STRIP); glNormal3f(...); glVertex3f(...); glVertex3f(...); ... glVertex3f(...); glEnd(); OpenGL argument against your example: you may also write similar 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(); 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(); 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 ? Wojtek Lewandowski ___ 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
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Robert,
I am now able to set an overall color for otherwise uncolored
geometries with your suggested fix. I still don't understand why this
is correct. I thought that the setStateSet would set a current color
from it's material which is now OSG seemed to behave until 2.9.3.
osg::Group *primary = gg.getPrimarySurface();
// This used to specify an overall color for otherwise uncolored geometries.
primary-setStateSet( _state.get() );
// Now required to set the overall color directly in the Geode.
// Uses the material associated with the state.
osg::Geode *gg = dynamic_castosg::Geode*(primary-getChild(0));
if ( gg )
_applyColor( gg, _material-getDiffuse(osg::Material::FRONT_AND_BACK));
...
void Material::_applyColor( osg::Geode *gg, osg::Vec4 color )
{
osg::ref_ptrosg::Geode geode = gg;
osg::ref_ptrosg::Vec4Array colors = new osg::Vec4Array( 1 );
(*colors)[ 0 ] = color;
for ( unsigned int ii=0; iigeode-getNumDrawables(); ii++ )
{
osg::Geometry *geom = dynamic_castosg::Geometry*(geode-getDrawable(
ii ));
geom-setColorArray( colors.get() );
geom-setColorBinding( osg::Geometry::BIND_OVERALL );
}
}
-Don
Robert Osfield wrote:
Hi Don,
On Tue, Sep 21, 2010 at 12:13 AM, Don Leich d...@ilight.com wrote:
I confirmed that the bug persists in today's SVN trunk. In the example
already supplied the overall color is not applied when normals are
given as BIND_PER_PRIMITIVE.
I've just tested svn/trunk and 2.9.3 and can confirm that there is
different behaviour.
I've also isolated the two geometries that use BIND_PER_PRIMITIVE and
they just use this binding for normals, but have no colour array
assigned at all. So... they will be inheriting their colour from
other geometries in a completely undefined way.
This to me doesn't look like a bug at all, but an issue with a
under-defined scene graph, and just by luck it's worked before.
Please assign colours to all the geometries that need it and then
re-test.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
On Wed, Sep 22, 2010 at 7:13 PM, Don Leich d...@ilight.com wrote:
Hi Robert,
I am now able to set an overall color for otherwise uncolored
geometries with your suggested fix. I still don't understand why this
is correct. I thought that the setStateSet would set a current color
from it's material which is now OSG seemed to behave until 2.9.3.
osg::Group *primary = gg.getPrimarySurface();
// This used to specify an overall color for otherwise uncolored
geometries.
primary-setStateSet( _state.get() );
That only sets a color if the color mode of the material is OFF. That is
the default for Material; perhaps you've set it to something different in
the material that's in _state?
// Now required to set the overall color directly in the Geode.
// Uses the material associated with the state.
osg::Geode *gg = dynamic_castosg::Geode*(primary-getChild(0));
if ( gg )
_applyColor( gg,
_material-getDiffuse(osg::Material::FRONT_AND_BACK));
...
void Material::_applyColor( osg::Geode *gg, osg::Vec4 color )
{
osg::ref_ptrosg::Geode geode = gg;
osg::ref_ptrosg::Vec4Array colors = new osg::Vec4Array( 1 );
(*colors)[ 0 ] = color;
for ( unsigned int ii=0; iigeode-getNumDrawables(); ii++ )
{
osg::Geometry *geom =
dynamic_castosg::Geometry*(geode-getDrawable( ii ));
geom-setColorArray( colors.get() );
geom-setColorBinding( osg::Geometry::BIND_OVERALL );
}
}
It's always a good idea to set a color for a geometry unless you're sure
that your materials' color modes are OFF.
Tim
-Don
Robert Osfield wrote:
Hi Don,
On Tue, Sep 21, 2010 at 12:13 AM, Don Leich d...@ilight.com wrote:
I confirmed that the bug persists in today's SVN trunk. In the example
already supplied the overall color is not applied when normals are
given as BIND_PER_PRIMITIVE.
I've just tested svn/trunk and 2.9.3 and can confirm that there is
different behaviour.
I've also isolated the two geometries that use BIND_PER_PRIMITIVE and
they just use this binding for normals, but have no colour array
assigned at all. So... they will be inheriting their colour from
other geometries in a completely undefined way.
This to me doesn't look like a bug at all, but an issue with a
under-defined scene graph, and just by luck it's worked before.
Please assign colours to all the geometries that need it and then
re-test.
Robert.
___
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
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Don, On Tue, Sep 21, 2010 at 12:13 AM, Don Leich d...@ilight.com wrote: I confirmed that the bug persists in today's SVN trunk. In the example already supplied the overall color is not applied when normals are given as BIND_PER_PRIMITIVE. I've just tested svn/trunk and 2.9.3 and can confirm that there is different behaviour. I've also isolated the two geometries that use BIND_PER_PRIMITIVE and they just use this binding for normals, but have no colour array assigned at all. So... they will be inheriting their colour from other geometries in a completely undefined way. This to me doesn't look like a bug at all, but an issue with a under-defined scene graph, and just by luck it's worked before. Please assign colours to all the geometries that need it and then re-test. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
I confirmed that the bug persists in today's SVN trunk. In the example already supplied the overall color is not applied when normals are given as BIND_PER_PRIMITIVE. -Don ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi J-S, I'm using TortoiseSVN on a Windows system. This has a right-click menu entry for SVN Checkout. The GUI can only handle the URL and was confused by the spaceOpenSceneGraph after trunk. You're exactly right that I was pulling down and eternity and a half. Today, after contemplating installing svn on a SuSE linux system, I got what I wanted with http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk which I swear I tried Friday. Thanks for keeping an eye out. -Don Jean-Sébastien Guay wrote: Hi Don, I bailed on my svn import. TortoiseSVN wouldn't work with the checkout command as documented. I got the checkout going, but I seemed to be getting way more than I wanted. After more time than I had to spend I still didn't have the OSG source. What command did you try? This page gives you the command you should have been using: http://www.openscenegraph.org/projects/osg/wiki/Downloads/SVN which is: svn checkout http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk OpenSceneGraph That gets you only the trunk source tree, i.e. what you need. It should be a pretty speedy checkout, at least it is whenever I do it on a new machine (which I've done a few times in the past month or two). I would understand it taking a lot of time if you had removed one or especially two levels from the path, i.e. if you did svn checkout http://www.openscenegraph.org/svn/osg/OpenSceneGraph/ That would checkout all the branches, tags and trunk, i.e. it would take an eternity and a half, in addition to taking more disk space than you probably have... SVN branches and tags are shallow copies unless something changes, so they're lightweight on the server, but as soon as you download them on your machine they take the full size of all files. Hope this helps, J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Don, I'm using TortoiseSVN on a Windows system. This has a right-click menu entry for SVN Checkout. The GUI can only handle the URL and was confused by the spaceOpenSceneGraph after trunk. Heh, that's the destination directory when using the command-line SVN... So you're right, in Tortoise you just need the URL, which was http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Don, This is clearly a bug, could you try the svn/trunk version of the OSG to see if it's still present? If so could you provide an .osg file that reproduces the problem? As a general note, BIND_PER_PRIMITIVE is bad for performance and portability, it's there for convenience of backwards compatibility but it's really not something I would recommend anyone using. Robert. On Fri, Sep 10, 2010 at 12:34 AM, Don Leich d...@ilight.com wrote: I know it's slow, but we'd been using BIND_PER_PRIMITIVE mainly for backward compatibility for faceted shading and coloring occasionally. After our recent upgrade from osg-2.8.3 to 2.9.8 everything rendered with BIND_PER_PRIMITIVE is wrong -- bad colors or material properties ignored. Is this change known? Is there any magic that may make it behave? Am I going to have to bit the bullet and duplicate vertices to match the normal per facet I've got? -Don Leich ___ 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
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Robert,
I bailed on my svn import. TortoiseSVN wouldn't work with the checkout
command as documented. I got the checkout going, but I seemed to be getting way
more than I wanted. After more time than I had to spend I still didn't
have the OSG source.
I did manage to produce a test file. There are two small meshes, one colored
overall magenta, the other cyan. Both are 50% transparent. This is
what I see in a 2.8.3 viewer. The magenta mesh BIND_PER_VERTEX normals.
The cyan has BIND_PER_PRIMITIVE. With a 2.9.8 viewer the semi-tranparent
magenta mesh shows as opaque gray.
-Don Leich
MatrixTransform {
UniqueID MatrixTransform_0
name il::Scene
nodeMask 0x
cullingActive TRUE
UpdateCallbacks {
NodeCallback {
}
}
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 1
Group {
UniqueID Group_1
name scene
nodeMask 0x
cullingActive TRUE
num_children 4
MatrixTransform {
UniqueID MatrixTransform_2
name il::LightManager
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 2
MatrixTransform {
UniqueID MatrixTransform_3
name il::Light
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 1
LightSource {
UniqueID LightSource_4
nodeMask 0x
cullingActive FALSE
StateSet {
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
GL_LIGHT0 ON
}
referenceFrame RELATIVE
Light {
UniqueID Light_5
DataVariance DYNAMIC
light_num 0
ambient 0.15 0.15 0.15 1
diffuse 0.7 0.7 0.7 1
specular 1 1 1 1
position -0.57735 -0.57735 -0.57735 0
direction 0.57735 0.57735 0.57735
constant_attenuation 1
linear_attenuation 0
quadratic_attenuation 0
spot_exponent 0
spot_cutoff 180
}
}
}
MatrixTransform {
UniqueID MatrixTransform_6
name il::Light
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 1
LightSource {
UniqueID LightSource_7
nodeMask 0x
cullingActive FALSE
StateSet {
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
GL_LIGHT0 ON
}
referenceFrame RELATIVE
Light {
UniqueID Light_8
DataVariance DYNAMIC
light_num 1
ambient 0.15 0.15 0.15 1
diffuse 0.7 0.7 0.7 1
specular 1 1 1 1
position 0.57735 0.57735 0.57735 0
direction -0.57735 -0.57735 -0.57735
constant_attenuation 1
linear_attenuation 0
quadratic_attenuation 0
spot_exponent 0
spot_cutoff 180
}
}
}
}
MatrixTransform {
UniqueID MatrixTransform_9
name scene world transform
nodeMask 0x
cullingActive TRUE
StateSet {
UniqueID StateSet_10
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
GL_LIGHT0 ON
GL_LIGHT1 ON
}
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 1
MatrixTransform {
UniqueID MatrixTransform_11
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 1
MatrixTransform {
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 8
MatrixTransform {
name id:-216
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
}
MatrixTransform {
name id:-206
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Don, I bailed on my svn import. TortoiseSVN wouldn't work with the checkout command as documented. I got the checkout going, but I seemed to be getting way more than I wanted. After more time than I had to spend I still didn't have the OSG source. What command did you try? This page gives you the command you should have been using: http://www.openscenegraph.org/projects/osg/wiki/Downloads/SVN which is: svn checkout http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk OpenSceneGraph That gets you only the trunk source tree, i.e. what you need. It should be a pretty speedy checkout, at least it is whenever I do it on a new machine (which I've done a few times in the past month or two). I would understand it taking a lot of time if you had removed one or especially two levels from the path, i.e. if you did svn checkout http://www.openscenegraph.org/svn/osg/OpenSceneGraph/ That would checkout all the branches, tags and trunk, i.e. it would take an eternity and a half, in addition to taking more disk space than you probably have... SVN branches and tags are shallow copies unless something changes, so they're lightweight on the server, but as soon as you download them on your machine they take the full size of all files. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
