RF and physics

[Nout]

Just want to let you know that I'm building physics into RF
and that it really start to work!

It's still quite basic, but you can script quite some physics in a simple way and already do some nice things with it. If all runs well, I hope to publish an .avi demo in the coming days, to show a few things

Furhtermore a ton of additional features where introduced (>70 features) and some known bugs resolved (eg the moving platform and door)

Quest, Gekido,

Can you highlight who will be the person to contact to release these all these features and how to pass this release? I'm finishing up the first sets of physics and then want to ship it.

[GD1]

WOOT! WOOT!

thanks Nout, this is amazingly great news, probably the best news all year! will this also include your other scripting changes that never got released (time warp, zoom, scriptable HUD, etc.)?

i remember hearing that Gek couldn't integrate them because they were written on the old source 068, will that be a problem this time?

anyways, keep up the good work! and BTW, i believe either wxb1 or Quest of Dreams would be the person to contact, but i may be wrong.

[hike1]

Quest is your guy, but the .exe you sent me 2 months ago still has bugs, why don't you get that going with the current source?

Which is at
http://terrymorgan.net/download.htm

[QuestOfDreams]

yep just send me the changes and I'll try to integrate them into my build as soon as possible; if possible give a short description of what you've changed (e.g. list of modified files)

[Spyrewolf]

Just want to let you know that I'm building physics into RF
and that it really start to work!

Furhtermore a ton of additional features where introduced (>70 features) and some known bugs resolved (eg the moving platform and door)

Wow you have been busy, the engine is really comming up in leaps and bounds in the last few monthst hanks to you guys!!! im interested in the physics this has been on alot of people's wish list for years, are you expanding on the genesis physics library? or have introduced an entirely new one?

Either way any physics would be greatly appreiciated! this is good news can't wait to see the AVI's in action

[MakerOfGames]

SWEET! I got a question though, are the physics using the current bounding boxes/skeleton? Or in the process did you create per polygon collision? I know bounding box physics are possible and I have a system devised in my head,(requires invisable objects attached to the main object to have physics, if contact then rotate main object etc.) Anyway, I am just curious to see if RF will be getting per polygon collision in this upgrade. To get the most accurite physics you would need per polygon collidion detection. Whatever type it is, THATS GREAT NEWS!

[GD1]

most games actually dont use per-poly collision, as this is a big resource hog, when resources could be better spent making the scene prettier. systems like ODE allow for per-poly collision, but primarily use a set of primatives welded together with different types of joints to "block out" the basic geometry of the character.

for example, say you have an object like a golf ball, with the dips in the ball individually modelled. now, it would be a waste to check for collison inside each of those dips, so most game developers would substitute a single sphere primative instead.

some of the newer games coming out in the next year or so use per-poly however, but modern generation games use a combination of primative based collision and special low-resolution collision meshes.

[MakerOfGames]

Hey, thanks for the info. I think I already knew that but forgot. I taken a very close look at the games I play and have noticed where collisions are and when the event activates. Also, on G4, I saw a presentation on the making of the Fantastic 4 videogame. And they showed one of the charactor models covered with bouding boxes. I didnt know per poly was such a resource hog though.

[federico]

Hi Nout, I have a simple question 'cause i didn't understand at all. When you say that you are starting to build physic on RF, what do you exactly mean?

in the old-middle forum we started a thread about this. I have a copy.

The physic topic is one of the most recurring in the forum. I want to start this trying to place a milestone in the continuous and partial circus of question and answer. I don’t know ALL the answer so help me to find the right way.

1) Reality Factory has his physic system derived by Genesis3d. Rigid body, gravity and bounding-box collision. We can’t define mass but we can use scripting command to apply forces: ForceForward, ForceBackward, ForceLeft, ForceRight, ForceUp, ForceDown.
There is extended physic in the projectile entitity, or the actorspout entity, setting true the Bounce parameters, but there is a strange inertia and can’t be scripted.
We can create rigid body joined together but we can’t add a joint between two entities.
Command for attaching actors: PositionToPawn PlayerToPosition PositionToPlayer and HighLevel command AttachToActor(“Entity Name”, “Slave Bone”, “Master Bone”, offset_X, offse, offset, rotation_X, rotation_Y, , rotation_Z) --- this must placed in the master pawn script in Spawn Order.
The collision works with bounding box (no triangle-triangle except the new static mesh entity). Note that this box don’t rotate with the actor. You can set only the width of a square as basis of the box, you can’t define the height.

