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
