PDA

View Full Version : sanity check



zed
09-14-2005, 10:50 PM
the spheres are contructed in a display list, the tips are tri_fans and the middle is made from quad_strips, the quad strips work fine its only the tri_fans that have the problem but only if i have the glnormal call in there

im getting this on a gffx with 77.72 drivers.

// good picture
glNormal3f( 0,1,0 );
// draw the tips as tri_fans
glBegin( GL_TRIANGLE_FAN );
v.x = sin( 0.0 ) * sin( 0.0 ); // blah blah
v.z = cos( 0.0 ) * sin( 0.0 );
v.y = cos( 0.0 );
glVertex3fv( center + v*radius );
for ( sl=0; sl<slices+1; sl++ )
{
a = float(sl)*off_R;
v.x = sin( a ) * sin( off_H );
v.z = cos( a ) * sin( off_H );
v.y = cos( off_H );
// glNormal3fv( v );
glVertex3fv( center + v*radius );
}
glEnd();

// bad picture (yes i know the normal aint necessarily unit length)
glBegin( GL_TRIANGLE_FAN );
v.x = sin( 0.0 ) * sin( 0.0 );
v.z = cos( 0.0 ) * sin( 0.0 );
v.y = cos( 0.0 );
glVertex3fv( center + v*radius );
for ( sl=0; sl<slices+1; sl++ )
{
a = float(sl)*off_R;
v.x = sin( a ) * sin( off_H );
v.z = cos( a ) * sin( off_H );
v.y = cos( off_H );
glNormal3fv( v );
glVertex3fv( center + v*radius );
}
glEnd(); http://uk.geocities.com/sloppyturds/good.jpg
http://uk.geocities.com/sloppyturds/bad.jpg

btw this aint important (as i can workaround it and also its only for debugging)

ta zed

Overmind
09-15-2005, 12:57 AM
Sounds like a bug in your vertex class... Perhaps the cast to float* in the glNormal3fv call modifies the value somehow. Also I'm not sure about the lifetime of the temporary vertex that's constructed in the "center + v*radius" calculation, try saving it to a local variable...

EDIT: Just noticed another error, but that shouldn't cause this effect: You don't set the normal for the first vertex in your "bad picture" code.

Btw. your normals are guaranteed to be unit length.
x^2 + y^2 + z^2 == (sin^2(a) + cos^2(a))*sin^2(off_H) + cos^2(off_H) == sin^2(off_H) + cos^2(off_H) == 1 ;)

Zulfiqar Malik
09-15-2005, 02:44 AM
Just a suggestion:

you can look at the freeglut source code (its freely available online as the name points says :D ) for drawing of different primitives. Maybe you can do a comparison and find out your error.

On a side note (probably straight forward), are your vertexes 32-bit floats? I encountered a similar problem because i was using doubles.

zed
09-15-2005, 12:11 PM
this also shows the error (note this is constructed in a display list)
http://uk.geocities.com/sloppyturds/friA.jpg
http://uk.geocities.com/sloppyturds/friB.jpg
2 new screenshots in wireframe as its more apparent (the only difference between the 2 shots is the camera has roatted ie theyre runnning the same pieces of code)

STOPPRESS just chucked the rendering pipeline onto standard VAs and theres no problem, only when the rendering pipeline is set to VBOs.

no gl errors are recorded

to sumerize error occurs when
VBOS active,
the sphere is contructed in DL
only in the TRI_FAN part
and only if i use the glNormal commands

i assume driver bug but unimportant (ive wasted an hour on this + like i said its ultimatly not important i dont wanna spend more time)


Sounds like a bug in your vertex class... Perhaps the cast to float* in the glNormal3fv call modifies the value somehow. Also I'm not sure about the lifetime of the temporary vertex that's constructed in the "center + v*radius" calculation, try saving it to a local variable...-im a bit sceptical as ive been using it for years without incident (and also theres no problem with the other thousands of primitives in the scene


EDIT: Just noticed another error, but that shouldn't cause this effect: You don't set the normal for the first vertex in your "bad picture" code.-true, that came from editting the code (though i believe i stuck a normal command right at the start of the code)


Btw. your normals are guaranteed to be unit length.
x^2 + y^2 + z^2 == (sin^2(a) + cos^2(a))*sin^2(off_H) + cos^2(off_H) == sin^2(off_H) + cos^2(off_H) == 1 thanks for that i suspected they were but werent certain (mathmatical proof is not my strong suit)


n a side note (probably straight forward), are your vertexes 32-bit floats? I encountered a similar problem because i was using doubles.yeah i could see how that would cause problems but no theyre floats

tahnks anyways zed