2) Genesis3d has his physic system. Here we have the confusion, because even the genesis users (that people who really use c++ in games) haven’t a complete knowledge about this.
Here the most interesting topic:
http://www.genesis3d.com/~kdtop/Physics ... al%201.htm
http://www.genesis3d.com/~kdtop/Physics ... al%202.htm
http://www.genesis3d.com/~kdtop/Physics ... al%204.htm
What have I understood? …umh, you probably will need programming to make it work, but I read that GTest (or GDemo) has some physic entities. In the Header of entities for the world editor (that file in the “source” folder) there are three entities, if I correctly understood: PHYSICS_JOINTS: PHYSICS_OBJECTS: PHYSICAL_SYSTEMS:
So, instead ask to implement the complete Genesis3d physic in RF, we have to ask: “Is it difficult to implement these entity in RF?” Probably it is.

3) Scripted physic and new commands. Scripting a simple physic it’s not really difficult. Do you want to create a bouncing ball? Let’s make a script that ForceUp the pawn proportional to his time of falling. More time of falling = more reaction force.

{//ball.s

TIME [0]
FORCE [0]
FLYTIME [0]

Spawn[()
{
Console(true);
LowLevel("Setup");
}]

Setup[()
{
debug(FLYTIME);
if(self.IsFalling=true) // the pawn is flying
{
TIME=self.time; // all the time minus this time is the flying time
self.think="Fly";
}

if(IsKeyDown(7))
{
ForceUp(50);
}

if((FLYTIME*50)>20) // 20 is the lower limit for bounce
{
ForceUp(FLYTIME*50); // 50 is our coefficient for multiply the flying time
}
}]

Fly[()
{
debug(self.time-TIME); // keep the track of time

if(self.IsFalling=false) // stop tracking time
{
FLYTIME=self.time-TIME; //all the time minus that time is the flying time
self.think="Setup";
}

}]

}

Time is you friend. In this case Force+Time=Physic.
Dan Valeo created new commands for scripting a physic system that extend these possibilities. You can find it in the old forums but you have to rebuild RF with MSVC. He created a command to compute the distance bone to bone (yeah!), but essentially all these commands, new and old, are in the same family and you have to script a lot. Naturally a scripted physic is slow and not accurate.
In my racing demo, I made a scripted simulation of wheel sliding and sterring inertia using a complex way to handle the keyboard input. I set, via script, a latency in the keyboard input so the steering power increase and decrease progressively and so the engine torque etc.. Most of this script has been created in an “empirical way”, but basically is a complex (and useless for study) remake of my simplified “ball in the box “ demo.


4) External implementation. Greywolf started (but stopped) an attempt of implementation of external dll. There are several physic system like ODE that can be implemented in this way. Anyways it would be an really useful but potentially endless work.
http://www.realityfactory.ca/v4/viewtop ... sc&start=0

____________

Any idea?

Fede

three things widely different. the first and the third don't change the matter of RF and it's OK (see my last demo Ping in this forum). the second really sounds like "building physic in RF". it would be wonderful, a real step behind. the fourth - i suggest to you that all the enthusiastic guys here are thinking thait you said this! - it's ALL another thing (and it would be incredible)!
Here all we have ideas confused ...

exactly, what are you doing

[Guest]

Some more details on Physics
I work in 4 steps, maybe 5

Step 1: I first used the physics from genesis. Main issues found are
- You need to code each collission
- You only have box bounding boxes for collision, a strong limitation
- The collision detection is not very accurate and geometry easy move through walls etc...
I experimented with the calculation speed, but this did not bring much.
After about 4WKs I decided to leave it and integrate another available physics engine

