Capsule Body

[KKlouzal]

I have an object, SceneNode, which I want to represent inside newton as a capsule.

The purpose will be a client/server physics simulation, client 'players' will be represented on the server as an upright elongated capsule. What should I use as a base for my SceneNode?

ndBodyDynamic or ndBodyKinematic?

I don't want this capsule to ever fall over, and the capsule should interact with other physics bodies, however, I don't want the capsule to get pushed by other objects.

For example, the capsule should not 'walk through walls' or 'fall through the floor' but it should 'fall onto the floor'. If another rigid body is 'thrown at the capsule' then the capsule should not be bothered by the rigid body, however, the rigid body should 'bounce off the capsule'.

I do want to be able to manually update the position of my capsule at any given time.

So to start, should I use ndBodyDynamic or ndBodyKinematic as the base class for my SceneNode?

Oh, Newton 4.0.

[Julio Jerez]

Try the player capsule.
There is a demo.

It is now under modifications since I am trying to replace the old model with free motion capture data, and I am still writing the utility to convert mocap to fbx format.

But if you run the player capsule, I believe it is what you described.

[KKlouzal]

Specialized 'PlayerCapsule' class with methods for movement and heading and such is a bit much for what I need.. The 'client' has a full-blown ndBodyPlayerCapsule which is controlled through keyboard/mouse input. At the end of each physics simulation frame, position/rotation/velocities/etc.. are transmitted to the 'server'. The server side only needs a basic representation of the object, so I'm thinking a simple capsule like such should suffice:

Code: Select all

