Wow, quite a lot of questions. I try to answer as good as I can.
@Liquid7800
1. TriMesh/TriMesh collision becomes slow if the meshes get bigger. I think the first ODE “Egg & Bowl” demo demonstrates this. And they demonstrate how to cope with this, by replacing one TriMesh by several primitives (three spheres in this case, if I am right).
Next, according to the ODE userguide, size of timesteps has to be small for tri-mesh collision, and you have to track the position of tri-meshes outside of ODE for dCollideTTL to work efficient. The tutorial suggest something like this:
const double *DoubleArrayPtr =
Bodies[BodyIndex].TransformationMatrix->GetArray();
dGeomTriMeshDataSet( TriMeshData,
TRIMESH_LAST_TRANSFORMATION,
(void *) DoubleArrayPtr );
I haven’t seen similar code in the PyODE wrappers though. I’m not an expert on collision detection, but might be the problem of OPCODE is that it doesn’t distinguish between concave and convex collision shapes.
2. No, I meant something else. Newton, like ODE and Bullet, contains two mayor subsystems: collision detection, and dynamics (physics). In case if ODE the collision detection subsystem even has a name (OPCODE) and is interchangeable.
I meant to use the Newton collision system without using Newton rigid body physics. More explicit: create collision shapes, but no bodies, and then register collision callbacks, and implement collision response (if any) yourself. This could be handy if you don’t need a full-blown physics system for your game, or if you want to implement triggers (the player leaves an area, get’s close to an NPC, drives/flies over a waypoint)
Lauren has pointed me at Bullet, which is another physics engine, open source, with emphasis on collision detection. Bullet seems to have the same convex/concave collision shapes as Newton (convex hull, bounding volume hirarchy optimized triangle mesh), plus some nice additions (e.g. moving concave shapes via GIMPACT). And I heard rumors that ODE is going to exchange OPCODE for Bullet. So perhaps my plan will change, and after completing Newton documentation I will spend some more time on Bullet.
@ynjh_jo
1. I didn’t implement any camera control code because I wanted the tutorials to be as simple as possible, concerning code, not usability. In other words: focus on how to use Newton. Panda3D coders will know how to implement their own controls.
But you are right. If I want to convince people how ‘great’ Newton is then I would have to make attractive (visual, performance, mouse control) demos which not only show how to use Newton, but demonstrate it’s capabilities too. I will put it on a todo-List. Thank you for the suggestion.
2. Yes, I am aware the the demo vehicle is very odd. The car is intended to be ‘glued’ to the ground, and never roll over or slip away.
I never did a car game, so I lack experience here. But I have been playing some games (e.g. GTA SanAndreas, 4x4EVO, Need for Speed, Test Drive Off Road), and I noticed that what sells as ‘realistic’ vehicle dynamics is far from being realistic. Acceleration, suspension and ground traction are ridiculous in most cases. But this way games are more fun. And this is what games are for: having a good time. Well, back to your questions.
Right. The car’s center of mass has been set below the axle plane to avoid roll. The computed center has been discarded. Realistic would be to have it somewhere in the lower third of the car, near engine and drivetrain. So your value of +0.1 is perfectly realistic for this car egg file.
To avoid tire slip, even for acceleration beyond realistic values.
By the way, did you notice the increased gravity? Another trick I found on the Newton forums to keep the wheels on the ground.
Right. This simple demo allows only three values for wheel heading: -maximum, 0 +maximum. In real life, turning the steering wheel more than a little bit while going at full speed will result in a crash. But again, just a simple demo and not a full blown car game.
Tire.setGrip( ) is PandaNewton addition to Newton. That means, Newton doesn’t know such a method. It is valid only if you use the default tire callback. C++ Implementation of this callback follows a suggestion of wallaber (http://walaber.com/), given on the Newton forums. Walaber suggest a grip of 1 to 3 (hmm, wonder why I set it to 30).
This is what walaber suggest…
Ogre::Real speed = tire->getOmega() * tire->getRadius();
Ogre::Real load = tire->getNormalLoad();
tire->setMaxSideSlipSpeed( speed * tire->getGrip() );
tire->setSideSlipCoefficient( speed * load * (tire->getGrip()) );
speed = tire->getLongitudinalSpeed();
tire->setMaxLongitudinalSlipSpeed( speed * tire->getGrip() );
tire->setLongitudinalSlipCoefficient( speed * load * (tire->getGrip()) );
…and this is part of my tire callback implementation
_tire = (PyTireObject*) NewtonVehicleGetTireUserData( vehicle, tireId );
load = NewtonVehicleGetTireNormalLoad( vehicle, tireId );
grip = _tire->m_grip;
omega = NewtonVehicleGetTireOmega( vehicle, tireId );
...
// side slip
if ( ! NewtonVehicleTireLostSideGrip( vehicle, tireId ) )
{
speed = omega * _tire->m_radius;
NewtonVehicleSetTireMaxSideSleepSpeed( vehicle, tireId, speed * grip );
NewtonVehicleSetTireSideSleepCoeficient( vehicle, tireId, speed * grip * load );
}
// longitudal slip
if ( ! NewtonVehicleTireLostTraction( vehicle, tireId ) )
{
speed = NewtonVehicleGetTireLongitudinalSpeed( vehicle, tireId );
NewtonVehicleSetTireMaxLongitudinalSlideSpeed( vehicle, tireId, speed * grip );
NewtonVehicleSetTireLongitudinalSlideCoeficient( vehicle, tireId, speed * grip * load );
}
So grip is a constant factor that increases longitudal and sideway traction, but valid only in the default (C++) callback implementation.
Implementation of this callback isn’t finished yet. Brakes are still missing and wheel relaxation has to be handled dependent on the current timestep. And it is not the only way to to it. The Newton forums offer more than one suggestion.
3. If it is high-speed collision detection you mean then the answer is yes and no. Yes, Newton has such a feature, and no, I did not test if it is working right. By the way: about 50% of the API is untested 
To enable high-speed collision detection (according to the SDK help files) you have to set continuous collision mode on the material pair and at least on of the two colliding bodies.
For the next release I want to complete object and method doc-strings. That means, just copy content from the SDK’s help files, and edit if something is different in Python. Perhaps some details become more clear then.
enn0x
