precision of coordinates in Panda3D?

it’s said that in Python all float values are calculated in double precision.
i hope it also means that the values are stored in double precision. but i am not sure.

and i am concerned that, in Panda3D, are the coordinates stored in double precision?

here is why i care about that:
in double precision, 900,000.0 is stored as 0x412B774000000000h, when the hex form is added 1h to 0x412B774000000001h, the float value is still 900,000.0 . only when hex form is added 5h to 0x412B774000000005, the float value becomes 900,000.000000001 . if 1 unit stands for 1 meter, the precision is 0.000001 millimeter.

in single float precision, 900,000.0 is store as 0x495BBA00h, when hex form is added 1h to 0x495BBA01h, the float value becomes 900,000.0625 , that is 6.25 centimeters (more than 2 inches)! this gap can easily be seen with human eye. there is no 900,000.03 meter in single float precision.

this problem becomes bigger on greater figures. and 900,000.0 meter is not yet a great figure on the planet earth.

today i found some phenomenon which may indicate that the coordinates of objects are not stored in double precision, or precision is lost in the process of calculation. as i am making a simulator program, visible inprecision is a big problem.

can someone confirm that the coordinates are stored in single float precision? and is there a way to change that?

In Panda, vertices are indeed stored in single precision. There is no way to change this, because your graphics card only handles single-precision vertices as well (mainly to limit bandwidth).

It is a problem when you want to make very large spaces, but you will have the same problem with any 3-D engine.


thanks for your reply.

i think of storing important coordinates in my variables as double float values and let the graphics’ coordinates be inprecise.

Your local variables are double-precision, as Python stores them. It is only vertices, transforms, and other related properties that get sent to the graphics card directly that are single-precision.

Edit: actually, there is a known bug with some DirectX configurations (and a handful of OpenGL configurations as well): the act of opening a window and creating a graphics context forces your FPU into single-precision mode, so that everything becomes single-precision, even your local Python variables. This is indeed a vexing problem.


I can confirm this - the bug is fixed (supposedly) in DirectX 10 and up, though. This bug has caused me a lot of pain (especially since the bug kept making my Lua engine crash), so I understand completely.

so is there a way to prevent the bug?
i am using DX9 and i at least need my Python variables to be in double precision.

We thought we had a solution that went in at 1.7.1, but perhaps there are some graphics drivers that still have this problem even with our fix, and perhaps you are one of the unlucky individuals with such a driver. I assume you are using Panda3D version 1.7.2?

If you temporarily switch to OpenGL or tinydisplay, do you still have the single-precision problem?


i am using 1.72 .
i can confirm that in OpenGL, the coordinates of visual objects are also inprecise like in DX9.
i can’t test the precision of Python’s variables now - i am new to Python and haven’t setup any system except the only one Panda3D project which hasn’t got much physics calculation.

You mean node position, like nodePath.setPos()? As I said above, these values are always single-precision, and this is not a bug.

You can’t? How about:

x = 900000.03
print x

But I’m confused. What problem are you having, specifically? If you can’t test the precision of Python’s variables, then it follows that it’s not Python variables you’re having a problem with right now, so where exactly are you experiencing a problem with precision?


i can type commands only when i am not running Panda3D program. in Panda program, i can’t type those commands. but if Panda is not running, DX9 is not activated, right? i tried typing commands in Python, i got correct (double precision) results.

what i experienced, was that, when i moved an object with some formula, the position of an object was jumping , visually. it becomes very obvious when i put the object at coordincate of 500000.0, but if the object is at coordinate of 1000.0 or below, there is not such visual jumping.

but if Python can still run in double precision, i can store the positions of objects in my variables, such as self.objectcoord[x,y,z]. when i do calculation, i use these variable with double precision, not using self.object.getX() , which gives me the single float values with precision already lost. then there is only visual problem, for physics calculation, it’s still highly precise.

You can’t type commands in a Python program? We should fix that, that makes such a big difference. Why can’t you, what happens when you run, for instance:

python -i

and then at the Python prompt:

from direct.directbase.DirectStart import *

Do you see the gray window? If you press control-C then, it should break into a prompt, and you can type Python commands.

There are fancier ways to run interactive Python, depending on your editor of choice, but this is the most fundamental.


thanks a lot.
i ran the commands and got 900000.03 , that’s good.

Thank you DRWR, this was the best description of what is going on I’ve heard yet. Now I understand whats going on, so Panda DOES NOT actually store the vertices as double precision at all.

I was worried about having an early ATI chip (Radeon HD3200) that I’d determined wasn’t using double precision but that all my vertices were still being stored as doubles, thus wasting half the RAM. Somebody needs to update the Panda manual as it gives a false impression that the engine actually supports that level of precision.

Now I know that there is no point in either sending those values as doubles across the net (as most Panda network code does) or storing them like that in my SQL database schema.

Now if I can only figure out a way to make geomip terrains respond as collision geometry my project might indeed continue onward.