IrrNewt irrlicht\newton framework >> SVN access

[white tiger]

@DavidR: very strage. I upload it accordling to the FPS (i get this using driver->getFPS()). So it should be frame rate indipendent. Please wait until I test your problem more accurately

[white tiger]

Fixed. Thanks for the segnalation The fix is simple, in the file "irrnewt_source\world.cpp" find the function World::update() and change:

Code: Select all

float fps = (float) device->getVideoDriver()->getFPS();
if (fps > 0.0f) {
	NewtonUpdate(this->world, 1.0f/fps);
}

to:

Code: Select all

float fps = (float) device->getVideoDriver()->getFPS();
if (fps > 0.0f) {
	NewtonUpdate(this->world, fps);
}

and your game will be frame rate indipendent. This fix will be in the net release togheter with a manually update function. Thanks again

[white tiger]

I implemented ball and socket joint, convex hull collision and convex hull modifer collision. NOw only the follows newton features is not included in IrrNewt yet:

-coupound collision (a body wich is the addition of lots of body, for example a cube and a sphere up the cube)
-user defined joints (all newton default joints implemented)
-ragdoll

I don't know if I release a new version of irrnewt (0.2) now or when i will finish to implement ragdoll (currently working on it)

bye

[white tiger]

forgot to say in the last post. i have also implemented a pseudo number generator wich uses the famous Mersenne Twister algorithm, much faster and much random that the standard rand() function (in the IUtils class)

[DavidR]

Hi whitetiger.

No need to worry, I've tracked this issue down to something else rather than IrrNewt - it seems that the timing code doesn't work correctly inside of Irrlicht when I use CreateDeviceEx, and causes IrrNewt to go crazy. I simply coded an additional function to calculate things based upon clock() rather than Irrlichts built in time stuff.

But it is not an IrrNewt issue so don't worry

EDIT: Ok, didn't read your other post. If that has highlighted a bug in world.hpp, then that's good

[white tiger]

here are irrnewt 0.2 best NEW features from 0.11:

-support for all newton joints execpt user defined joint (hinge,slider,corkscrew, universal, ball and socket)

-convex hull collision (body with user defined non primitive collision) create by the node (no need that user pass any triangle or something like that)

-convex hull modifier

-all primitive collisions implemented (ellipsoid, box, cylinder, cone, chamfer cylinder, capsule and null)

-easier to implement in your program (new structures like SBody, SJoint and others pass they to the functions)

-many bug fixes

-in 'IUtils' new class a psudo random number generator (Mersenne Twinster algorithm,faster and more casual than rand()). useful for example to add a random force

-lots of new functions some wrapped from newton (setMinimumFrameRate,setPlatformArchitecture,ecc..) some don't be in newton (galAllBodies(), getAllSimpleVehicles())

-new hello world example
-adding comments in the examples

you can also find a pre alpha ragdoll implementation

[BlindSide]

I just downloaded it it seems very nice. Good work

I think I will make a fork of irrNet using physics incorporating irrNewt, is that ok with you?

Anyway there is one issue that is the HelloWorld example crashed because it could not find a model. Maybe it is missing or someone set wrong directory?

Good Luck with this you are making very fast progress

EDIT: @ kohaar's post below, I noticed in all collision involving terrain camera sticking is a problem, this is including Irrlicht's default collision. I also noticed both in Irrlicht and Newton nodes have a tendency to fall through terrain easy (Though I heard compiling newton in debug may solve this) This was a while ago so maybe it is fixed now.

[kohaar]

Great work on the version 0.2!

I have a few questions.

1. How do I adjust the sliding value of the camera in the fps example? I assume it has to do with material and friction, but nothing I do seems to change the friction. Can you give me an example?


2. Just an observation. Mouse sensitivity seems to depend a lot on framerate. This can of course be adjusted real-time, but just in case you didn't know.

[white tiger]

How do I adjust the sliding value of the camera in the fps example? I assume it has to do with material and friction, but nothing I do seems to change the friction. Can you give me an example?

yes sure:

1)create 2 materials by calling IWorld::createMaterial() 2 times and assign the returned values to the respective materials. For example call the first material terrainMaterial and the second cameraMaterial.

2)Set the material to all bodies that have that. in this case use something like that:
cameraBody->setMaterial(cameraMaterial);
terrainBody->setMaterial(terrainMaterial);

3)set static and dynamic friction using something like

cameraMaterial->setFriction(terrainMaterial, your_static_friction, your_dynamic_friction);

of course the result is the same using:

terrainMaterial->setFriction(cameraMaterial, your_static_friction, your_dynamic_friction);

Mouse sensitivity seems to depend a lot on framerate. This can of course be adjusted real-time, but just in case you didn't know.

Thanks I will ceck for that

I think I will make a fork of irrNet using physics incorporating irrNewt, is that ok with you?

yes

Anyway there is one issue that is the HelloWorld example crashed because it could not find a model. Maybe it is missing or someone set wrong directory?

Thanks for segnalation, the error is in the source code (i have changed it to test convex collision). I will release a new version (0.2) with the fix

I noticed in all collision involving terrain camera sticking is a problem, this is including Irrlicht's default collision.

This was happened in irrnewt 0.1 wich had no support for camera physics. In the current version collision in terrain_camera_fps example is checked using newton, not irrlicht

[kohaar]