class Player : public SceneNode, public ndBodyDynamic
...
Player::Player() :
    ndBodyDynamic(),
    _Position(0.0f, 15.0f, 0.0f, 0.0f)//   Default player position. TODO: make spawn points a thing..
    {
        ndShapeInstance Shape(new ndShapeCapsule(0.5f, 0.5f, 10.0f));
        ndMatrix Matrix(dGetIdentityMatrix());
        Matrix.m_posit = _Position;
        Matrix.m_posit.m_w = 1.0f;

        SetNotifyCallback(new PlayerNotify(this));
        SetMatrix(Matrix);
        SetCollisionShape(Shape);
        mass = 10.0f;
        WorldEngine::_ndWorld->Sync();
        WorldEngine::_ndWorld->AddBody(this);

Then I hook into the NotifyCallback to translate position/rotation/velocities/etc.. out to other 'clients', at a slower interval. (clients run their own physics simulations and get an update from the server at a slower rate, this way everyone stays in sync cause their simulations will slowly drift).

My next question though, what is the best way to update the position/rotation/velocity/etc.. for this ndBodyDynamic? I would make all my updates prior to stepping the physics simulation. But can I simply change the matrix and set the velocities? Do I need to sync() the world prior? sync after?

[Julio Jerez]

In that case, you can subclass from ndBodyKinematic.
Not from nobody Dynamic

The you hive it a mass value.

A body like that will I treat with the rest of the scene, but the scene can't move him.
You has to move him manually.

[JoeJ]

_Position(0.0f, 15.0f, 0.0f, 0.0f)

You forgot to make the 4th value a 1, to indicate it's a point not a vector.

Beside moving the kinetic body, i guess you (still) need to set it's velocity as well, so dynamic bodies which collide with it react as expected.

One potential problem i see with kinetic bodies is that multiple players would not resolve collisions to each other. So the server depends on the clients to care about that, eventually.

[Julio Jerez]

ah yes Joe, I also has that bug, Fixed that vector posit bug, thanks.

and yes, kinematic do not deal with collision amount each other.
that can be deal with in their update, for that player and trigger are on a special update list that get a
SpecialUpdate(ndFloat32 timestep) call.

I just made the ndBodyKinematicSpecial and base class, so that it can be expose to the application as a base object for this kind of thing.

for what I understand, KKlouzal is trying to make a client player that is getting is position from some server, so he only needs to teleport the body to the next location in the client side.
In general, since all other players already has location resolved by the server, it does not matter if they interpenetrate a little from player to player in the client, because they are server objects.
the problem is that as the player moves on the client, it can interact with other client objects, but only to push them out of the way.

your client player now can be like this

Code: Select all

class MyClientPlayer : public SceneNode, public ndBodyKinematicSpecial
{
      .....

     void SpecialUpdate(ndFloat32 timestep)
     {
          // do your logic here, ex you can calculate the velocity from the delta position

          // to move a player call, set velocity by calling
          SetVelocity(veloc);
          // them call
          IntegrateVelocity(timestep);
     }
}

that's what triggers and player capsules are. you can just make your own version that do what you want.

Initialization is the same as for any other body.
you give some mass an inertia so that the rest of the world can interact with it,
but the world will not move them.

Remember to give is some mass so that is does not act as a static body with infinite mass.

sync to latest so that you get that base class, I just made it a shared common for that kind of objects so that they can be treated with common interface by the collisions and solvers.

[KKlouzal]

Thank you, I appreciate it. I believe you are mostly correct in what I'm trying to do. I will explain it one more time in different words though just to make sure we're on the same page here.

Server application, runs entire physics simulation.
Client application, runs entire physics simulation.
Each client is responsible for the dynamic bodies that they own. So, client creates rigid body, he is responsible for his rigid body, client has single PlayerControllerCapsule, he is responsible for this too (updated from mouse/keyboard input).

Server application keeps a 'duplicate copy' of all physics bodies which are on all clients.
So, client A creates rigid body, sends message to server, server creates same rigid body.
Client B joins server, Client B get's his own PlayerControllerCapsule, server creates 'simple capsule' to represent Client B.

After each physics step/tick on each client, client will send position/rotation/velocity information from all rigid bodies in his simulation that have changed, and sends them to the server. Server updates his simulation based on these changes.
If Client A PlayerCapsuleController moves, after physics simulation step/tick, Client A sends his PlayerCapsuleController position/rotation/velocity information to server, and server updates his copy of Client A 'simple capsule' to reflect changes.

Once in a while (maybe every 1 second), server takes ALL his simulation data (each dynamic/kinematic body) and sends position/rotation/velocity information out to EVERY connected client (this way we keep all client simulations in 'sync').

This is a simplified approach, but from a high-level overview, this is essentially what happens.
In the future, the server will use more than just simple Capsule to represent client object, but for this stage of development, capsule is plenty.

When I get home today, I will see what I can do with the kinematic special body.
I am still not 100% sure what the best way to manually update position/rotation/velocity information of a ndBody within the simulation, or when is best to perform the update.
Thank you again.

[Julio Jerez]

I see it the other way around, each client is his own player capsule.
You say that the server also has a player capsule, so I assume, that eCh client will see its own players, and play proxy representing other clients, and the server has all as player capsules.

Regardless of the network architecture, the principle is still the same, whoever is going to have a proxy player, You made it from a kinematic special.

To move a body, you can call setmatrix,
But that's only recommended for creating or teleworking and object. That funtion creates lot of changes to the state of tge world.

The recommended way is to, first yo set the velocity.
Them you call integrate body.

That way the body moves incrementally.

If you look a the player capsule special update function, you will see that that e ally what it does.

So in you case, you just make you body from a kinematic special, and you implement that funtion SpevialUpdate.

There you just move the body using the method explained.

There you can add all the logic you want to keep the sync logic, game play logic, or whatever else you need it to do.

[Julio Jerez]

If you are talking of the entire scence update, that happens periodically for synchronization.

In a loop you can iterate over every body in a scene, calling set matrix, set velocity and set omega.
You can do that in a world post updat, or by simply over loading the physic update in you own subclass, and keeping the logic to do that.

[KKlouzal]

If I wanted to overload 'physics update' for regular ndBody objects running on the client/server, what would that look like? This way, in my object, I can store a 'most recent networked value', and then when newton does a simulation step, I assume it will call 'physics update', and I can integrate the 'most recent networked value', sort of like this:

Code: Select all

class SceneNode, public : ndBody
{
   ndVector MostRecentNet_Position;
   ndVector MostRecentNet_Velocity;
   ...
   ...
   bool MostRecent_Used;

   virtual void OnPhysicsUpdate()
   {
      if (!MostRecent_Used)
      {
         this->NetSetPosition(MostRecentNet_Position);
         this->NetSetVelocity(MostRecentNet_Velocity);
         ...
         ...
         this->MostRecent_Used = true;
      }
   }

   void NetSetPosition(ndVector Pos) { ... }
   void NetSetVelocity(ndVector Vel) { ... }
   ...
   ...

   void ReceiveNetUpdate()
   {
      MostRecentNet_Position = Net.ReadVector();
      MostRecentNet_Velocity = Net.ReadVector();
      ...
      ...
      this->MostRecent_Used = false;
   }
};

Just to give a logical overview of how I figure this should work.

[Julio Jerez]

this class SceneNode: public ndBody
will be too difficult in c++.

the ndBody is just a common interface for the engine, if a high level app derive from that class, the core engine object will not be aware of what kind of object it is. for example, the ndScene implements everything related to collision, contacts, shapes, that kind of things. for thatm is uses ndKinematc as base class. a new body derived from ndBody is not going to be ndKinematic so it will no be on any sub system.

similarly, the solvers deal with ndBodyKineamtix and ndBodyDynamics, so they will understand bodies derive from ndBodyDynamics and treat them as dynamics bodies that interact with other bodies. I will handle bodies derived from ndBodyKinematics, but will treat them as static bodies. they will not be integrated.

what you want to do in this.
for getting and update for the network. you can subclass the world and overload OnPostUpdate

Code: Select all

class ndServeWorld: public ndWorld
{
   public:
   ndServeWorld(ndDemoEntityManager* const manager);
   virtual ~ndServeWorld();

        // do all the server stuff logic
   void OnPostUpdate(ndFloat32 timestep);
};


them, in OnPostUpdate you can do scene management stuff like when a new body is added to a client or remove. there you can add or remove new bodies that come and go form the server,

To interface with bodies no matter what type they are, you can make a custom
base class ndBodyNotify, and assign that to the bodies in you creation functions.
this way all bodies in the scene, will have a notification with a common base class that was made by your application. Plus, the bodies get appropriate call backs that you can overload to do the network synchronization on per body bases and you do not have to worry about type casting. as you would if you did this in the world update loop.

in the sandbox demos, that class is class ndDemoEntityNotify: public ndBodyNotify

there you can implement the force and torque function, but also, you can add the serve corrections.
if you look at the demos, some objects require special attention.

for example thet ragdoll demo, that I am working now, used this.
class ndActiveRagdollEntityNotify : public ndDemoEntityNotify

and there it checks if some collision cause so modifies to acquire a huge velocity, and if so, is clamp it.

there are other demos, that use different subclasses of ndDemoEntityNotify because they do different thing. But doing that you can do there equivalent of what you mention in the post.

there are some other examples, The player capsule would play the animation of the visual body.
class ndBasicPlayerCapsuleNotify : public ndDemoEntityNotify
the fracture, I think it use a special one as well, and so on.

[KKlouzal]

My apologies, the code block from my last post was a generalized idea. I do inherit from ndBodyDynamic and not just plain ndBody. I also use the ndBodyNotify class to receive updates from the physics engine OnTransform and OnApplyExternalForce.

FYI, The demos aren't easy to follow. You have to dig deep into the demo framework and figure out what everything is doing before you can start to understand how each demo works. They need to be simple demos for newcomers to follow, single .h/.cpp source files that demo a specific feature. (I can use the demos now that I've had to dig into the framework a few times, but for newbies, and even me still sometimes, finding demo code for a specific feature is always a struggle).

Nonetheless, I haven't had much time yesterday to implement the new features discussed in this post, hopefully tonight and over the weekend I will have more time to make these implementations. I am very close to having client/server networked physics simulations and hope by the end of this weekend to have a prototype functioning. I was able to do it in Bullet, this will be my first attempt with Newton (switched to Newton because the performance is MUCH better than Bullet.)

[Julio Jerez]

well I try to make the as simple as I can, but that's no always possible.

on the ndNotify, try using it more, because it is you interface to polymorphism.

sub classing from bodies and adding functionality to the subclass,
seems like a cool idea at first, but lead to an spaghettis of of casting
where using the ndNotify, let you have you own common base and store the data and logic
you need to control different bodies types.

here is a typical problem, that if you were sub classing from bodies is very hard to manage.

imagine you have a body that is an airplane, by can be an vehicle on land, or even change from a vehicle to a base. these thing are not uncommon in games.

using body classes seems a solution, but in practice is hard to manage because end up in creation and destruction, and complex game logic.
while use the notification, you can have an array of them and you swap to the one you want.
them the notification can manipulate the body.