Step 2: I started to integrate the Tokamak physics engine. Why Tokamak? Because I'm a total newbie to physic engines and Tokamak is one of the more easy physic engines I could find. It is also dedicate to games. It however does support rigid bodies, mesh, geomerty, colission, some joints, sensor, motor, breakable geometrie etc... so enough to start with and to learn.
I've now integrated Tokamak on top of RF. This means that you can assign a pawn to a physic body + geometrie and that you can connect bodies by joints. All is available as normal entities and easy to use. I also added a chain entity, to hook several bodies into 1 chain. You can hook the chain to walls, make a bridge etc... Next I added scripting. You can by a script define bodies, geometrie and joints. This script is read at startup and builds your physics + actors. Afterward the script is no longer used, so it does not affect frame rates. This scripting opens tons of possibilities; like predefining the physics for a car, a bridge, a chain etc... Also in the low-level pawn script, new commands are added to place a force, or an impulse or torque on physic bodies.
There are also disadvantages: Tokamak (like most physics engines) uses his own colission system, on top of genesis. This allows you to define sphere, box and capsule collision, but it only works for the pawns you have assigend a pysics body to.
Known issues:
- Not all pawns or actors have correct bounding box information and this messes up the physics, a bypass is created where you define yourself the bondingbox
- It's not strait forward to get the physic parameters set well to avoid bad collision. The defauts are now typically quite OK, but all is made changable.
- Models are read fro BSP and treated as a static mess. This makes the collision with moving platforms/doors not "moving" with the platform. The way to solve this is to read models separate from BSP and assign them to rigid bodies. This is possible, but I just need some help to get this piece of code created to read these models separate.
- Still sometimes bodies pass walls. By playing with settings this should be solvable

As step 3: I now started to extend the physics scripting language by adding sensors and motors. This is new for me and I'm learning how it works. With motors and sensors you can make physics for a car. My goal is to have a physics script that defines a general car and in which you only need to define the actors used to let it work

Step 4: I think it would be wise to replace the genesis collision fully by the tokamak collision, but it's not so strait forward... so I'm hesitating...

Step 5: I've also considered using another physics engine aswell. The examples of ODE are quite unstable + ODE misses a few features like scripting. Newton sounds very advanced and stable, but it's relative slow. I'm a bit reluctant to add these 'more heavy' engines into RF as I'm affraid they might kill frame rates quite fast. These engines sound more something for newer graphic engines, but I can be wrong here.

I hope this makes clear what I've added and what I'm working on

[Nout]

Hmm... seems I logged in a guest rather then as Nout

Hike1: Any bugs you know, please send me the info so I can resolve them

Quest: I'll send you the code in a few days. In parallel I will add sensors and motors, but in this way you can already update the latest code with all the changes

[hike1]

There was no
inventory, the custom inventory screen was gone. At
the beginning pressing 'comma' (my inventory) turned off
stencil shadowing on Wallie. The movement through the
game seemed jerky, but this may be true for all .exe's.

Save/load game worked
Still jitter when I had conversations, need to make a full
screen conversation screen.

No doubt you figured out the inventory thing is related to
the gameentitydatatypes.h? When I use the old .exe with the
new gametypes, I get the wrong inventory screen but all the
items are there. With both the new gametypes and exe, I get
the wrong inventory screen and no items.

Also, unless I start with all weapons at the beginning, I can't
get them back after I holster or change weapons, that is, a
weapon picked up in the game disappears after I holster or
change to another weapon.

[MakerOfGames]

Just a thought, I know per polygon collision is a resource hog but: cant you use the data gathered in the polygon shadow file of the RF source to write the code nesicary for per poly collision? What I mean is because the code for poly shadow requires the constant collision of the polys and rays of "light", you could use the data gathered for the per poly of the actor and instead of colliding with light, you have the actor collide with other entities. I am not sure of what you all are talking about but just throwing an idea out there. I thought per poly collision was needed before you could do high end physics because of the collision inaccuracies of bouding box. But once you get per poly collision, how do you define what to do for each polys collision? I thought of trying to write code for per poly collision, but I am a total noob to C++(I was teaching myself C++ in my freetime a while ago.) and cant decifer alot of the RF code. All I know is it is great to see this work being done on RF.

[Anaxagoras]

Um... I don't mean to be a bother, but I was just curious about the physics system Nout's working on. I'm no programmer (I have plans to learn C/C++, though) and I was just curious what kind of physics system this will be? I mean, will it duplicate ragdoll-esque physics, or am I completely off? I apologize for my cluelessness. Oh, and looking forward to it no matter what it's like!

[federico]

ok Nout! Theese are the four steps to the glory of RF! I can't wait for testing your physic!!!