Reality Factory

http://www.codercorner.com/Opcode.htm ???

Issues: 1)I can't extend an extended body.

This is normal. Only a body can be extended, but you can add multiple extensions to 1 body and in this way work around it. That is just the way Tokamak is set up.

2) extending from the source Body object (trying to create the walls of the maze) I have buggy behaviour, flashing and crazy forces random applied....

Not clear what you mean, can you send me an example?

3) I don't understand the differences between the PosX, PosY, PosZ parameters and the following parameter triplet. It seems that the working one for modifying the relative position of the extended body is the second.

The first one is defining the position of the body and the actor connected to it, while the second one allows to offset the actor (so to de-center it from the body). It's a "dirty" feature, as it creates a discontinuity in the calculated physics. Small changes are mostly OK, but bigger steps can lead to a short instability. To be used with care, but is very efficient in resources and can avoid adding another joint / body!

4) the rotation parameters are in radiants and not in degrees ( )

This bug was meanwhile resolved

5) A StaticBody can't be jointed.

This extension was meanwhile added

actually I don't know how to put the maze over the plane, extendrigidbody is too buggy.

Not clear what you mean. In your demo, you do use an extendrigidbody to fix the maze-borders to the maze-plane, so what is the problem?
Important to know are:
Any extension can only be added to a body. Why? Because the body is the only thing the physics engine calculates position and rotation for. Extensions are just fixed geometry that is hard-connected to the body and which extends the collision bounding box
Extensions are always expressed in relative coordinates towards the body you connect to (eg pos, offset and rotation)
Offset allows to move the actor-mesh, independent of the bounding box.
So there You can connect the maze-border to the maze-plane by a Extendrigidbody.

Should I try to use SetPositionOfExtended(BodyId, GeomId1, PosX, PosY, PosZ) or SetAngleBetweenExtended(BodyId, GeomId1, GeomId2, AngleX, AngleY, AngleZ)? Whats the difference in respect of ExtendRigidBody? Are this commands useable in "Real Time" in the Start Order, to quickly modify an angle or a Pos?

- ExtendRigidBody is used to initialy connect additional geometry to a body.
- SetPositionOfExtended(BodyId, GeomId1, PosX, PosY, PosZ) and SetAngleBetweenExtended(BodyId, GeomId1, GeomId2, AngleX, AngleY, AngleZ) are intended to "on the fly" modify position and angle of an extension that was before defined by ExtendRigidBody.

Now a fantascientific question. Is possible to convert bsp model of the level in a physic object. In this case it would be very simple to create the maze (naturally i think no, but just to rule out the doubts...)?

I'm quite confused by the word "maze". Seems I give it another interpretation then you do?
Models are today not supported. My knowhow on genesis is limited and I do not know how to read the model mesh. I need this to create the corresponding Tokamak collision geometry and asked some help a while ago. Till now it's unsolved. This also means that doors and platforms are not seen by the Physics engine. It's an item we need to resolve, but I need some help on genesis

6) the CreateBallJoint hasn't rotation setting. To create a flipping maze is better than 2 crossed hinges, but I can't turn it up.

This was meanwhile added

7) Please excuse my tirosomeness...

No problem and value it a lot ! Any feedback is welcome.

