Wii Remote (aka Wiimote)

At a price of only 40 Euros, the Wii Remote offers a host of features:

A three-axis accelerometer (which may also be used to sense tilt if held stationary; measuring the position with an accelerometer is no good idea as that would involve a double integration over noisy data)
A 3D position sensor based on infrared light beacons
A number of buttons
A rumble motor
A speaker
Four LEDs
Wireless connection via BlueTooth
Extendability, for instance with the Nunchuk

The Wii Remote masquerades as an almost-standard BlueTooth HCI device. Not every BlueTooth protocol stack will work with it. BlueTooth allows you to use several Wii Remotes with the same computer (which requires that the API you're using can enumerate all those different copies).

A basic program to test the setup is WiinRemote.

There are different APIs for the WiiRemote so that you do not have to talk to the BlueTooth protocol stack on your own. I'll demonstrate wiiuse (the source example of which seem to be broken in some respects; you can obtain a corrected version from me) for Win32 and the Wiimote Lib (docs) for .NET.

Physics Engines

The job of a physics engine is to compute the motion of rigid bodies and possibly also soft bodies due to forces and collisions. This may be realized in software or (more or less partially) in hardware such as the PhysX board or a graphics card. A physics engine is not concerned at all with 3D rendering, apart from defining the positions and orientations of the objects. Some demos with Newton Playground and the physics simulator of Maxon Cinema 4D.

The basic equations of Newton's dynamics say:

Velocity is the change of position: v = dx/dt.
Acceleration is the change of velocity: a = dv/dt.
Force is mass times acceleration: F = ma.
There are similar, but uglier equations for the rotational components of the motion (angular velocity, angular acceleration, torque, inertia tensor).
If the positions, orientations, (linear) velocities and angular velocities are known at some single point in time, the motion is determined at any time throughout history and future.

The science of physics treats collisions through forces, which is a bad idea in computations because a collision causes sudden high forces. Thus, one typically uses two interleaved processes in a physics engine:

Advance velocity and acceleration under continuous forces such as gravity or springs
Detect and resolve collisions

The motion of rigid objects is fully computable from the position of their center of mass, their mass and their inertia tensor. Thus for rigid objects, the geometrical complexity comes only into play when collisions occur and have to be resolved. To save time and memory, one typically uses simplified placeholder geometry to deal with the collisions. For soft objects, however, the computational load explodes.

A typical physics engine requires control over the positions and orientations of the 3D objects. These have to somehow be “registered” with the engine. Then, you regularly call a function of the physics engine that advances the time, that is: that computes what the world looks like a given number of milliseconds after the current state. This number of milliseconds should be the actual time since the previous call, which requires you to use a high-precision timer. The standard time functions may only be precise up to 1/60 of a second, depending on the operating system.

A closer look at the free cross-platform physics engine Newton.