RF and physics

[federico]

What do you mean? That we can renforce the bsp collision using a StaticBody for example? That's a good idea. But it can works only with simple geometry. Or, alternatively, we can export the geometry from the editor (I see a pdf doc in last week in the forum about this) and make it a rigidbody, but the hull convexity must be respected in some way. How can the engine react, thinking about converting the most of a level in a set of Tokamak StaticBody?
Another idea is to change the collision detection method. How difficult is that? Looking close from us, there is the ODE trimesh for staticmesh implemented in RF. How difficult can be topass this collision information to Tokamak? And how much can this can slow down all the collision process?
I see (adamwaves.com) a tutorial to have trimesh collision on tokamak. Is it too difficult to implement? Also this will slow down the collision? I think no, because it reduces the collision information.
About using the Genesis collision on top of tokamak, it can be a good idea too, but we have to avoid the risk of making the car collision and friction useless, adding invisible body can be a trouble. I never thought before, but I use a pawn for the chassis (to have pawn script functionalities) and I never see the car chassis falling through the floor. The issue is only with wheels, that are only RigidBody. I'll try to use pawns also for the wheels and I'll see what happens. Really every frame the collision process are two (Tokamak + genesis)? Perhaps is this that slows down some procedures...

[Nout]

What do you mean? That we can renforce the bsp collision using a StaticBody for example? That's a good idea. But it can works only with simple geometry.

There is a new script command that allows to extend a body. This uses Tokamak collision, and can be added on top. Meanwhile I also added Tokamak sensors that are usable from physics scripts, so likely this is a better choice.

Or, alternatively, we can export the geometry from the editor (I see a pdf doc in last week in the forum about this) and make it a rigidbody, but the hull convexity must be respected in some way. How can the engine react, thinking about converting the most of a level in a set of Tokamak StaticBody?

I don't see this working practically. A hull is not the type of collision box you look for, we need to be able to collide with each face.

Another idea is to change the collision detection method. How difficult is that? Looking close from us, there is the ODE trimesh for staticmesh implemented in RF. How difficult can be topass this collision information to Tokamak? And how much can this can slow down all the collision process?
I see (adamwaves.com) a tutorial to have trimesh collision on tokamak. Is it too difficult to implement? Also this will slow down the collision? I think no, because it reduces the collision information.

Principaly this is possible, but I see little added value. I would then rather fully swap to ODE (recall, I've made a first integration. Today some bodies fall through the floor even much worse then for Tokamak..., likely a wrapper problem but did not find my mistake yet)

About using the Genesis collision on top of tokamak, it can be a good idea too, but we have to avoid the risk of making the car collision and friction useless, adding invisible body can be a trouble.

By nature, any pawn has a RF collission box. By nature any Body has a RF and a Tokamak collission box. Removing one on the collision systems is not that easy but in fact it's overhead.

I never thought before, but I use a pawn for the chassis (to have pawn script functionalities) and I never see the car chassis falling through the floor. The issue is only with wheels, that are only RigidBody. I'll try to use pawns also for the wheels and I'll see what happens. Really every frame the collision process are two (Tokamak + genesis)? Perhaps is this that slows down some procedures...

Collision detection code is different for every primitive shape, so it's possible that sphere collision detection includes a bug, while capsule and box work fine. Having 2 collision systems is of course not speeding up the process. I've set up Tokamak in such a way that you can define the calculation speed independent of the time step by allowing multiple cycles. In PhysicsSystem Entity:
AdvanceTime = the time the simulator will advance in 1 RF frame. If you make this too big, the simulation will become unstable, but faster...
IterationTime = The real timestep Tokamak uses to calculate with. smaller is more accurate, but you will make AdvanceTime/IterationTime calculation cycles, so more an more cycles with smaller steps to still have a full Advancetime

[Nout]

Hi all,

In the last 3 months a lot of updates and new features where added to RF with Physics. All happened in the backgound without much posting on the forum

RF with physics starts to get first signs of some maturity and tons of improvements and new features are added
Main items worth to mention are:
- The physics are now integrated also in the latest release of RF075
- Thanks to the strong support and devotion of Fredrico, his great vehicle scripts where converted into a first vehicle script command available to the users. This command makes it very easy for a user to add a vehicle to RF and easy control it.
- Thanks to Frederico's discovery about the operation and usage of the slider joint (this joint was existing but not documented) it became now also a part of the physics engine.
- 2 ray sensors are added, one for RF and one for physics. These rays sensors offer the abilty to detect proximity of objects and to react on that.
- The engine supports now conditional breakable geometry (Eg a rope that will only break when you load it too heavy, or when you shoot it, but not when loaded with a normal weight)
- The script language for physics is strong enlarged and included now a total of 111 script commands; The 111 (not a typo ) commands offer already quite high flexibility but will be further extended
- Last features still on my list are:
Prio 1) add a vehicle entity features like steering, suspension, key control etc... that does not require programming (30% completed)
Prio 2) add a spring joint (60% completed)
Prio 3) add support for a crashable car (to do)
Prio 4) better collision support (to do)

To get a flavour of physics, have a look to the excellent demo created by Frederico (see other post: car with suspension)

An next alpha release of RF075 with physics I scheduled for mid March 2006

[wackedoutbiker]

All right man! Sounds like RF has made a lot of progress in my absence! But for now, I must continue work on the 2D version of my game. (just a fun little adventure game for all you guys)

BTW where can I find a copy of the RF docs to view online? I'm not at home.

[AndyCR]

http://dhost.info/realityfactory/onlinehelp/index.htm

Sorry for the short post.

[cel]

Just wandering, any news on an update for rf 0.75 with physics? Not alpha or beta, but the final stable release? Thanks in advance.

[Nout]

The program is on hold right now.
Too many other obligations.

[federico]

again on ragdolls. I finally got a ragdoll mirroring the pawn's bones without rotation bugs! This was a big trouble for us. Now a big update of the ragdoll source is needed. Then next step is to make the pawn's bones seek the ragdoll's joint while physics is applied.

[AndyCR]

Wow, nice work!