1)create 2 materials by calling IWorld::createMaterial() 2 times and assign the returned values to the respective materials. For example call the first pmaterial terrainMaterial and the second cameraMaterial.

2)Set the material to all bodies that have that. in this case use something like that:
cameraBody->setMaterial(cameraMaterial);
terrainBody->setMaterial(terrainMaterial);

3)set static and dynamic friction using something like

cameraMaterial->setFriction(terrainMaterial, your_static_friction, your_dynamic_friction);

Here is what I have done, but no matter what I change the parameters to, the result seems the same, meaning that the camera will slide down a hill at the same "speed" (if you can call it that)

Code: Select all

	camera_body->addForceContinuous(core::vector3df(0,-350,0));

	camera_material=p_world->createMaterial();
	cube_material=p_world->createMaterial();
	terrain_material=_world->createMaterial();
	camera_body->setMaterial(camera_material);
	terrain_body->setMaterial(terrain_material);

	terrain_material->setElasticity(camera_material,0.0f);
	camera_material->setFriction(terrain_material,1.0f,1.0f);
	camera_material->setCollisionCallback(cube_material,&camera_cube_callback);

The source is your FPS terrain example, only I added gravity and friction

[white tiger]

ok.

-friction appears inefficacly beacuse camera body is an ellipsoid and an ellipsoid rolls on the terrain when you moving. The result is that the friction is not sliding but rolling, and as you know rolling friction is very lees than sliding friction.

In order to avoid body rolling you need to create a joint called "up vector joint" or "constraint rotation joint". in this joint "PinDir" is a vector3df indicates in wich aces the body must not rotate and in wich aces the body can rotate. A 0 value on an axis indicates that the body mustn't rotate on that axis, a 1 value indicate that the body can rotate. Also intermediate values (ex. 0.5) is provided.

Now we need that the ellipsoid rotate on none aces (rotate never). teorically we need to pass at the up vector joint a (0,0,0) pin dir. But a (0,0,0) vector can't be normalized, making not also the joint ineffective but also some physics engine's calculations wrong.

To avoid that we create two up vector joints, one with a "1,0,1" pin dir(don't rotate on y) and one of "0,1,0" pin dir (don't rotate on x and z) as described in the "demo" example. altogether the result is that the body don't rotate. Here are source code:

Code: Select all

//THE CAMERA BODY CAN'T ROTATE
	irr::newton::SJointUpVector upVectorData;
	upVectorData.ParentBody=camera_body;
	upVectorData.PinDir.set(0.0f,1.0f,0.0f);
	irr::newton::IJointUpVector* up_vector_joint=
		p_world->createJoint(upVectorData);

	//rotation constraint. avoid that the body rotate on y
	upVectorData.PinDir.set(1.0f,0.0f,1.0f);
	up_vector_joint=p_world->createJoint(upVectorData);
	//END

Now friction is rolling (improve friction making the terrain-camera speed slow)

Of course also a cube instead an ellipsoid makin the friction sliding, but it is highly un reccomended.

-in order to make camera-terrain speed low you will to set a static friction > 1 and a dynamic friction of course <= static friction (example 1.5-.15). If you set 2.0-2.0 (maximum) values your camera don't move when it is on the terrain

[benny53]

are you gonna release the source code anytime?

[kohaar]

It is definitely better, and thanks for taking the time to help me.

The camera seems to move on its own when it is rotated (not moved). Why is that? This is however not a big deal. What I’m looking for is a better way to move the player and characters than irrlichts collision detection ect. and irrNewt is a big improvement.

I do however have one big problem before I can actually use it. I can't get the irrNewt update to be framerate independent?

I have posted the code here: http://harme.dk/main.cpp

It's just your example with the modifications you gave me, and a timed update. If you past it into your example, you should be able to test it.

The changes I have made are marked with :
// start changed code
// end changed code

[white tiger]

What I’m looking for is a better way to move the player and characters than irrlichts collision detection ect. and irrNewt is a big improvement.

Thanks

The camera seems to move on its own when it is rotated (not moved). Why is that?

rotateFromMouse() rotate the body and the scene node. but we take the two rotations separately (setUpdateRotation(false)) and we don't want that the body rotate (up vector joint). So temporanely insert a

setRotationGeometry(core::vector3df(0,0,0))

after rotateFromMouse. Of course in the next release the name of this function (setRotationGeometry) will be changed to setRotationBody() and there will be another function like rotateFromMouseNode() or something like that (wich rotate the node and not the body)

I do however have one big problem before I can actually use it. I can't get the irrNewt update to be framerate independent?

uhm? on my computer p_world->update() is frame rate indipendent (I see you use IWorld::update(s32 frame) overload function to update newton manually). the bodies has the same speed at any frame rate. isn't it?

Maybe you want that the body is slow on low frame rate and fast on high frame rate. in this case uses

p_world->update(1.0f/deltaTime);

Also

double lastTime = 0.0;

may be in my hopinion

double lastTime = device->getTimer->getTime();

because the first loop the time is:

double time = tmr->getTime(); //5000 for ex.
float deltaTime = (( (float)time - (float)lastTime ) / 1000.0f); //=5
lastTime = time;
p_world->update(deltaTime);//update with 5 seconds. making updating too fast

bye

[white tiger]

are you gonna release the source code anytime?

Sorry for that IrrNewt must be open source. I will release source code soon (afterwards some clean up)