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