Tumle v1.4 irrlicht/newton

JonLT · Post by **JonLT** » Fri Apr 13, 2007 1:41 am

Tumle 1.4
You would think that such a big leap in version number meant that a big deal has happened. Thats not the case, sorry. This is just to indicate that Tumle now works with irrlicht 1.4. The only thing changed is the way the event receiver is passed on to the Tumle classes. In stead of a pointer, it is now a const ref.
I've also made Tumle a little more Linux friendly, by putting in a 'configure' script that makes some makefiles.
Here's the link: tumle-1.4.zip
mirror
mirror
~ 160 kb.
Thanks to FuzzYspo0N for pointing out the need to update.

Tumle v0.1
Tumle is a irrlicht/newton framework i've been working on as I thought it would be usefull for a game.
Tumle (aka IN) consists of the same files as IN, the only thing changed is the name and some small stuff, I've also added a version number for convenience.

The features:
- create physics objects from scene nodes.
- create and apply materials to the objects, to control the objects behavior.
- collision callbakcs, to control what happens when objects collide.
- user controlled physics objects.
- user controlled physics FPS camera.

Download includes
- Source files.
- Six example files.

How to use Tumle
- Download the newton SDK, include newton.h and link to newton.lib.
- Add the Tumle source files to you project and include the Tumle includes.
- Do whatever you do when you use Irrlicht.

The only thing left now is to download: tumle.zip ~ 160 KB (this is the old one - look above)

Changes since IN:
http://www.jonlt.frac.dk/tumle/changes.txt

P.S. To you who use IN (if any) just rename everything that was called IN to Tumle, and you should be fine.

Halan · Post by **Halan** » Fri Apr 13, 2007 12:18 pm

cool

rm a character controller would be nice

JonLT · Post by **JonLT** » Fri Apr 13, 2007 2:20 pm

Thanks for downloading!

Character controller is on my wish list along with a collidable camera.
Haven't looked into it yet though

Midnight · Post by **Midnight** » Sat Apr 14, 2007 3:37 am

Q. What are Q and A tags for?
A. Oh they make things contextual.

Q. What do you mean?
A. It's so things make sense.

JonLT · Post by **JonLT** » Sat Apr 14, 2007 5:48 pm

I've made some better documentation http://www.jonlt.frac.dk/IN it really made me feel important

And I've added Q and A tags in the initial post for you midnight

EDIT: (documentation is included in the download now)

JonLT · Post by **JonLT** » Mon Apr 16, 2007 3:01 am

I've managed to make a colliding camera, calling it INCamera

.
And I've cleaned up in the code, i really think this is getting usefull

Anyways the link in the initial post now links to the improved version.

roxaz · Post by **roxaz** » Mon Apr 16, 2007 6:32 am

i made colliding camera too but while moving speed is increasing. maybe you managed to keep constant camera speed? i tried but im noob at physics so it was too hard for me

P.S. maybe you are from Lithuania?

JonLT · Post by **JonLT** » Mon Apr 16, 2007 12:28 pm

if you move the camera with forces it will accelerate, if you want a constant speed use NewtonBodySetVelocity

roxaz · Post by **roxaz** » Mon Apr 16, 2007 1:53 pm

not exactly. i done this like you said. here it is

Code: Select all

void Player::updateMovement()
{
	vector3df move(0,0,0);
	if(keysDown[KEY_KEY_W])
		move.Z += MAX_SPD;
	if(keysDown[KEY_KEY_S])
		move.Z -= MAX_SPD;
	if(keysDown[KEY_KEY_A])
		move.X -= MAX_SPD;
	if(keysDown[KEY_KEY_D])
		move.X += MAX_SPD;

	node->getAbsoluteTransformation().rotateVect(move);
	float moveF[3];
	tb::vecToFloat(&move, &moveF[0]);
	float currVeloc[3];
	NewtonBodyGetVelocity(body, &currVeloc[0]);
	float newVeloc[3];
	newVeloc[0] = moveF[0] + currVeloc[0];
	newVeloc[1] = moveF[1] + currVeloc[1];
	newVeloc[2] = moveF[2] + currVeloc[2];

	NewtonBodySetVelocity(body, &newVeloc[0]);
}

body is still moving faster and faster. i tried not to add current velocity, then body speed is cinstant but gravity does not work for this body.

JonLT · Post by **JonLT** » Mon Apr 16, 2007 2:28 pm

you are adding the velocity, but you just need to set it:

Code: Select all

if(keysDown[KEY_KEY_W]) 
    move.Z = MAX_SPD;   //not +=

and after the key check try this:

Code: Select all

float newpos[3] = {move.X,0, move.Z}; //only mover vertically
NewtonBodySetVelocity(body, (float*)newpos);
        
if(!(event.KeyInput.PressedDown)) //stop the camera if the keys are released
    {
            move.X -= somefloat;
            move.Z -= somefloat;
    }

[EDIT: sorrry didn't see that last line in your post

, im currently trying to get the same thing to work]

roxaz · Post by **roxaz** » Mon Apr 16, 2007 3:00 pm

check this out http://www.newtondynamics.com/forum/viewtopic.php?t=753 maybe you will have more luck in understanding it

JonLT · Post by **JonLT** » Mon Apr 16, 2007 3:10 pm

this is what needs to be done:

Code: Select all

 
node->getRelativeTransformation().rotateVect(move); 
float currVeloc[3]; 
NewtonBodyGetVelocity(body, &currVeloc[0]); 
float newpos[3] = {move.X,currVeloc[1], move.Z};
NewtonBodySetVelocity(body, (float*)newpos);

this gets the vertical velocity and passes it on the the new velocity

roxaz · Post by **roxaz** » Mon Apr 16, 2007 3:57 pm

its not good too. lets say camera is moving and box hit camera. box will bounce from cam like from wall because it can not affect cam speed. in other words - when camera is moving it looks like cam mass is infinitive

JonLT · Post by **JonLT** » Mon Apr 16, 2007 10:28 pm

Julio Jerez wrote this:

Unfortunately there is not way to move bodies kinematically in 1.5, 1.6 will have that ability so these problems will be a lot easier to deal with, since it will be legal to set the body velocities and the solver will understand it correctly. This will allow for the implementation of player without having to use inverse dynamics.
Until then thei sis the only thing Newton can offer.

on the newton forum:http://www.newtondynamics.com/forum/vie ... php?t=3370

Wikipedia on inverse dynamics: http://en.wikipedia.org/wiki/Inverse_dynamics

Inverse dynamics uses link-segment models to represent the mechanical behavior of connected pendulums, or more concretely, the limbs of humans or animals, where given the kinematic representation of movement, inverse dynamics derives the kinetics responsible for that movement. In practice, from observations of the motion (of limbs), inverse dynamics is used to compute the associated moments (joint torques) that lead to that movement, under a special set of assumptions.

So unless we want to give the camera legs, i think we have to settle with infinit-mass-camera.

If you set the mass of the camera to much less than that of the bodies, the only wrong thing happening is, that if the camera is moving while being hit with someting, it will not respond all to good, but the object hitting it behaves as it should.

roxaz · Post by **roxaz** » Tue Apr 17, 2007 12:57 pm

if so... then we will have to wait until 1.6 comes out