Convex hull:
So how to have a complex and convex collision shape? Newton uses a system of aggregative hulls (i can't find the link anymore ).
There is a way to link the static mesh per face collision wih tokamak?

Tokamak knows 1 triable mesh only. This mesh is to my knowledge not hard restricted in size + does nor require that triangles are connected, so it can support multiple independent shapes in 1 mesh. I see it feasable to enxtend the code to look for staticmesh entities and to read these meshes additional to the standard bsp into the Tokamak mesh. So, yes, should be possible.

The static mesh collision is built on ode? say this because the staticmesh is attachable to pawns and so to bodies....

The static mesh uses the genesis collision. The fact you can connect it to a pawn does not means that the PAWN is becomming a rigidbody and that only a collision box is created for the pawn, not for the static mesh.

OPCODE

It's a well known library for collison detection and it is used in the ODE physics engine. I do not know what code is inside Tokamak, maybe it is also opcode? Before I started using Tokamak I've reviewed other physics engines. Tokamak is the easies and less heavy version, still supporting all important features. ODE is slightly slower and the demo's suffer from bugs. Newton is one of the better engines, with good physic properties and supporting many features, but unfortunately it is also slow. In the meantime I also discovered another interesting engine called JigLib. It support most features Tokamak has. After the alpha, I will devope some days to make a code test case using JigLib and see if this performs better then Tokamak. Main advantage: I have the code for JigLib, not for Tokamak.

Progress:
- The vehicle entity no longer crashes
- The car is correctly assembled and visible
- The steer hinge-rotation done by rotating the hinge's attachment "on the fly" is working, but shows some instabilities. I will skip the idea and first implement 2 additional hinges + steer control by Torque (as in the script). In a later stage I will try to remove them again and apply a joint-callback on the hinge and force the rotation inside the callback.
- So the focus is back on a VehicleEntity using 6 hinges

1) ... 2) ... 3) ... etc.. WOW!
Man, you go so fast! I'm trying to catch you but you are always beyond!
Nice to see all these implementation.
___
this is a tilting maze game: http://director-online.com/havok/demos/demo-maze2.html

Not clear what you mean. In your demo, you do use an extendrigidbody to fix the maze-borders to the maze-plane, so what is the problem?

When I'm talking about incorrect behaviour, I'm talking about unexpected random application of forces that completely turn completely the bodies, getting over the joint costraint and then collapsing all the structure...
Can you try to apply a new extensoin to the Body[1] in my example, so we can understand if the problem is my exe or something else?
_____

Can you put in the release both the vehicle, geometry+hinge / 6-hinge? I wanna try to understand how the things works more deeply...
_____

Bye!

How much work is needed to be done before the physics engine is complete?

The physics are today quite usable, but I face a problem of objects falling through the floor. the code of the physics engine is not public. A post was made on the Tokamak forum, but things move very slow down there...

This basically means that we are stuck
For simple physic scenes things work now, but when making a vehicle, or using high velocity bouncing objects, they just fall through the floor, unrecoverable...

I'm considering to swap to another physics engine
Newton is one of the better free engines, but it's also the slowest one and in combination with RF it will become unusable
ODE is an aternative, as it's quite fast, and I'm trying out something on this. The main problem to solve is to get the collision working (read: establish correct reading of all triangles of each brush and pawn + pass it to ODE). When this works, the other things are just a matter of time.

I've recently read through the license of Tokamak and Newton and they are both a bit limiting

The LICENSEE agrees to credit the use of the [physics engine] in any program information, including splash screens, "About" dialogs, program notes or instructions and shrink-wrapped packaging.

The LICENSEE agrees to notify [the Company] of any products, commercial, shareware or free that incorporate the [physics engine].

Are you planning on intergrating you physics stuff into the next release of reality factory?

by the way, i am pretty sure that no physics engine will ever be "perfect" but this is some pretty good stuff right here.

Thanks,
Fps

i am pretty sure that no physics engine will ever be "perfect" but this is some pretty good stuff right here

Sure but the "falling through the floor" issue it's terrific. Physics is this: you have a world with some rules. This has to be "rigid" in some sense or the world isn't a "cosmos" no more and becomes a "chaos". It's better to have not such complex rules if they aren't continously applied. it's better tohave the standard (and unrelistic) standard Genesis3d collision system than to have a collision system that somethimes fails to work correctly. In the Tokamak forums there are some trick to avoid the problem but none of them seems to be applicable to RF. The problem is emphasized by the slowness of the engine so there are little things to do for this at the moment. I understand Nout but it would be really sad to give up with tokamak after all this good work...

I've still some hope that Chris (the developer of Tokamak) will fix the "fall through the floor" in Tokamak, but it's unknown if and when this will happen.
Maybe it can help if many people form this forum post a request for solving this on the Tokamak forum, to get some priority call? I encourage everybody to do so and we have nothing to loose...

The latest RF with physics release is downloadable here:
http://realityfactory.altervista.org/download/

the archive is called RF073withPhysics7Jan2006.zip

I've checked the archive and the car test level is buggy and not optimized at all I apologize for that. Please check this progressive demos for rf with physics. Simply patch the RF with physics workfolder.

