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); > > > >> glVertex3f(0, 1, 0); > > > >> glVertex3f(1, 0, 0); > > > >> glColor4f( 0, 1, 0, 1 ); // GREEN > > > >> glVertex3f(1, 1, 0); > > > >> glEnd(); > > > > > > Yes, I mentioned that in my previous post. It doesn't take away > > from > > > > > > the fact that the triangle strip is considered a single primitive. > > > > > > I actually wonder what the colors would look like here. Did you > > > actually run this code? My guess would be that the final vertex > is > > > green, but the final triangle would blend from red to green across > > its > > > > > > surface, because its two other vertices were red (as specified in > > the > > > > > > code). I could be wrong (I haven't run the code myself), but > > that's > > > > > > what I would expect. Even if you consider each triangle in the > > strip > > > a > > > different "primitive", you still couldn't get a set of completely > > red > > > > > > triangles, followed by a completely green triangle, which is what > > the > > > OP > > > is looking for. > > > > > > >> Last argument is actually a postulate for OSG clarity. We have > > > >> BIND_PER_PRIMITIVE_SET flag. Shouldn't this flag be rather used > > for > > > the > > > >> situation where we want to one normal / one color etc for all > > > triangles in > > > >> tristrip ? > > > > > > If I understand you correctly, then yes. BIND_PER_PRIMITIVE in > the > > > case > > > of triangle strips should mean the same normal/color for each > entire > > > triangle strip (that's how Performer used to treat it as well). > If > > I > > > > > > remember correctly, the OP was looking to get different normals > for > > > each > > > triangle in the strip (to produce a faceted appearance, I think). > I > > > don't believe this is possible even in pure OpenGL. The only way > to > > > do > > > it is to use distinct triangles for primitives. > > > > > > --"J" > > > _______________________________________________ > > > osg-users mailing list > > > osg-users@lists.openscenegraph.org > > > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ > > osg-users mailing list > > osg-users@lists.openscenegraph.org > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > _______________________________________________ > > osg-users mailing list > > osg-users@lists.openscenegraph.org > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ > 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
