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