PDA

View Full Version : NV_evaluators and divide by zero error



Diapolo
02-17-2002, 12:28 PM
Hi,

I have got a small problem with the NV_evaluators, if I try:




float CPTS[4][4][4] = {{{-6.0f, 6.0f, 0.0f, 1.0f}, {-2.0f, 6.0f, 0.0f, 1.0f}, {2.0f, 6.0f, 0.0f, 1.0f}, {6.0f, 6.0f, 0.0f, 1.0f}},
{{-6.0f, 2.0f, 0.0f, 1.0f}, {-2.0f, 2.0f, 0.0f, 1.0f}, {2.0f, 2.0f, 0.0f, 1.0f}, {6.0f, 2.0f, 0.0f, 1.0f}},
{{-6.0f, -2.0f, 0.0f, 1.0f}, {-2.0f, -2.0f, 0.0f, 1.0f}, {2.0f, -2.0f, 0.0f, 1.0f}, {6.0f, -2.0f, 0.0f, 1.0f}},
{{-6.0f, -6.0f, 0.0f, 1.0f}, {-2.0f, -6.0f, 0.0f, 1.0f}, {2.0f, -6.0f, 0.0f, 1.0f}, {6.0f, -6.0f, 0.0f, 1.0f}}};

float CPTS_tex[4][4][4] = {{{0.0f, 1.0f, 0.0f, 1.0f}, {0.33f, 1.0f, 0.0f, 1.0f}, {0.66f, 1.0f, 0.0f, 1.0f}, {1.0f, 1.0f, 0.0f, 1.0f}},
{{0.0f, 0.66f, 0.0f, 1.0f}, {0.33f, 0.66f, 0.0f, 1.0f}, {0.66f, 0.66f, 0.0f, 1.0f}, {1.0f, 0.66f, 0.0f, 1.0f}},
{{0.0f, 0.33f, 0.0f, 1.0f}, {0.33f, 0.33f, 0.0f, 1.0f}, {0.66f, 0.33f, 0.0f, 1.0f}, {1.0f, 0.33f, 0.0f, 1.0f}},
{{0.0f, 0.0f, 0.0f, 1.0f}, {0.33f, 0.0f, 0.0f, 1.0f}, {0.66f, 0.0f, 0.0f, 1.0f}, {1.0f, 0.0f, 0.0f, 1.0f}}};

float TESS[4] = {16.0f, 16.0f, 16.0f, 16.0f};

glEnable(GL_EVAL_VERTEX_ATTRIB0_NV);

glEnable(GL_EVAL_FRACTIONAL_TESSELLATION_NV);

MainLoop
{
// other stuff ...

glMapControlPointsNV(GL_EVAL_2D_NV, 0, GL_FLOAT, (4 * sizeof(GLfloat)), (4 * 4 * sizeof(GLfloat)), 4, 4, GL_FALSE, CPTS);
glMapControlPointsNV(GL_EVAL_2D_NV, 8, GL_FLOAT, (4 * sizeof(GLfloat)), (4 * 4 * sizeof(GLfloat)), 4, 4, GL_FALSE, CPTS_tex);
glMapParameterfvNV(GL_EVAL_2D_NV, GL_MAP_TESSELLATION_NV, TESS);

glEvalMapsNV(GL_EVAL_2D_NV, GL_FILL);

// ... other stuff
}


I get an divide by zero error, if the glEvalMapsNV(GL_EVAL_2D_NV, GL_FILL); is executed.
If I leave out the glEnable(GL_EVAL_FRACTIONAL_TESSELLATION_NV); call, there is no error.

I had checked for GL errors, but the function for that returned none!

Any ideas for this one?

Diapolo

richardve
02-17-2002, 01:49 PM
What compiler are you using?

Diapolo
02-17-2002, 02:58 PM
Iīm using Borland C++ Builder 5.0 (Build 12.34) Update Pack 1.

Mazy
02-17-2002, 03:18 PM
Im not sure but i think a lot of stuff in the opengl on win32 can give you that error if you dont set the FPU flags correctly

Set8087CW($133F);

Diapolo
02-17-2002, 03:44 PM
Thatīs the first divide by zero error I saw, during my hobby OGL coding sessions http://www.opengl.org/discussion_boards/ubb/smile.gif.

But I donīt have a clue, how to use the command you specified for my Borland Compiler http://www.opengl.org/discussion_boards/ubb/frown.gif.

Diapolo

richardve
02-17-2002, 04:10 PM
Originally posted by Diapolo:
Iīm using Borland C++ Builder 5.0 (Build 12.34) Update Pack 1.

Exactly what I was thinking http://www.opengl.org/discussion_boards/ubb/smile.gif

There was another topic about this a few months ago, altough I can't find it right now, so I'll give you the solution again:




#ifdef __BORLANDC__
#include
_control87(MCW_EM,MCW_EM);
#endif


Add this to the beginning of your program (before calling any GL function)

Diapolo
02-17-2002, 05:08 PM
I tried the code you posted, but I donīt think my compiler likes it *g*.

I get 5 error messages:

- incompatible filename in include command
- typename expected
- redeclaration of _control87 with other type
- wrong initialization
- ) expected

I translated them from german, perhaps the meaning is sligthly different.
And ideas for this?

Diapolo

richardve
02-17-2002, 05:21 PM
Heh.. sorry, stupid HTML http://www.opengl.org/discussion_boards/ubb/smile.gif

You should replace




#include


with




#include <float.h>


http://www.opengl.org/discussion_boards/ubb/smile.gif

Diapolo
02-18-2002, 06:25 AM
Thank you very much, now the code works http://www.opengl.org/discussion_boards/ubb/smile.gif.

But Iīm asking myself, why the floating point errors have to be ignored or why this function need to divide something by zero?

Diapolo

richardve
02-18-2002, 12:09 PM
I can only tell you that the MSVC compiler disables these divide errors by default and the Borland C/C++ compiler doesn't.

But IIRC D3D has the same problem so it's probably not OGL throwing these errors.


[This message has been edited by richardve (edited 02-18-2002).]