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" <[email protected]> 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 <[email protected]> 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" <[email protected]> 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" <[email protected]> a écrit : > >> > >> > Hi Don, > >> > > >> > On Tue, Sep 21, 2010 at 12:13 AM, Don Leich <[email protected]> > 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 > >> > [email protected] > >> > > >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >> _______________________________________________ > >> osg-users mailing list > >> [email protected] > >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ > > osg-users mailing list > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
