If you''re going to be rendering at a reasonable framerate the timestep on the physics will be considerably larger than a rendering timestep. [maybe linearly interpolating, the values for rendering?]
Similarly the models you use for rendering and collision detection are likely to be quite different; most 3d rigid body demos use highly simplified geometry for collisions.

people.. this is like.. engine design 101.. have a Scene class that encapsulates a set of Object classes. Objects check for collisions with other Objects and either draw themselves or pass the transformed data to the parent Scene, depending on the application. the Scene instance, when rendered, determines which objects can potentially collide (Object::CheckBoundingBoxForCollision(BoundingBox *)) and then calls each Object''s collision detection method for the potential colliding Object. Object::CheckForCollision(Object *).

-goltrpoat

The above anonymous guy is right, its the way that I ended up working things in my engine as well.

On an abstract level, your scene owns all actors. Every actor has a public member function CheckCollide(Actor *other), that checks its bounding box against another actor''s bounding box.

Your scene has a function, say, CheckWorldCollide() that loops through all your actors, calling CheckCollide() for TotalNumObjects/2 (/2 because if you check collision for one pair, you eliminate the inverse check, obj1->obj2 is same as obj2->obj1).

Forgive me if this is a stupid question, but it seems from your question as if in Java an object can''t access another object''s private data even if its the same type. This isn''t the case in C++, which is why your object''s CheckCollide(Actor *other) can "get at" all the needed physics info for Actor other.

-- Remnant (at the Uni)