New Wrapper for the Ogre Engine

[Slick]

I noticed this typo - getomega is getting called instead of GetVeloc:

Code: Select all

inline Vector3 OgreNewtonDynamicBody::GetVeloc () const
{
   Vector3 veloc;
   dNewtonDynamicBody::GetOmega(&veloc.x);
   return veloc;
}

Also what is GetPointVeloc vs GetVeloc

[Julio Jerez]

Oh, bad bug, fixed
Thank you

PointVeloc, is a util fotion tat calculate the velocy of a point in global space reletion to a body.
say for example you have a box tha is moving and rotation and you wan to onwo teh velocity of one cornel
say P is the cornal location, point veliocity calculates

Pv = v + (p - cg) crossProduct w

pv point velocity,
v velocivut of the box,
w angula velocity of the box
cg location fo teh box center of gravoty in global space
p the location of te hconere in global space.

I added some more funtionality to the matereal system. did no have teh tiem to complete the demo, by I will probably finish it tonight.

[Slick]

How do I get velocity for a body in local space using Ogrenewton?

[Slick]

Oh, bad bug, fixed
I added some more funtionality to the matereal system. did no have teh tiem to complete the demo, by I will probably finish it tonight.

I saw the commits. Is the demo functional but just not built?

[Slick]

PointVeloc, is a util fotion tat calculate the velocy of a point in global space reletion to a body.
say for example you have a box tha is moving and rotation and you wan to onwo teh velocity of one cornel
say P is the cornal location, point veliocity calculates

Ah I see I think. The corner could well have more velocity than the center if it was spinning.

[Julio Jerez]

Ok I just check in a working material demo.
It looks like this

Code: Select all

void BuildMaterialScene (SceneManager* const sceneMgr, OgreNewtonWorld* const world, const Vector3& location, Real mass)
{
   int rampMaterialId = 0;
   int frictionMaterialIDStart = rampMaterialId + 1;
   int restitutionMaterialIDStart = frictionMaterialIDStart + 10;

   // create 10 diffErent friCtion material
   dFloat friction = 0.0f;
   for (int i = 0; i < 10; i ++) {
      dMaterialPairManager::dMaterialPair materialInterAction;
      materialInterAction.m_staticFriction0 = friction;
      materialInterAction.m_staticFriction1 = friction;
      materialInterAction.m_kineticFriction0 = friction;
      materialInterAction.m_kineticFriction1 = friction;
      world->AddMaterialPair (frictionMaterialIDStart + i, rampMaterialId, materialInterAction);
      friction += 0.065f;
   }

   // create 10 restitution materials
   dFloat restitution = 0.1f;
   for (int i = 0; i < 10; i ++) {
      dMaterialPairManager::dMaterialPair materialInterAction;
      materialInterAction.m_restitution = restitution;
      world->AddMaterialPair (restitutionMaterialIDStart + i, rampMaterialId, materialInterAction);
      restitution += 0.1f;
   }

   MakeStaticRamp(sceneMgr, world, location, rampMaterialId);
   AddFrictionSamples(sceneMgr, world, location, frictionMaterialIDStart);
   AddRestitutionSamples(sceneMgr, world, location, restitutionMaterialIDStart);
}   

basically you deside what material you are goin to use, tne you make your material graph, and the after that you simple assign the material id to the shape like this

Code: Select all

dNewtonCollisionSphere shape (world, 0.5f, m_all);
shape.SetMaterialId(materialStartID + i);
OgreNewtonDynamicBody* const body = new OgreNewtonDynamicBody (world, mass, &shape, node, matrix);

also, do no forget that the class dNewtonBody has the virtual method
virtual void OnContactProcess (dNewtonContactMaterial* const contactMaterial, dFloat timestep, int threadIndex) const {}

you can subclass from OgreNewtonDynamicBody and overload that method, and you can get callback C++ style.
you can use that to control sounds, particles or some other special functionality.
for example the fork lift demo used that to rotate the contact direction to align to the tire plane of rotation, it is very flexible I think.

[Slick]

ok cool I will try porting some of my code outside of my testing app and see how it goes.

[Slick]

As a design pattern it seems as though each class that has a body that you want to act on materials you would derive from OgreNewtonDynamicBody for example. I used to set up callbacks to all call one class that handled most objects but now it would be more encapsulated in each derived class instead.

[Julio Jerez]

was that a quetsion?


Notice that tther are tow body classes: OgreNewtonSceneBody and OgreNewtonDynamicBody

The are both decendent of dNewtonDynamicBody, so ther boath have teh sam interphase. But for teh most part almos all methods of OgreNewtonSceneBody do no do anything.
OgreNewtonSceneBody is teh calss tha you usie to add static gemetries liek terrain, building, tress, props, etc.
obecte can be move or anumated, and the remain static.
evertything else derive soudl be derived from OgreNewtonDynamicBody, and soem moethe sopurl be overloaded to customized the desired behaviors.
this is the paradign of C++, I believe.

also notice that materials are not part of OgreNewtonSceneBody or OgreNewtonDynamicBody teh are teh base class of the collision: dNewtonCollision
you cna change the matrial by simple chnage the collsion id, of the collsion shape asigen to a material.
This is different that hwo it is in Newton where material were asigen to the body.
This mehod is more flexible, for example and body with a compound or a scene collision can have many materials, is teh Newton C inetrace thsi si more complex to achive.

[Slick]

Not really a question but checking that it makes sense to create a class for each item that I want callbacks for. i have created static geometry using OgreNewtonSceneBody and now am porting my other objects to OgreNewtonDynamicBody. Lot's of errors for me to fix but looking forward to the first working version.

[Julio Jerez]

Not really a question but checking that it makes sense to create a class for each item that I want callbacks for.

yes that is correct, the method where you pass a function call back is much more poweful, but it could get more confusing.
This method is simpler and with careful design can achive same results. Mush C++ app use that methodology

Also notice that these classes are derived for the dNewtonBody class.
it is possible to sub class you own class, and implement the same interace as the C inerface with function pointers as opposed to virtual functions.
I beleive that for C++ user this sube set of objects encapsuletion is cleanner.

also do not forget to add your static geoemetry to a OgreNewtonSceneBody
this is the secrect of fast performance and memory saving in Netwon 3.xx

[Slick]

Ok I understand. I'll keep going.

[Slick]

OgreNewtonDynamicBody does not have a setuserdata function to store a pointer to the class that created it. The scenenode pointer seems to be stored in the dNewtonDynamicBody setuserdata function.

How would I get a pointer back to my class?

[Julio Jerez]

dNewtonDynamicBody is derived from is class dNewtonBody: public dNewtonAlloc, public dNewtonTransformLerp
you can call
void* GetUserData() const;
void SetUserData(void* const userData);

also you cna use OgreNewtonDynamicBody are your base class, you can subclass it and add any data you want.

[Slick]

I understand. In Ogrenewtonworld you store the scenenodes in the userdata field so I probably have to subclass instead.