amd64 double precision libraries in LINUX

[madmongo]

Hi guys. First of all, thank you for making this library available.

I am writing a 3d casino game and the addition of physics really improves the feel of things.

I am keeping all the physics life-size (which means SMALL) which I understand is a no-no in the float version of Newton, so I was wondering if you would mind making the double version of the lib available in the linux sdk? I am running this game on both 32-bit and amd64 processors.
Provided I use more than one thread in Newton, the chip collisions are good, even with chips 4cm in diameter and 4mm thick. Playing cards of course are a different matter (only 0.3mm thick!), so I don't give them any mass and animate them by hand.

I am using SDK version 2.08

Thank you in advance for taking the time to reply.

Of course Newton will get a mention when my game goes live.

Thanks once again.

Richard

[Julio Jerez]

what fps are you running your phsyics? has you tried playing at a higher fps?
for small objects running the physics at higher 240 fps will greatly improves the collision and physics quality,
and you may not even need the double presition.

[madmongo]

Thanks Julio, for the reply.

I am currently running at physics of 100fps.
I'll try 300 tonight and let you know in the morning.

Maybe in the meantime you could answer a question for me. On the 32-bit machine (1 core, 2.xxx Ghz), the small physics are almost ok at 100fps. On the 64-bit machine (4 cores), the casino chips behave less naturally. For example, sometimes orienting themselves at an angle, with one edge touching the table and then sliding sideways like this for perhaps 10cm.

I am using (cpu_count > 1 ? cpu_count - 1 : 1) threads for collisions, and yes, I am locking the critical section before updating the graphics. My physics objects really are sliding along the table.

If it was that the physics had just "stopped" then I would expect them not to translate.
And if it's because of maths instabilities causing them to not-quite touch the ground (for fiction calculations), I would expect them to at least fall so that they are flat.

Could I have missed something in the material setup that's important with the 64-bit compiler but not with the 32?

So far in all other respects I have found the library fantastic. Thank you for making it available.

Kind Regards,

Richard

[Julio Jerez]

I do not really understand the problem, but when teh collision works propertly, then the physics should be perfect at all time.
Objects should rest aproprietlly. The reason of increasing the FPS is so the Collision do not miss contacts.

for testing you can set x87 one core and 300, maybe 400 fps, then when this is working correctly as expected. then you can try multithearding.

Do the card have thickness? Convex shapes in Newton need some non zero thickness. Making and Flat shape may cause the Physics to go really bad.
can you make a video so that I can see what you try to explain?

[madmongo]

Thanks for the reply.

Ok, here's the situation:

1. The cards do have thickness, but only 0.3mm. I am making them mass-less and animating separately.
2. I am only considering the chip/table interactions at present.
3. chips collisions are a cylinder 0.02m radius and 0.004m height. Mass is 0.01Kg
4. I am dropping chips from no more than 0.01m up so impact velocity is reasonable
5. table is a cuboid 1m thick and 10m square (nice and big, again zero mass)
4. I have tried 1 thread, 3 threads, 100fps and 300fps. All results are same
5. on the 32-bit library, all impacts look reasonably natural and chips behave properly
6. on the 64-bit build chips behave less naturally and often come to rest at an angle of 45 degrees or so to the table, and then slide along it in that orientation.

I will put some code in to create a video over the weekend, but bottom line is that I am getting different behaviours under amd-32 bit and amd-64-bit environments, which I find surprising. I wondered if you had experienced the same. Environment is linux.

[Julio Jerez]

5. on the 32-bit library, all impacts look reasonably natural and chips behave properly
6. on the 64-bit build chips behave less naturally and often come to rest at an angle of 45 degrees or so to the table, and then slide along it in that orientation.

I will put some code in to create a video over the weekend, but bottom line is that I am getting different behaviours under amd-32 bit and amd-64-bit environments, which I find surprising. I wondered if you had experienced the same. Environment is linux.

I do not develop in Linux, I do in windows then compile in Linux and Macs, I almost never test Linux in 32 bit because my laptop is very bad, I do test in 64 bit and it seems right.
when you say 64 bit build are you saying 64 bit library? or a 64 bit OS running a 32 bit app. It should be identical in all cases.

also have you implemented debug display to see ho the shapes look like?

[madmongo]

64-bit library on 64-bit AMD linux system (Phenom Quad core)

I have not implemented the debug callbacks because it all worked ok on linux 32 (32-bit library on 32-bit linux).

Also, only 30-50% of chips behave badly, not all (whereas 100% of chips behave properly on 32-bit library). I can confirm that no contacts are being missed. The chips never embed themselves in the table (which I have made 1m thick in the physics).

However, I will implement the debug callbacks when I get a moment.

It's interesting that you say you do not test on a linux system. I used to work in the quant team of an investment bank. We used to compile the exotic pricing library for both windows and linux. Often, if there was an uninitialised float or double somewhere, you would not notice on the windows system, but the linux system would throw an exception or give a wrong result. Perhaps something to do with the way the different compilers (or operating systems) initialise memory?

If you don't have a partner to test the linux build, and you would like one, I would be happy to oblige - and sign any NDAs etc . if necessary.

I am very confident that the game I am working on will be a global success. I would love to solve this so that I can use your library in it. It's really pleasant to use.

Sincerely

Richard Hodges

[Carli]

I have the same problem:
I'm using Linux64 with AMD Turion and the up to 50% of the boxes from the stack demo stay at a 45% angle and/or not are slicing over the ground.

[Julio Jerez]

what demo is that, so that I can try in my system.

[Carli]

the problem was fixed.

I did scale the 1x1x1 box with a matrix but this was a fault. (maybe the normals are not normalized)