Page 1 of 1
(simplified) Physics now working
Posted: Wed Sep 05, 2007 12:36 pm
by federico
the most annoying problem of the tokamak engine implementation in RF (not mine, credits are due to Nout), was the instability: continous crashing, general system instability, and some oddity in simulation behaviour due to bad timings (graphics or physics, or both?). I was furious about this: so close to the goal and at the same time so far...
I dismounted the Nout code and I created a barebone physics then i added the features following a complexity order. I have a stable release of 075c+physics:
- Rigidbody simulation, using editor entities and physics script
- Materials
- BSP and staticmesh trimesh (a per-face collision of terrain and bsp level)
- Projectile and basic player integration
It's good enough, even if we can add anything more...
I still don't know how much I can save of the original setup (dozens of commands and procedures). Vehicles are not in schedule: I loved to play with car physics but, really, who needs that? I mean right now with this engine? ...
Simplified (! don't expect too much) Ragdolls are the next step after a basic release (probably including the community release? let's see...).
Here's a video:
http://www.youtube.com/watch?v=PX0HqeTU2O8
...you will notice the setup of my
secret project, don't ask about it....
Federico
Posted: Wed Sep 05, 2007 2:44 pm
by bernie
Absolute magic
. You are the greatest. Please can you give us a release soon? Can't wait to get my hands on the physics.
Posted: Thu Sep 06, 2007 6:28 am
by zany_001
AWESOME!"!!!W000000000000T!!!
does it mean we have ragdoll?
Posted: Thu Sep 06, 2007 9:08 am
by Juutis
zany wrote:does it mean we have ragdoll?
federico wrote:Simplified (! don't expect too much) Ragdolls are the next step after a basic release
Excellent work! I think having physics in the environment is far more important than having ragdolls. Well yeah, ragdolls are cool but being able to interact with the environment better gives new ways to create puzzles, for example.
How much is this going to affect the framerate?
Posted: Thu Sep 06, 2007 10:07 am
by federico
does it mean we have ragdoll?
yes and ... not yet. A composed ragdoll is ready and working. I created a demo some time ago (downloadable in my physics stuff). Search other physics topics: the difficult is to make the genesis actor bones copy the ragdoll position and rotation. There are new xommands for that, used also in my torso rotation script. Have you seen the torso of my hero rotating to aim the target? The problem is that you can add rotation
relative to the actor reference position.
How much is this going to affect the framerate?
it's a difficult question: you can tune the physics simulation to have a more or less physics loop iterations, or change the timestep (how much the simulation time steps foreward each frame) to have a good and fast result. If the timings is to heavy for the engine the bodies simply "fall through the floor" (another old problem). I have a slow machine so I can't be too sure about, but except from the fact that Genesis bodies flying fast in your world are quite stressfull for the engine, I didn't noticed any slowdown due to the physics itself...
You will see that the real issue is to define the right mass, friction and restitution parameters because the RF world is quite "scaled up" comparing to the tokamak units. The proportions are the key to a fast and economic simulation behaviour. If the physics engine can't
solve the problem, the framerate simply fall, otherwise I feel (it's a feeling, you know) that properly tuned tokamak doesn't affect the RF speed.
Posted: Thu Sep 06, 2007 4:32 pm
by darksmaster923
oooooooooooooooooo kool!!!!!!!!!
and nice player and weapon.
Posted: Fri Sep 07, 2007 9:23 pm
by zany_001
does this mean there will be a new reality racer demo?
Posted: Sat Sep 08, 2007 4:15 am
by darksmaster923
zany_001 wrote:does this mean there will be a new reality racer demo?
or....................................
zombie mod where u have to barricade urself in a room like css zombie mode
Posted: Sat Sep 08, 2007 2:19 pm
by federico
well guys, don't expect too much: it's a simplified version of the Nout's ideas...
Read what I wrote: no vehicle support and basic scripting manipulation. Mainly the result will be the ability to add an entity like a staticentityproxy that has a mass and react physically over the BSP world.
Posted: Sun Sep 09, 2007 11:03 pm
by Jay
Oh i didn't see this! Congratulations for getting it to work!
A mass? that means that when you add a thing with mass 1.0 and then one with 2.0 the one with 2.0 will move more slowly when you push it? Does this apply to force? What is a mass unit? (1.0 mass = ?? kg). Also, an different projectiles have different 'push' values (how much mass they can push)? (many questions i know)
Posted: Mon Sep 10, 2007 2:59 am
by paradoxnj
Does this apply to force?
Yep..because F=ma (force = mass * acceleration) (Newton's second law). A mass of 1.0f would have a "default" effect because anything multiplied by 1 is itself. A mass of 2.0f would provide more resistance to a push depending on the amount of force being applied by the object doing the pushing. If the target object is also moving, then Newton's first law applies (law of inertia).
Posted: Mon Sep 10, 2007 5:15 am
by AndyCR
I was kind of out of it when I clicked the link (and I have my IDE open - bad combination), and I thought I was watching a Half-Life 2 video until I realized what link I had clicked.
Posted: Mon Sep 10, 2007 10:06 am
by federico
Anothe time: all credits are due to Nout (I'm becoming quite paranoid on this credit, I know...)
about the mass, the paradoxnj answer can't be better. And yes, you can set in the weapon.ini the projectile force (used to calculate force on collision with tokamak bodies).
I need some more time to take again the 075c code and integrate physics from scratch: it was a suicidal work so I didn't commented well the code and the changes. Then I must cut the GameEntityDataTypes list of physics entities to leave only the working one. The Nout's doc are still here but a revision is needed.
Though I'm still not working on this trying to make the ragdolls work (they work I have troubles orienting the pawn bones with the ragdoll bodyparts), I feel that I must come out with somthing this month.
I don't want to create a community release (I'm also planning an integration of toka in the community release, or the implementation of some CR features in RF+TOKA). I want to create an RF "release candidate". QoD, what do you think about?
Posted: Sun Sep 16, 2007 12:38 pm
by Jay
about the RFCR+ TOKA (community release + physics), i could be of help, because i know my own code better than most others do. I will cut out the code which is not working in the community release (like the EntityAreaSystem, the code is still being used, no fear, it's only the working code), fix some bugs (there is a bug in the WindGenerator entity which can cause the Wind to always go into the same direction) and then try to merge the two releases (the physics release and the community release). I may also put new stuff into the merged release (new low-level cmds, and the pathfinding). What do you think?
what's that staticmesh trimesh? is this a speed improvement for per-poly collision? The name suggests that the mesh is split into 3 parts and the per-poly collision is then done afterwards.
Posted: Sun Sep 16, 2007 1:40 pm
by federico
Great. When you integrate your code I can show you how to handle physics entities directly from your code. For example: how to make your wind generator affect physics bodies.
The trimesh is the "tokamak terrain" and, yes, it's obtained by a process of triangulation of the bsp. It's a process similar to the per face collision we have with the staticmesh. In fact the staticmesh trimesh calculation can be added to the tokamak terrain.
The tokamak terrain is the static world and it has per face collision while all the rigidbodies can have only three shape (box, cylinder, sphere). In this way the rigibodies react colliding with the bsp world.