10 replies to this topic

[greenzone]

Ok so i am using the PhysX 2.8 engine with my program but i have my entire program using doubles. so i am having to cast the values that physX is handing me because it only works with floats. I read there is a way to set up physx to use doubles but i was unable the little info i could find on the subject. Well the problem i am having is that i am sure info is being lost in the process of casting and i was wondering if there is some kind of awesome CS casting trick that i am over looking from CS101 that can fix or help in the matter. I am getting smooth rotations and translation until these little moments when it gets a little jumpy or jittery other then that it actually works fin but i would like to smooth out these little bugs if i can. thanks

also if any one knows of the procedure or a white sheets on setting up physX to work with doubles that too would be totally awesome as well

[frob]

Out of curiosity, why are you using doubles?

Most libraries out there use floats. Mixing floats and doubles is a well-documented performance issue on DirectX and other libraries. Switching from double-precision to single-precision is an expensive thing.

Is there really something that you really need the extra few bits of precision for?

[greenzone]

well thats a good question. well i would have to say that I have been building off of a program i developed for a class and i started out using doubles and now its turned into a beast before i started trying to used physx. i am using openGL by the way. any how at this point I i guess just been lazy about converting everything to floats although in retrospect it might not be as much as a hassle as it might trying to retrofit physX. I know there is a way to get physX to work with doubles i just have not found documentation that i understand on how to do it.

[SIC Games]

frob is right! Doubles have longer range than floats which takes up more memory. However, conversion from float to double isn't that hard to say at least just impacts the performance. If you wanted to convert a float to a double just put the:

float PI = 3.14;
float ConvertFloat = (double)PI;

-- or --

double AnotherPie = PI;

However, floats are used in most 3D Applications instead of doubles. But if you insist - go ahead and try and see what your results are. If you feel the performance is getting a punch then this would be the reason behind using floats instead of doubles. I forgot how many bytes doubles use but they're way different than floats.

[JTippetts]

It's been awhile, but I think there are possible ramifications with having DirectX use float rather than double. I seem to remember having an issue once when I was playing with Ogre3D, where I was suddenly, seemingly out of the blue, getting weird and intractable errors with my embedded Lua. Spent days trying to figure it out; it only happened when I would switch to a Direct3D renderer from OpenGL. I believe it was DirectX changing the FPU mode to float, whereas Lua wanted doubles. Things could be different now, though.

[Hodgman]

@OP, simply casting your doubles to floats in the standard manner shown by SIC Games should be all you need. There's no trick to it. This will generate CPU assembly to read your 64-bit double from RAM into an FPU register (expanding the value to register precision, e.g. 80-bit), then write the contents of that register to a 32-bit float RAM address (rounding the value to 32-bit precision)

I believe it was DirectX changing the FPU mode to float, whereas Lua wanted doubles. Things could be different now, though.

Yeah, when creating a D3D9 device, it sets some flags in the CPU to tell it to round all it's results to 32-bit precision. You've got to set the D3DCREATE_FPU_PRESERVE flag when creating your D3D9 device to avoid this.

[Dan Mayor]

Just wanted to chime in, probably a bit late but anyway. Floating point variables have a range of something like 12345¹⁰. Although this is difficult to place actual range of numbers to it is important to remember that floating point variables are normally used for positions, velocities and other 3D calculations. It is very rare that you will ever encounter a level map, model, mesh or really any 3D asset that even comes close to peaking out the maximum allowable values of a float.

With all of that said I understand that many coders think bigger is better and that using a double in place of a float will give you the ability to have larger maps, worlds, more precision in game and all that jazz. However that is simply untrue, video cards themselves fall flat on their face when you get anywhere near those sizes. So I guess in short, I would suggest coders just be in the habit of using floats unless there is some extenuating circumstance wherein you actually do need the extra range.

[greenzone]

Why use doubles at all? I mean what requires such precision if most of the time it is unnecessary. The only reason I am using doubles in this program is because the graphic programing class i took had us set up this entire engine using doubles. I figured there was a reason for this but i don't believe it was ever explained. I mean all literature on the subject out side of this class talks about and uses floats. what are some examples of when doubles are beneficiary in graphic programing?

