I have written a terrain class, which displays a patch of terrain (using a heightmap) with triangle strips. The problem is, that the glVertex3f() function in the renderer raises a division by zero exception. When it occurs, the vertex coordinates are (180; 20; 50), the camera (set with gluLookAt) is at (70; 50; 85), looking at (10; 0; 25) with the upvector pointing up on the Y-axis. I am using perspective projection (fov=60 deg.). (All coordinates are absolute, world coords.) Could anyone please help me ? Thanks, Gonosz

can''t see any problem with the info so far.

If the error is occurring inside the opengl driver (ie NVOPENGL.dll for NVidia), then please post a small portion of the code (the enclosing glBegin/glEnd where it occurs, where you setup your model/view projection ie gluLookAt and where you set up your perspective projection)

div by zero in the driver is usually easier than it looks, its just tracking the right number.

If it is in your code, diligently check your divisions

~~~
Cheers!
Brett Porter
PortaLib3D : A portable 3D game/demo libary for OpenGL
Community Service Announcement: Read How to ask questions the smart way before posting!

First of all, sorry for the late answer. Since school started I hardly had time to sleep )

So. When I get a strange error, I usually write a detailed "log", I''ll translate most of that to English.

Today I got a strange division by zero exception from the GLtest project. It is caused by a glVertex3f, in the CTerrain::Render() funtion. The debugger doesn''t give any information, but the instruction just before glVertex is executed, and the one just after it isn''t - so it must be the glVertex.

The core of the function is the double loop:

for (y=1; y < height-1; y++)
{
glBegin(GL_TRIANGLE_STRIP);
for (x=0; x < width; x++)
{
color=_getcolor(map[x+y*width]/colordivider);
glColor3f(color, color, color);
glTexCoord2f((GLfloat)x/4,(GLfloat)y/4);
glVertex3f(xlines[x],
map[x+y*width],
ylines[y]);
color=_getcolor(map[x+(y-1)*width]/colordivider);
glColor3f(color, color, color);
glTexCoord2f((GLfloat)x/4,(GLfloat)(y-1)/4);
glVertex3f(xlines[x],
map[x+(y-1)*width],
ylines[y-1]);
}
glEnd();
}

xlines[x] : x*grid spacing (10x)
ylines[y] : y*grid spacing (10y)

I logged the actual camera positions and directions, and created a "modified version" of the code: I set a fixed camera to the values written above, and cleared out any matrix changes in the other files. When I rendered the terrain, the div by zero occured again, of course at the same vertex. I removed any extra lines and optimizations, like xlines, ylines, color changing, texcoord setting, and disabled lighting and texture usage as well.
It is strange, that when I output only the faulty vertex using the same conditions, the program will run! When I output it height*width times, it will work too... so I changed the faulty glvertex3f so as to learn, which coordinate can be the faulty one. I found out, that the problem is caused by the 36. vertex on the z=50, y=20 line, if its x coordinate is set like offset+10*innerloopcounter, not depending on the loopcounter''s value! I mean, if I change the direction of the inner loop, the x=11 vertex will cause the exception - 47-11=36... If I change the grid spacing (10 by default), or at least one of the other coordinates, the program will run finely - until it finds another faulty point... if I skip the 36. point, the 37. will generate the same error. If I display each vertex twice, the 18. point will crash on line y=5. Using the unmodified code, it happened many times, that after running for some minutes finely it crashed with a div by zero. (The program displays a terrain, and the camera "wanders" above it, changing direction at the edges.)
I asked this question in the OpenGL forum, and I got an answer too: MButchers suggested disabling the floating points exceptions, but I couldn''t find any information on it neither in the help file, nor in the menus. I found a "disable exceptions" option, but it didn''t work. Finally, I found the signal.h help, which said, that I can make the program ignore these faulty divs using signal(SIGFPE, SIGIGN); But when my program gets to a faulty vertex, it continues running, and the framerate drops to about 0.5 fps, and sometimes it still divides by zero... (by the way, I am using a Borland C++ Builder 3)

So this is it.

Thank you for your help,

Gonosz

ps.: huh this *is* long )

hi there,

sorry its - Set8087CW($133F);

Whatever happened to common naming conventions??

Mark

try changing width to width-1 in the second for loop, see if that helps

Feel free to email me.

Mark: thanks. But I couldn''t try it, because it just wouldn''t work without the VCL, which I don''t want to use... do you know any way how to use it without the whole VCL ?

Otherwise, the only solution would be to switch to Visual C...

Lord Karnus: the original inner loop was from x=0 to x
see you,

Gonosz

Hi again,

At last! I solved the problem: I am now using the Visual C++ - and there is no error... and the program seems to be running faster too.

Thank you for your help,

Gonosz|0