Okay, one more problem arrised.

I got this function,


Which perfectly positions the model in the air. it slowly falls down the way it should. The only problem here is that it falls through the floor. So I did bounding box + 220 and messed around with the values and I noticed them finally getting stuck in the floor. There for, I think the bounding box calculation is incorrect. Am I doing something wrong here ? Is their box supposed to be the same size in width height and depth ?

This doesn't look right to me

	box.Set(bbox.GetMax().GetX() + bbox.GetMin().GetX(),		bbox.GetMax().GetY() + bbox.GetMin().GetY(),		bbox.GetMax().GetZ() + bbox.GetMin().GetZ());

as those additions should be subtractions to get the dimensions of the box.

Apart from that though it looks fine. Only thing I can suggest is to make sure you are running the simulation at a fixed timestep (like 50 or 60hz) and that you are consistent with your units.

If your floor is a heightmap, I'd make doubly sure your triangles are correctly oriented and that you haven't made them backfacing in Tokamak even if you are rendering them correctly in your own app.

Best of luck,
ViLiO

Well, I changed the gravity to -10.0f, I modified the objects masses to 10.0f and placed them directly above the terrain. For some reason they really want to bounce right into the air. Also the bounding boxes still are incorrect for some awkward reason.

My first port of call would be fixing your bounding boxes so that you can reflect accurately what is happening in the physics simulation (no point drawing a 1x1x1 box when Tokamak is working with one that is 2x2x2) [smile]

As for bounciness, that is controlled with the restitution. You can change this by adding materials to the simulator and updating your body's geometry with the new material index. The larger the restitution, the more bouncey. The default restitution is only 0.4f though, so the problem probably lies elsewhere.

One thing you could do (I have found this to be a great help to myself), is actually add the Tokamak source code as a project in your solution. This will allow you to literally step through the library itself when debugging. I'd advise against actually changing things inside Tokamak though (unless you are feeling adventurous) [wink]

All the best,
ViLiO

Quote:engine->GetPhysicsHandler()->GetSimulator()->SetTerrainMesh(&terrainbody);

Wow. I think you should really read this (and everything you find about the Law of Demeter (shameless plug)).

From a code point of view, if any of this calls fails, you crash.

From a design point of view, what is the meaning of this statement? It means that the engine has a physic handler which has a simulator which can handle a terrain mesh, but that for some reason you chose to discard this logical link between all these classes in order to access the terrain mesh directly. As a consequence, you severely break encapsulation (what if you decide to move the simulator outside the physic handler class? You'll heave to search for all instances of engine->GetPhysicsHandler()->GetSimulator() and replace them with something else). A far better solution would be to encapsulate that: a engine::set_terrain_mesh(terrain_mesh&) function that will call physic_handler::set_terrain_mesh(terrain_mesh&), that will in turn call simulator::set_terrain_mesh(terrain_mesh&). You provide the necessary tests at each steps, and voilà: you code is now:

engine->set_terrain_mesh(&terrainbody);

Easier to read, and safer (but I won't discuss the design value; if your engine class is the sole entry point for everything, you're creating a God Class, and that's quite bad from a design point of view too).

edit: it seems you already do a part of the job by yourself. Remove that GetSimulator() function and call your PhysicHandler::SetTerrainMesh() [smile]