[iMalc]

Just wanted to chime in, probably a bit late but anyway. Floating point variables have a range of something like 12345¹⁰. Although this is difficult to place actual range of numbers to it is important to remember that floating point variables are normally used for positions, velocities and other 3D calculations. It is very rare that you will ever encounter a level map, model, mesh or really any 3D asset that even comes close to peaking out the maximum allowable values of a float.

With all of that said I understand that many coders think bigger is better and that using a double in place of a float will give you the ability to have larger maps, worlds, more precision in game and all that jazz. However that is simply untrue, video cards themselves fall flat on their face when you get anywhere near those sizes. So I guess in short, I would suggest coders just be in the habit of using floats unless there is some extenuating circumstance wherein you actually do need the extra range.

Range is not everything; You have completely side-stepped the issue of precision. So either you aren't aware of how floating point works, or you're conveinently only telling half of the story to make it seem more convincing.

Floats are essentially scientific notation.
The larger your float value is, the less precise it is. With IEEE754 floats, all decimal precision is completely gone at by the time you reach 8388608.
From there is only gets worse. if you add 16777216.f and 1.f for example, you get 16777216 again! For proof, test the following assert:

assert(16777216.f + 1.f != 16777216.f);

Mathematically you would certainly excpect the result of adding one 1 to have an effect, but it doesn't because 16777217.f can't be represented.

For many things, you need much more precision than that well before you get that high. Floats just don't provide that.

Don't get me wrong though, floats are still very very useful in a lot of cases. I even have a C++ class that provides fully IEEE754 compliant 16-bit "half" floats, at close to the speed of regular floats, for when saving memory is of the utmost importance.

But... it's just not as cut and dry as you make it out to be.

Edited by iMalc, 11 October 2012 - 01:01 AM.

[JTippetts]

Just wanted to chime in, probably a bit late but anyway. Floating point variables have a range of something like 12345¹⁰. Although this is difficult to place actual range of numbers to it is important to remember that floating point variables are normally used for positions, velocities and other 3D calculations. It is very rare that you will ever encounter a level map, model, mesh or really any 3D asset that even comes close to peaking out the maximum allowable values of a float.

With all of that said I understand that many coders think bigger is better and that using a double in place of a float will give you the ability to have larger maps, worlds, more precision in game and all that jazz. However that is simply untrue, video cards themselves fall flat on their face when you get anywhere near those sizes. So I guess in short, I would suggest coders just be in the habit of using floats unless there is some extenuating circumstance wherein you actually do need the extra range.

I believe that the developers on the original Dungeon Siege encountered precision problems while building their continuous world, hence their switch to a hybrid system using chained local coordinate spaces. It really isn't as hard as you might think to start encountering precision problems using single-precision floats. Awhile back, I built a quick and dirty little streaming system for my isometric game, and it really only took me about 20 min to hit the "end of the world", where precision problems started cropping up. You can have large floats and you can have precise floats, but large precise floats are a different story.

[SIC Games]

@OP, simply casting your doubles to floats in the standard manner shown by SIC Games should be all you need. There's no trick to it. This will generate CPU assembly to read your 64-bit double from RAM into an FPU register (expanding the value to register precision, e.g. 80-bit), then write the contents of that register to a 32-bit float RAM address (rounding the value to 32-bit precision)

I believe it was DirectX changing the FPU mode to float, whereas Lua wanted doubles. Things could be different now, though.

Yeah, when creating a D3D9 device, it sets some flags in the CPU to tell it to round all it's results to 32-bit precision. You've got to set the D3DCREATE_FPU_PRESERVE flag when creating your D3D9 device to avoid this.

Thanks bro for agreeing. I also like to add that when I tried to convert my mesh file from float to double - it didn't draw correctly until I switched it back to float. Though a XMVECTOR willt ake a double just it's less nessary. Hope this forum has helped out. It doesn't hurt to try and see for yourself though.