ODE physics in FTE

Here’s how to make bouncing stuff in FTE.

Read the ODE manual and FAQ

This is mandatory in order to understand what the various console variables actually do. Really, I can’t stress this enough. ODE has a very dry, very technical, but also very thorough documentation. You should set a weekend aside to read it.

You might also want to watch most of the Youtube playlist about ODE.

Install the ODE library

You might need to compile the ODE .dll (.so for linux) yourself. The ODE source comes with a configure script for Linux, and compiling is straightforward (read INSTALL.txt.) You want to run ./configure – -help and have a good look at all the compile options. ODE is installed under /usr/local/lib/libode.so.3.1.0 (or later version number.)

Under Windows, you need Visual Studio (the 2005 free edition will probably suffice) or Codeblocks. You can also cross-compile for Windows using mingw from Codeblocks. Also read INSTALL.txt in the ODE source. You probably want the double precision build.

FTE expects ODE in the form of a shared library, named libode.so.1 for Linux (copy the lib from /usr/local into your game’s base folder and rename it) or ode_double.dll for Windows.

Note I’m having problems with Windows ODE under Wine atm.

Update: Spike informed me that he put a number of third party libraries (including ode_double.dll) up on triptohell. You might get lucky there. Look for a file called 3rdparty.zip.

You should verify that FTE found the library by checking the physics_ode_enabled cvar. It should be 1. If it is 0, it means the engine can’t find the library.

The QuakeC side

To spawn a simple physics enabled crate (as an example) in your game, you will need to write a spawn function as for any other mapper-placed object. You will need a model of a crate, or a simple model of a box. I trust that if you’re trying to use a physics library, you can model a box…

Let’s assume your box model is called models/crate.iqm (physics objects don’t need any bones.) Please make sure that your box model’s origin is at its center, not at the bottom. This because ODE will use the origin as the center of mass and it will look wrong if it’s not in the object’s center.

In your spawn function (name it misc_physics_crate or whatever) you want to include the following:

  • self.movetype = MOVETYPE_PHYSICS;
  • self.solid = SOLID_PHYSICS_BOX;
  • self.mass = 5;
  • self.bouncefactor = 0.5;
  • self.bouncestop = 0.1;
  • self.friction = 1;
  • self.model = “models/crate.iqm”;
  • precache_model (self.model);
  • setmodel (self, self.model);
  • setorigin (self, self.origin);
  • setsize (self, self.mins, self.maxs);
  • physics_enable (self, 1);

After compiling the code and placing the new object in a map, this should result in a pushable crate.The player basically acts as a moving wall in FTE by default, so you can push physics objects.

There is another collision type that you can use, SOLID_PHYSICS_SPHERE. This does what it sounds like. Spheres and boxes behave quite differently, for example they react in different ways to being affected by forces and spheres have a tendency to keep rolling forever (this can be minimized by damping – you should know what damping is after reading the ODE manual.)

Update: FTE now supports SOLID_PHYSICS_CYLINDER.

There is also SOLID_BSP for physics objects – I haven’t tried that yet, but Spike says it’ll make a BSP (bmodel) collide correctly. The other collision geoms (cylinder, trimesh etc) don’t work yet in FTE.

Mass is relevant only in relation to forces and the mass of other objects. Bouncefactor is how prone to bouncing the object is; 0 = no bounces, 1 = very bouncy. Bouncestop is the minimum impact velocity required to produce a bounce (multiply by sv_gravity, ie 800 in Quake). Friction is a multiplier for the contact mu… you did read the manual, yes? Setsize is a bit sensitive; you can tweak the object’s mins and maxs to make it collide more correctly (r_showbboxes 1 might help), but don’t make the box too tight or you will see NAN errors. For spheres, the bbox should always be a cube (x=y=z.) physics_enable() includes the object in the ODE physics simulation (note you need to call this again if the object auto-disabled.) Application of force also enables the object.

Improvements

A bunch of improvements to this basic physics object would be:

  • Make it activate only when the player is close
  • Make it respawn should it ever fall through the map
  • Enable physics only after droptofloor()
  • Add custom buoyancy, friction, and damping
  • Add touch and think functions to do all of the above

I’m not gonna detail this stuff; you should be able to deduce how to do this after you read the ODE manual and after you have searched fteextensions.qc for available physics-related functions and variables. I’m just gonna teach you one more thing:

Make it shootable!

Yup, we want to be able to have our own physics-enabled shooting range, right? Here’s how to do it:

  • Find the code where your weapon projectiles collide with the world
  • Add physics_addforce() to impart a force on any physics object.
  • e.g., physics_addforce(trace_ent, somevector * 10000, ‘0 0 0’);
  • where somevector is the direction and strength of the force.
  • Randomize things to make it seem more lifelike!

I have to warn you that high forces can shoot physics objects through walls and such. This is not quite solved yet. You may want to have physics objects respawn if they’re lost so the player doesn’t run out of toys. How you do that is up to you.

The engine side

ODE exposes not only collision geoms, forces, or joint functionality, but also a lot of controls to the software that uses it. In FTE (as well as Darkplaces), these controls are accessed via console variables.

Here is where it pays off to read the ODE manual. You need to know what linear/angular damping is, you need to know what contact mu and contact surface layer are, you need to know that ODE auto-disables physics objects, and so forth.

If you bring up the FTE console and type physics [TAB], you will be presented with A LOT of cvars. Those control the global ODE behaviour. Here are some good settings:

  • physics_ode_autodisable_time 5
  • physics_ode_world_damping_angular 0.025
  • physics_ode_world_damping_linear 0.025
  • physics_ode_world_damping_angular_treshold 0.05
  • physics_ode_world_damping_linear_treshold 0.05
  • physics_ode_contactsurfacelayer 0.001

There are many others and I cannot really hold your hand through all of them. RTFM!

Joints

I will explore joints such as hinges etc. at a later time. This is basically how you make cars or seesaws.


2 responses to “ODE physics in FTE

  • nil

    Thank you very much, was an excellent starting spot. (I somehow got really lost on the QuakeC part of it last time around). And yes RTFM is ofc expected with regards to ODE, it just fell behind the list of getting any indication ODE was working πŸ™‚

    Thanks a lot πŸ™‚

    • kneedeepinthedoomed

      ODE works perfectly well. It is an acceptable solution to provide the usual bouncing toys that we all love in games. It just requires reading a thick manual and understanding most of it (and the ability to google for fundamentals), as well as knowing how it translates to the game code. So it requires a large time investment, but it works fine.

      FTE just added support for cylinder geoms, too.

      And you’re welcome.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: