Newton Game Dynamics

(1)
Most 3D applications use the coordinate system that has been chosen by OpenGL. This is x:left, y:up, z:back. Most Newton examples are OpenGL-based, and so the examples use this coordinate system too. Gravity would be (0,-G,0) in this coordinate system.

Panda3D developers have has chosen x:left, y:forward, z:up as it’s default coordinate system.

By the way: this is where the terms “z-buffer” and “z-buffer-fighting” come from. In OpenGL the z coordinate is how “deep inside” a window (forward) the objects are.

(2)
If it comes to fundamental physics then the choice of coordinate system is not important. Physical laws are the same in every coordinate system, and so every coordinate system will work. Left-handed or right-handed doesn’t matter too.

Problems arise only when software makes assumptions on what coordinate system will be used.

Panda3D assumptions: The default camera controls come to my mind (drive and trackball), both are assuming y is up. But of course you could write your own camera controls…

Newton assumptions: A.F.A.I.K Newton does have only two assumptions on coordinate systems: First, vehicle tired can choose their pin free, but vehicle bodies have to ab aligned in such a way that the “nose” of the care is the positive x-axis. You might want to read this thread on the Newton forum: “Vehicle Joint Bug w/world Z Up and Tire pin along X axis?”. Second, ragdoll bones. There is a mismatch between Panda3D and Newton about which coordinate axis is from bone end to bone tip. So far I have no workaround.

This means you can choose whatever coordinate system you like for Newton. Car meshes have to be rotated so their nose points towards +x. Ragdolls are a problem still to be solved. The Panda3D default coordinate system is a good choice.

(3)
Newton transform matrices do not support scale and shear! So if you use scaled models and apply the matrix computed by Newton, then scale will be reset to (1,1,1).

(4)
For PandaNewton I have been using the same coordinate system in Panda3D and Newton. So conversion of vectors and matrices is 1:1.

If you set gravity to (0,-G,0) and your box moves to the backwards (out of the screen) then everything is fine. Since Panda3D prefers z-up I suggest setting gravity to (0,0,-G), like you did already.

Next I suggest you check if rotations are working right. For example by creating a box and changing heading/pitch/roll, then apply np.getMat( ) to the Newton body, and back again.

I hope this has been helpful :slight_smile:
enn0x

Wow that’s really helpfull…

I’ve tested my matrix conversion code between Newton and Panda and it works perfect.
Basicaly i create a source Box that i alter in real time (Task with random tranformation)
and i created a test Box that receive source Box panda Matrix, send it to Newton , get it back from Newton and apply to itself.
Both Box are always in sync :slight_smile:

So i went back to my issue. Basically i was wondering because of the CollisionTree tutorial. I tested this with a terrain.bam file.=> Boxes always goes trough the terrain!!
I tested it with any other egg file (ring from Robot Samples, CastleSiege from
DeledEditor Samples, custom Plane from Wing3D, bridge made in Blender)
=> they all works!! (ie Box collide with the terrain and reacts accordingly).

So i guess there is something in the terrain.bam file that trick me :frowning:
But i cannot reverse engeneer it i guess…

Regarding the scale issue, i planned to back the scaling information before
converting and restoring it afterward.
(from what i remember from maths, scaling is either the 4th row or 4th column and is not applied anywhere in rotation/translation formula…).

I’ll keep informed…

You could convert it back to ASCII using:

bam2egg terrain.bam terrain.egg

If it is the terrain.bam from the PandaNewton tutorials then I could send you the blender file too. I didn’t include them in the download because of size. If I remember right I have compiled the bam files for Panda 1.3.2.

enn0x

Yes i would be interested in to get the original file.
I hope to find the reason …

My possible guess was :
holes? (not likely at all)
too thin ?
other…

Here it is:
http://www.dachau.net/users/pfrogner/terrain.zip

enn0x

I want to try this but the links are dead. Please re-upload!