Changing joint parent body

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

Changing joint parent body

Postby kallaspriit » Sat Jun 12, 2010 1:20 pm

Is it possible to change the parent body of a joint in the submit-constraint callback?

I am making a ray-cast car and the ray-casting is implemented in submit-constraint callback where I add the necessary forces. The problem comes with braking - when brake is applied, I create a linear-row along the longitudinal tangent and set friction values to brake force. This works just fine but the brake forces are only applies to the frame but not the body the car is braking on (for example, a moving ramp), because when initially creating the joint, I set parent body to NULL.

Code: Select all
if (brakeForce > 0.1f)
{
    addLinearRow(contactPosition, contactPosition, longitudinalTangentOrientation * Ogre::Vector3::UNIT_X);
    setRowMinimumFriction(-brakeForce);
    setRowMaximumFriction(brakeForce);
}


Is it possible to change joint parent body to the body I am braking on (I find the body with raycast), so when I brake on a dynamic object, it would be dragged along with the car instead of the car stopping like the object under it is static.

Or perhaps there is another approach entirely, I am trying to figure ray-cast car out myself and not really using any existing solution so perhaps I'm doing it wrong altogether, although it does work except for the problem described.

Any ideas? :P
kallaspriit
 
Posts: 216
Joined: Sun Aug 14, 2005 6:31 pm

Re: Changing joint parent body

Postby Julio Jerez » Sat Jun 12, 2010 2:15 pm

No you can not chneg bodies a joint is attached to.

but I do no undertand which you need to do that, in teh callback you do not have to issue rows if you do not have too.

if the Ray cast car is a Joint, you just need to make sure you reserve enought rows at creation time to add what you wnat in the callback, but you do not need to add the all all the time.

kallaspriit wrote:Or perhaps there is another approach entirely, I am trying to figure ray-cast car out myself and not really using any existing solution so perhaps I'm doing it wrong altogether, although it does work except for the problem described.
Any ideas? :P


I realised that the RayCast car in the engine has lot of problems, As I am speaking now I am working on remaking it.
I asked for some pointers to rVangaard the creator of Raiser, how to go about.
He is using Newton now for collison and body physics, I have the chance to test Raiser a litle.
I am looking for some feel similar to what Raiser has, but not so Silmulation driven. I want to cover but aspets but let the end user decide what to do.
one of the big difference is that they do not use joints at all for there cars, as a result fritsion is less strong than it should be but averything else is very nice.

I also have a test demo maded by an Ogre user called BlueBlue. It is very nice but it does not uses OgreNewt. I am usin that demo as test bet to get the car going.
Anyway let us see how much I cover this weekend,

the problem is that I am torned in two projects the Raycast Car and the Editor.
How far are you in you implemention? maybe we can joint forces and make one?
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Changing joint parent body

Postby kallaspriit » Sat Jun 12, 2010 3:42 pm

I have the foundation ready for extensible raycast car and it's drivable. As I said, I have not learned how others have done it so I may be doing something weird.

Anyway I uploaded my current progress with source code, download it from here.

Arrows to drive, hold down left shift to get more power and CTRL to pick with mouse.

The classes of interest are in headers:
Code: Select all
BasicTireModel.h
RayCastTireJoint.h
TireJoint.h
Vehicle.h
BasicTireVisualizer.h
TireModel.h
BasicDamperModel.h
DamperModel.h
SpringModel.h
TireVisualizer.h
BasicSpringModel.h
DebugTireVisualizer.h
Tire.h


It's based on my minimal ogrenewt project, so it should be easy for you to compile, just make sure you have the latest OgreNewt and the environment variables set.

I also included dll's and release build so you can try it out. There is no tire model yet, but it's built in a way that it will be easy to add, I will try the pacejka approach soon. The model already provides load, camber, slip angle and lateral, longitudinal velocities, so it will be easy to build on.

Give it a try and let me know what you think and how to improve it. I have many ideas myself and I know I have not implemented much stuff like correct handling of airborne wheels (got to use inertia), blocking wheels etc.. it WIP :)
kallaspriit
 
Posts: 216
Joined: Sun Aug 14, 2005 6:31 pm

Re: Changing joint parent body

Postby Julio Jerez » Sat Jun 12, 2010 7:47 pm

Darm it feels great. Is this a single joint car? tell me more about it.

what ever you are doing it cannot be too bad, it feel very realistic, more than I was expecting.
I do not know why I am the only one who have dificcult time making a fun raycast car.
I am going to take a look at your inplementation and see if I can inetgrated all into the Ray cats car joint Car joint
This could be a very solid foundation to build the car joint.

Even you mesh look very nice.
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Changing joint parent body

Postby Julio Jerez » Sat Jun 12, 2010 7:59 pm

on another unrelated thing, I do not know why directx 9 is 3 time faster than open GL
in my system I rarely run apps that use D3D because they crash most of the time.
but when I get demos like your that run in both graphic library I always get disapointed at OGL.
your demo runs at 580 fps in openGL and 1496 in directx 9

I was under the impression OGL and D3d run at simular speed, but over and over again I am proven wrong.
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Changing joint parent body

Postby kallaspriit » Sun Jun 13, 2010 7:23 am

I will try to explain a bit :)

Basically the car is built out of a frame (just OgreNewt::Body, I am using convex hull) and tires. Each tire has the following:

SpringModel - takes compression x and returns spring force, just -k * x for BasicSpringModel, takes spring constant k as constructor parameter
DamperModel - takes acceleration a and returns damper force, just a * k for BasicDamperModel, takes damper constant k as constructor parameter. Can be easily extended to use a damper based on maps-graphs etc
TireModel - takes tire parameters like current load, camber, slip angle, slip ratio and returns maximum forces the tire can generate. BasicTireModel gives lateral traction as just a function of load, but this can easily be extended to use advanced model like Pacejka
TireJoint - calculates tire parameters, takes info from all of the models and applies the forces. I have implemented RayCastTireJoint, but this could be replaced with convex cast etc without changing the rest of the code
TireVisualizer - gets all the relavant information about the tire each frame and can be used to visualize the tire any way needed, allows using several visualizers at a time (subvisualizers)

The Vehicle containers allows adding and retrieving tires by name.

Every tire has it's own joint, that is used to apply lateral and brake forces, also limit suspension travel.
Code: Select all
// Apply lateral forces
addLinearRow(contactPosition, contactPosition, lateralTangentOrientation * Ogre::Vector3::UNIT_X);
setRowMinimumFriction(-lateralForce);
setRowMaximumFriction(lateralForce);

// Apply brake force (problem: the other body is null, not the body it's on)
if (brakeForce > 0.1f)
{
    addLinearRow(contactPosition, contactPosition, longitudinalTangentOrientation * Ogre::Vector3::UNIT_X);
    setRowMinimumFriction(-brakeForce);
    setRowMaximumFriction(brakeForce);
}

// Applies suspension travel limit
if (compression > maxCompression)
{
    Ogre::Vector3 maxCompressionPosition = rayStart + globalPinOrientation * Ogre::Vector3::UNIT_X * (rayLength - maxCompression);
    addLinearRow(contactPosition, maxCompressionPosition, globalPinOrientation * Ogre::Vector3::UNIT_X);
    setRowMaximumFriction(0);
}


Longitudinal and spring-damper forces are added directly:
Code: Select all
body->addGlobalForce(contactNormalOrientation * Ogre::Vector3::UNIT_X * springDamperForce, contactPosition);
body->addGlobalForce(longitudinalTangentOrientation * Ogre::Vector3::UNIT_X * useLongitudinalForce, contactPosition);


The full car initialization is as follows:
Code: Select all
OgreNewt::Body* frame = PrimitiveFactory::getSingleton().createConvexHull("frame.mesh", "frame", "", 1000, Ogre::Vector3(0, 1, 0));
frame->setAutoSleep(0);

// Shift center-of-mass lower
Ogre::Vector3 frameCenterOfMass = frame->getCenterOfMass();
frameCenterOfMass.y -= 0.2f; // top of the frame is actually not as heavy as the bottom
frame->setCenterOfMass(frameCenterOfMass);

// Create spring-models
Vehicle::SpringModel* tireSpringModelFL = new Vehicle::BasicSpringModel(50000.0f);
Vehicle::SpringModel* tireSpringModelFR = new Vehicle::BasicSpringModel(50000.0f);
Vehicle::SpringModel* tireSpringModelRL = new Vehicle::BasicSpringModel(50000.0f);
Vehicle::SpringModel* tireSpringModelRR = new Vehicle::BasicSpringModel(50000.0f);

// Create damper-models
Vehicle::DamperModel* tireDamperModelFL = new Vehicle::BasicDamperModel(50000.0f);
Vehicle::DamperModel* tireDamperModelFR = new Vehicle::BasicDamperModel(50000.0f);
Vehicle::DamperModel* tireDamperModelRL = new Vehicle::BasicDamperModel(50000.0f);
Vehicle::DamperModel* tireDamperModelRR = new Vehicle::BasicDamperModel(50000.0f);

// Create tire models
Vehicle::TireModel* tireModelFL = new Vehicle::BasicTireModel(1.0f, 1.0f);
Vehicle::TireModel* tireModelFR = new Vehicle::BasicTireModel(1.0f, 1.0f);
Vehicle::TireModel* tireModelRL = new Vehicle::BasicTireModel(0.8f, 1.0f); // give rear wheels less lateral traction
Vehicle::TireModel* tireModelRR = new Vehicle::BasicTireModel(0.8f, 1.0f); // give rear wheels less lateral traction;

// Create tire visualizers, note the DebugTireVisualizer as subvisualizer, draws the arrows
Vehicle::TireVisualizer* tireVisualizerFL = new Vehicle::BasicTireVisualizer(sceneManager, "tire.mesh", new Vehicle::DebugTireVisualizer());
Vehicle::TireVisualizer* tireVisualizerFR = new Vehicle::BasicTireVisualizer(sceneManager, "tire.mesh", new Vehicle::DebugTireVisualizer());
Vehicle::TireVisualizer* tireVisualizerRL = new Vehicle::BasicTireVisualizer(sceneManager, "tire.mesh", new Vehicle::DebugTireVisualizer());
Vehicle::TireVisualizer* tireVisualizerRR = new Vehicle::BasicTireVisualizer(sceneManager, "tire.mesh", new Vehicle::DebugTireVisualizer());

// Create tire joints, these could be convex-based instead etc
Vehicle::TireJoint* tireJointFL = new Vehicle::RayCastTireJoint(frame, tireModelFL, tireSpringModelFL, tireDamperModelFL, tireVisualizerFL, Ogre::Vector3(-0.68f, 0.05f, -1.13f), 0.25f, 0.15f, Ogre::Vector3::NEGATIVE_UNIT_Y);
Vehicle::TireJoint* tireJointFR = new Vehicle::RayCastTireJoint(frame, tireModelFR, tireSpringModelFR, tireDamperModelFR, tireVisualizerFR, Ogre::Vector3(0.68f, 0.05f, -1.13f), 0.25f, 0.15f, Ogre::Vector3::NEGATIVE_UNIT_Y);
Vehicle::TireJoint* tireJointRL = new Vehicle::RayCastTireJoint(frame, tireModelRL, tireSpringModelRL, tireDamperModelRL, tireVisualizerRL, Ogre::Vector3(-0.73f, 0.05f, 1.34f), 0.25f, 0.15f, Ogre::Vector3::NEGATIVE_UNIT_Y);
Vehicle::TireJoint* tireJointRR = new Vehicle::RayCastTireJoint(frame, tireModelRR, tireSpringModelRR, tireDamperModelRR, tireVisualizerRR, Ogre::Vector3(0.73f, 0.05f, 1.34f), 0.25f, 0.15f, Ogre::Vector3::NEGATIVE_UNIT_Y);

// Create tires
Vehicle::Tire* tireFL = new Vehicle::Tire(frame, tireJointFL);
Vehicle::Tire* tireFR = new Vehicle::Tire(frame, tireJointFR);
Vehicle::Tire* tireRL = new Vehicle::Tire(frame, tireJointRL);
Vehicle::Tire* tireRR = new Vehicle::Tire(frame, tireJointRR);

// Create the vehicle and add tires
vehicle = new Vehicle::Vehicle(frame);
vehicle->addTire("FL", tireFL);
vehicle->addTire("FR", tireFR);
vehicle->addTire("RL", tireRL);
vehicle->addTire("RR", tireRR);


TIPS: use vsync if you dont want flickering arrows, I have not fixed that issue. END button toggles reverse.

I made some changes to the code, get the lates from here. :P
kallaspriit
 
Posts: 216
Joined: Sun Aug 14, 2005 6:31 pm

Re: Changing joint parent body

Postby Stucuk » Sun Jun 13, 2010 8:35 am

Julio Jerez wrote:I was under the impresion OGL and D3d run at simular speed, but ove and over again I am proven wrong


Depends on the Graphics Card's implementation of them. It also may depend on OGRE, they may have slower code for the OpenGL side in Ogre. Large engines like OGRE are bad for comparisons.
User avatar
Stucuk
 
Posts: 801
Joined: Sat Mar 12, 2005 3:54 pm
Location: Scotland

Re: Changing joint parent body

Postby kallaspriit » Sun Jun 27, 2010 12:10 pm

Julio, have you had time to look into this?

I tried rewriting my raycast car in a way that the joints are generated dynamically every time the car finds a new body underneath it with the frame as child body and the other body as parent. For some reason, this breaks the collision detection and the whole thing becomes unstable.

This is the code I'm using:
Code: Select all
#include "TireContactJoint.h"

// If I use the other body as parent, the collision detection pretty much fails and everything is unstable
//TireContactJoint::TireContactJoint(OgreNewt::Body* frame, OgreNewt::Body* otherBody) : OgreNewt::CustomJoint(6, frame, otherBody)
TireContactJoint::TireContactJoint(OgreNewt::Body* frame, OgreNewt::Body* otherBody) : OgreNewt::CustomJoint(6, frame, NULL)
{
    this->frame = frame;
    this->otherBody = otherBody;
    this->load = 0.0f;
    this->longitudinalForce = 0.0f;
}

void TireContactJoint::update(const TireContact& contactInfo, Ogre::Real load, Ogre::Real longitudinalForce, Ogre::Real maxLateralForce)
{
    this->contactInfo = contactInfo;
    this->load = load;
    this->longitudinalForce = longitudinalForce;
    this->maxLateralForce = maxLateralForce;
}

void TireContactJoint::submitConstraint(Ogre::Real timeStep, int threadIndex)
{
    // Apply force generated by spring-damper system
    frame->addGlobalForce(contactInfo.normalOrientation * Ogre::Vector3::UNIT_X * load, contactInfo.position);
   
    // Apply longitudinal force that moves the body forward/backwards
    frame->addGlobalForce(contactInfo.longitudinalOrientation * Ogre::Vector3::UNIT_X * longitudinalForce, contactInfo.position);
   
    Ogre::Real otherBodyMass = 0.0f;
    Ogre::Vector3 otherBodyInertia = Ogre::Vector3::ZERO;

    otherBody->getMassMatrix(otherBodyMass, otherBodyInertia);

    if (otherBodyMass > 0.0f)
    {
        // for some reason, this makes the other body explode
        //otherBody->addGlobalForce(contactInfo.normalOrientation * Ogre::Vector3::NEGATIVE_UNIT_X * load, contactInfo.position);
        //otherBody->addGlobalForce(contactInfo.longitudinalOrientation * Ogre::Vector3::NEGATIVE_UNIT_X * longitudinalForce, contactInfo.position);
    }

    // Apply lateral force at contact point, given max force that the tire can currently generate
    addLinearRow(contactInfo.position, contactInfo.position, contactInfo.lateralOrientation * Ogre::Vector3::UNIT_X);
    setRowMinimumFriction(-maxLateralForce);
    setRowMaximumFriction(maxLateralForce);
}


This is how my method works:
1. Cast a ray
2. Find the body that the ray hit
3. If a body is hit
3.a If a joint exists and the body is the same as previous for this wheel, use existing joint
3.b Else, create a new joint with frame as child and the other body as parent
4. If no body is hit, destroy the joint

If I use NULL as parent body, everything works good except when breaking on other bodies, they don't move (the force does not get transmitted to it), the same problem with slipping on it sideways.

I can setup a demo if needed, any ideas?
kallaspriit
 
Posts: 216
Joined: Sun Aug 14, 2005 6:31 pm

Re: Changing joint parent body

Postby Julio Jerez » Mon Jun 28, 2010 1:50 pm

Neo, I am sorry I am working on a project that will help me to make thing simpler for all Newton users,
It is the Archemedia part of Newton 2.0
It is still on early stage, but I figure that I better make it because it is becoming too difficult to address issue one at a time.


It is time for us to have a formalize the authoring and modeling of scenes for people using the engine.
Remember when I hit a road block trying to add compel scene to OgreNewt, because Ogre do no have a way to handle hierarchies in a homogeneous way, by this I mean bone and scene node are different things, which mean all work would have to be special just for Ogre, and I was no going to go that.

well this toll will address that, it is the their Library on the Newton Tool, and it is a database manager, with plug in architecture, so by linking this libraty to OgreNewt, I will be able to add complex scene to oger Newt, in either Ogre format (by writing a plug in) or native by conversion that scenes on the flight.

Basically by using Archemedia, and OgreNewt anyone will have an almost complete Game engine, that will advance provide physics and graphics, Ogre cna be a runtime engine, and newton the runtime physics.
This is the reason I have neglected some support call lately.

you can check a preview here.
http://www.newtondynamics.com/downloads ... n-2.24.rar

once I have the visualization and Navigation I will integrate the Physics editing and then I will resume the ray cast car.
What this editor will do is that it will move the physics authoring from code form to data driven.
so as long as we model using the editor then we all can communicate batter.
basically each model will be a blue print rather that some specific piece of code.

It is my experience that Visual modeling is the equivalent to inject steroid to an application, you can have a superb engine but no way to create data visually, then you do not get the best of the engine, but you can have a mediocre engine with good visual tool and you can have incredible outcome.
I am trying to get good engine and good visual editing.

my next Plugin demo will be the inegration of teh neWorld library into OgreNewt, so that we can share work in by traferin the data and no by code.
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Changing joint parent body

Postby Carli » Tue Jun 29, 2010 6:17 am

but how does ogre handle networking? (with a newton world in the scene graph)
Carli
 
Posts: 245
Joined: Fri Oct 02, 2009 5:28 am

Re: Changing joint parent body

Postby Julio Jerez » Tue Jun 29, 2010 2:05 pm

The networking is a application dependent thing, The editor can help on teh Anotaions, of what is networking wnat messages, and stuff like that of object in the scene.

So if you are making a Network game and you wnat to use this editor as your Game editor, then you can write a Plug in that will take the Data that you have in eth scene and converted to your
Run time Game format and launch in the Ogre window.

The editor is all Plugin architecture and will support Custom data, so you can append Sound, graphics, Physics, particles, AI, Path, and Netwok infomation, all in persintence way.
so basically your infeface is a serieus of Plugin you will write to constomise the enditor to you engine,

This is not a Game engine and it is not a Mesh modeler, all of the data strutures are not for Remndefing ter ar for editing.
It is a game asset manager with limited graphics capabilities, like Solid modeling and material.
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles


Return to General Discussion

Who is online

Users browsing this forum: No registered users and 1 guest

cron