[ODE] questions regarding physically based camera modeling using ODE

[Mike Reinstein]

I think I probably made a mistake in my last email regarding my questions...
I didn't differentiate between entities (movable players) and cameras. I 
made the assumption that cameras were always synonymous with entities, as is 
the case with first person perspective. But the real crux of my problem lies 
in the facts that:
a) I don't want my avatars to rotate as a result of interactions with ODE
b) I don't understand how I build a networked simulation where all 
participants (clients) store a copy of the simulation locally, running it in 
parallel to the server. I want to Implement predicative contracts, but I'f 
im not sending positions of objects explicitly, how can I do movement 
interpolation? I'm assuming I send forces enacted by each moving player 
entity, and allow each client to work out the movement, but can I do this 
with reasonable confidence that all players are seeing the same simulation 
execute? does ODE internally rely on any stochastic mechanisms that would 
cause noticeable differences in simulation copies? (ignoring small rounding 
differences).

I'm assuming this also involves clock synchronization between clients and 
servers as well?

I'd appreciate any feedback or tips. Thanks for your reply h+ :)

-Neko




>From: "Jon Watte" <hplus-ode at mindcontrol.org>
>To: "Mike Reinstein" 
<web_fella at hotmail.com>,<ode at q12.org>
>Subject: RE: [ODE] questions regarding physically based camera modeling 
using ODE
>Date: Sun, 25 Apr 2004 17:33:07 -0700
>
>
> > Question 1: How do most games nowadays do it? Is the approach to 
generally
> > model the cameras as physical objects that the physics system 
controls? Or
> > is it usually one independant of a physics system. It seems to me 
like
> > physical modeling of the camera is the way to go since the 
gravity, and
> > collision detection stuff will be handled automatically, but it 
presents
> > other challenges...
>
>I think it ranges all over. There calculates a desired position based
>on firing a bunch of rays from the desired subject (usually your avatar)
>and then picking the best, unobstructed view position; then a simple
>first-order filter pulls the camera towards the desired position. (There
>is a preference towards not moving the camera if possible)
>
>In some stuff I'm experimenting with (based on ODE), I model the camera
>as a sphere with a radius that's about 1.5x the near clipping plane
>distance. That way, it doesn't clip through geometry, which is always
>nice :-) The problem is that you get all the kinds of problems that you
>will get with an integrator system: fishtailing, bobbing, springy
>response, and all that. If you make it too stiff, you get vibration or
>possible explosion.
>
>I actually let the sphere rotate freely, and place the camera in the
>center of the sphere, but orient it according to a desired up vector and
>desired look-at target, rather than trying to use the sphere's
>orientation.
>
> > Question 3: If I go with physical modeling, how does this tie in 
with
> > multiplayer support? the problem is If I allow the physics system 
to control
> > camera movement and collision response, what data do I send to the 
networked
> > players in the game, and extrapolate expected positions using a 
curve fit?
> > This puzzles me....
>
>I use the category/collision bits to mark the camera as something that
>collides against other things, but doesn't affect other things. I e,
>when the camera collides with something, I attach the contact joint to
>the static environment and the camera; the other object is unaffected.
>
> > Question 4: Pardon my ignorance, but what is an inertial tensor? I 
have a
> > feeling this has something to do with question 2 mentioned 
above...
>
>An inertial tensor is a representation of how mass is distributed around
>the center of gravity of some object. It's what gives you the ability to
>wobble, and then to settle around one of the three main axes for a 
block,
>but a sphere will just spin smoothly wherever it's spinning.
>
>Once you know vectors and matrices (basic linear algebra), tensor 
calculus
>is a logical progression from there.
>
>Cheers,
>
>			/ h+
>

_________________________________________________________________
>From must-see cities to the best beaches, plan a getaway with the Spring 
Travel Guide! http://special.msn.com/local/springtravel.armx