PDA

View Full Version : tiny surface visualization problem

mckkv
05-24-2005, 03:09 AM
I have tiny triangle. It's vertix coordinates are(0,0,0), (1E-20,0,0), (0,1E-20,0).

I use

Scale3f(1E+20, 1E+20, 1E+20),

and draw my triangle with

glBegin(GL_TRIANGLES);
glVertex3f(0,0,0);
glVertex3f(1E-20,0,0);
glVertex3f(0,1E-20,0);
glEnd();

so that my triangle has (0,0,0), (1,0,0), (0,1,0) eye coordinates.

Triangle is drawed ok, then the light is off, but then the light is turned on, 'floating point overwlow' error occurs after
glBegin(GL_TRIANGLES) call.

My question is what are actual OpenGL restrictions on scale factor passed to glScalef function?

Is there any other solution for me, other than resizing of my triangle before passing it to OpenGL?

ZbuffeR
05-24-2005, 04:21 AM
Strange, what is your OpenGL implementation ? Can you give more details about your system ? software Microsoft generic ? Nvidia /ATI/whatever ?

If you are unsure, post version given by glinfo2 (http://www.delphi3d.net/hardware/glinfo2.zip) .

EDIT: By the way, if you need precision, better use the "*d" calls, instead of glScalef/glVertex3f use glScaled/glVertex3d, so that doubles can be used by the function.

Relic
05-24-2005, 04:54 AM
Mind that you need to glEnable(GL_NORMALIZE) to get any decent lighting with glScale factors != 1.0.
That said, doubles won't make a difference because most, if not all, OpenGL implementations use 32 bit IEEE floats internally.
The excessive scaling and small input coordinates are killing your precision sooner or later. Don't do this.
If this is because you want to zoom in on something, use a different projection setup instead of scaling.
Best precision is achieved if you keep your coordinates in ranges between +-1.0.

jide
05-24-2005, 05:36 AM
Also there's need for specifying normals for any lighting to work. glEnable (GL_NORMALIZE) would then do the stuff.

Also, float are normally 4 bytes sized. So, values can be range up to exponent 38 (-3.8E38 up to 3.8E38 if I'm not wrong). So maybe the fact that you use scaling to 1E20 and that you specify vertices at 1E-20 - thus giving a range of 1E40 - provokes that overflow.
However, I cannot ensure that. I might be completly wrong. Surely other people will be able to confirm it or not.

Try to use double instead. But according to my opinion, you should apply a default 'virtual' scaling so that you won't have to play with exponents too much so avoiding loosing precision.

mckkv
05-25-2005, 01:09 AM
To ZbuffeR:

Strange, what is your OpenGL implementation ? Can you give more details about your system ? software Microsoft generic ? Nvidia /ATI/whatever ?

Driver version 6.14.10.6177
Vendor NVIDIA Corporation
Renderer GeForce3/AGP/SSE2
OpenGL version 1.5.1

EDIT: By the way, if you need precision, better use the "*d" calls, instead of glScalef/glVertex3f use glScaled/glVertex3d, so that doubles can be used by the function.

Switching from "f" to "d" makes no difference.

mckkv
05-25-2005, 01:33 AM
To Relic:
The excessive scaling and small input coordinates are killing your precision sooner or later. Don't do this.
If this is because you want to zoom in on something, use a different projection setup instead of scaling.

Thank you for your advice. But for now I don't understand what do you mean by 'killing the precision sooner or later'. Can you explain it, please?

mckkv
05-25-2005, 01:37 AM
To jide:
Also, float are normally 4 bytes sized. So, values can be range up to exponent 38 (-3.8E38 up to 3.8E38 if I'm not wrong). So maybe the fact that you use scaling to 1E20 and that you specify vertices at 1E-20 - thus giving a range of 1E40 - provokes that overflow.
However, I cannot ensure that. I might be completly wrong. Surely other people will be able to confirm it or not.

It seems, you are rignt, becaue using of 1E-19 is working ok. Thank you!