http://realitychess.altervista.org/physics/

check also the previous demos in this thread. They should work correctly now.

I hope that Nout can upload the source in the ftp site, I have some ideas...

Frederico,

Thanks for correcting and sending the latest car level.
I'm still working on adding the spring joint and the code does not yet compile again... but I hope to get this fixed soon

I'm playing with sensors and I've quite understood but i have some problems.
I set in the Init a sensor connected to the car chassis.

Sensor[0] = CreateSensor(Body[0], Dx*0.40, -Dy*0.50, Dz*0.47, 0,-90,0);

then in he start I debug the sensor Depth.

debug(SENSOR_DEPTH);
SENSOR_DEPTH = GetSensorDepth(Body[0], Sensor[0]);

I get always zero. Using other debug commads for sensor I got the proper results but not in the depth case. I read this post by you in the tokamak forum: http://www.tokamakphysics.com/phpbb/vie ... highlight=
I read that you had a similar problem. How have you solved it? I tried to exclude collision groups but it didn't work.
Another note: bsp geometry is the collision group -1. Good to know for our floor issue.

I found a trick to bypass the collision problem using a sensor. My understanding of sensors is 70%, the application is 20% 'cause I have some unexpected result tracking depth (I have always zero). So this trick can be rewritten in a better way. I also had some trouble with some command in Init order so there are some words to say about the script.

Mainly there is a sensor put on a wheel, in the center for two reason: 1) I don't know if sensors rotate with the wheels (I think no, but the showbbox drawing doesn't rotate, so I can't see) 2) I had some problem with detecting the bounding sphere of the wheel. That's strange, I can't get the correct result. My mind tells me that if I put the sensor at minus GetBodyBBox(Body[3], 1) / 2, long Y axis,I wil get the sensor colliding exactly on the tangent of the shere surface. This doesn't happen. Feel fre to correct me.
So Let's go over. I place this sensor directed downward.
Sensor[1] = CreateSensor(Body[3], 0,0,0, 0,-100,0);

-then in the start order I check for sensor collision so I have the ground collision Y coordinate (why, why, why depth doesn't work?).
SENSOR_DEPTH1 = GetSensorContactPoint(Body[3], Sensor[1], 1);

then I check for the current wheel Y origin (the Y position, in short), minus the y BBox dimension (oddity of the bbox detection). If the difference is greater than -14 then the wheel is under the geometry coordinate detected by the sensor.
Then I apply a force to make the wheels float until the detection is correct again.

if((((SENSOR_DEPTH1 - SENSOR_DEPTH2) > -14) and ((SENSOR_DEPTH1 - SENSOR_DEPTH2) < 0)) = true)
{
ApplyImpulse(Body[1], 0, 5, 0, true);
ApplyImpulse(Body[2], 0, 5, 0, true);
ApplyImpulse(Body[3], 0, 5, 0, true);
ApplyImpulse(Body[4], 0, 5, 0, true);
COLLISION_FAULT = true;
}
else
{
COLLISION_FAULT = false;
}

then I add in the force calculation a command to make the wheels go forward (or backward) if no collision (and friction) is detected.

if(((self.leftmousekey_pressed=true)and((self.key_pressed=46)=false)and((self.key_pressed=33)=false))and(((self.key_pressed=58)=true)or((self.key_pressed=58)=false))and(((self.key_pressed=57)=true)or((self.key_pressed=57)=false)))
{
TORQUE_REAR=260;
X_FINAL_TORQUE = TORQUE_REAR*(B_PERC/100);
Z_FINAL_TORQUE = TORQUE_REAR*(A_PERC/100);
if(COLLISION_FAULT = true)
{
ApplyImpulse(Body[5], X_FINAL_TORQUE/50, 0, Z_FINAL_TORQUE/50, true);
ApplyImpulse(Body[6], X_FINAL_TORQUE/50, 0, Z_FINAL_TORQUE/50, true);
}

This trick is very... tricky, probably too much tricky. But it is a starting point. My thought is: When geometry becomes more complex the physics fails to be detected not so randomly as you could expect. The problem is world geometry construction. There are "sensible zone" where detection fails. It's like a "hole" in the world geometry. it isn't like an high speed movements where the detection fails for graphics/physics engine different speed. I have attached to this post the script and a level. I've tried to create a little race arena for the buggy. The world complexity is low, but try to go in the curve where there are the three little cubes and you will see the collision issue. It's like an "hole" in the collision table. Then try again with my previous terrain level simple2.bsp
It isn't an high speed issue. I think that It's clearly related to world geometry. What do you think, master? Any Idea?

1) I don't know if sensors rotate with the wheels

(
Sensor have a fixed direction relative to the body you connect them to. So if you connect it to a wheel, it will turn with the wheel

2) I had some problem with detecting the bounding sphere of the wheel. That's strange, I can't get the correct result. My mind tells me that if I put the sensor at minus GetBodyBBox(Body[3], 1) / 2, long Y axis,I wil get the sensor colliding exactly on the tangent of the shere surface. This doesn't happen. Feel fre to correct me.
So Let's go over. I place this sensor directed downward.
Sensor[1] = CreateSensor(Body[3], 0,0,0, 0,-100,0);

I recently found out that sensors Tokamak callbacks. This is not implemented yet in RF.
BUT, I added a RayCollission command (This is the RF-complement of testing ray collisions, usign RF code, not Tokamak code). This command is able to detect depth aswell. I have to look up if it was added to PAwn scripting or to both, Pawn and Physics scripting.

-then in the start order I check for sensor collision so I have the ground collision Y coordinate (why, why, why depth doesn't work?).
SENSOR_DEPTH1 = GetSensorContactPoint(Body[3], Sensor[1], 1);

then I check for the current wheel Y origin (the Y position, in short), minus the y BBox dimension (oddity of the bbox detection). If the difference is greater than -14 then the wheel is under the geometry coordinate detected by the sensor.
Then I apply a force to make the wheels float until the detection is correct again.
Quote:
if((((SENSOR_DEPTH1 - SENSOR_DEPTH2) > -14) and ((SENSOR_DEPTH1 - SENSOR_DEPTH2) < 0)) = true)
{
ApplyImpulse(Body[1], 0, 5, 0, true);
ApplyImpulse(Body[2], 0, 5, 0, true);
ApplyImpulse(Body[3], 0, 5, 0, true);
ApplyImpulse(Body[4], 0, 5, 0, true);
COLLISION_FAULT = true;
}
else
{
COLLISION_FAULT = false;
}


then I add in the force calculation a command to make the wheels go forward (or backward) if no collision (and friction) is detected.
Quote:
if(((self.leftmousekey_pressed=true)and((self.key_pressed=46)=false)and((self.key_pressed=33)=false))and(((self.key_pressed=5=true)or((self.key_pressed=5=false))and(((self.key_pressed=57)=true)or((self.key_pressed=57)=false)))
{
TORQUE_REAR=260;
X_FINAL_TORQUE = TORQUE_REAR*(B_PERC/100);
Z_FINAL_TORQUE = TORQUE_REAR*(A_PERC/100);
if(COLLISION_FAULT = true)
{
ApplyImpulse(Body[5], X_FINAL_TORQUE/50, 0, Z_FINAL_TORQUE/50, true);
ApplyImpulse(Body[6], X_FINAL_TORQUE/50, 0, Z_FINAL_TORQUE/50, true);
}


This trick is very... tricky, probably too much tricky. But it is a starting point. My thought is: When geometry becomes more complex the physics fails to be detected not so randomly as you could expect. The problem is world geometry construction. There are "sensible zone" where detection fails. It's like a "hole" in the world geometry. it isn't like an high speed movements where the detection fails for graphics/physics engine different speed. I have attached to this post the script and a level. I've tried to create a little race arena for the buggy. The world complexity is low, but try to go in the curve where there are the three little cubes and you will see the collision issue. It's like an "hole" in the collision table. Then try again with my previous terrain level simple2.bsp
It isn't an high speed issue. I think that It's clearly related to world geometry. What do you think, master? Any Idea?

If it is geometry linked, then you can try a few more tricks
- Use RF collision detection on top of the physics by adding a transparent actor with the size of the bottom part of the car, but a little bit lifted from the ground??
- Or add a Tokamak hull around the car?
- Or add a tranparent geometry on the beginning and end of the car, slightly above ground?