Ray cast car and networking

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

Ray cast car and networking

Postby Martin Piper » Tue Aug 02, 2011 1:24 am

I was trying the ray cast car tutorial and thought it would be helpful to include an example of using the class with a network.

This example does not use lock step physics, instead it is something a bit more like a distributed physics demonstration.
This type of simulation can be useful for fast interactive physics where you don't want clients to wait for lock step simulation updates from the server. It can also be useful when the server is on a platform with limited memory and cannot use lockstep or rollback simulations. It is similar to a method I used for the game Urban Chaos: Riot Response. Each server was another games console so to keep CPU and network use down the physics objects were distributed across each console. In the game each object used SLERP quaternion interpolation, but this demonstration uses Euler angles to keep the code simpler.

The win32 binary demonstration can be downloaded from http://www.rnlobby.com/Newton/NewtonPhysicsNetwork.zip
Extract and run NewtonPhysicsNetwork\tutorials\bin\Tutorial_203_RayCastConvexCastCar.exe
After each application is started it will try to find an existing session on the LAN and join it, or failing that it will create a new session. It then creates three cars and the physics simulation runs.
When one application is quit the physics objects controlled by that instance will be migrated to other instances in the session.
This means you have a peer to peer network session with physics objects that can migrate between peers.
This physics object migration is important because in the console game when a player was walking near to some physics objects the local games console would take ownership of those objects to enable the local player to see low latency physics updates. The network physics objects can be grouped into local simulation islands. While this demonstration doesn't have players running around it could easily be expanded to allow this at a later date since the network objects specifically allow user controlled migration.

The source code changes, which I'm releasing to the public domain for anyone to use, can be downloaded from http://www.rnlobby.com/Newton/newton-dy ... hanges.zip
The original version of Newton used was 2.33, although I expect with some tweaks the same code will work with future versions as well.
Most of the code changes are in applications\tutorials\Tutorial_203_RayCastConvexCastCar
Each physics object replicates the following data:
    Position X,Y,Z
    Rotation X,Y,Z
    The steering angle
    Each wheel turn angle
    Each wheel suspension

The update policy for each variable is defined in the _RO_NetworkRayCastCar.rol which is compiled by a custom compilation rule (RNROLCompiler.rules) and generates the network object interface class _RO_NetworkRayCastCar. The main class for the network object is in NetworkRayCastCar.h and this inherits from the ROL generated class.

Since each variable can be updated by their own policy then the expected accuracy of each value can be tweaked to best suit the range of values from the physics simulation. For example the position updates can use 16 bit packet floating point deltas. The rotations are clamped to a range -PI to PI and automatically wrap around. The wheel spin, suspension and steering also has similar limits. These limits are defined by the ROL file and require no extra code from the user since ReplicaNet handles all of these updates types for you.
In the network simulation is also a very simple camera represented by the _RO_NetworkCamera.rol file. This deliberately uses a low resolution and very cheap network bandwidth model to update each application's camera position.
What this means is that all the physics related variables will be updated in a way that conserves bandwidth depending on how far the camera is to a physics object. This is accomplished by implementing the CalculateDistanceToObject callback for NetworkRayCastCar.

When locally creating a physics object a corresponding network object is created.

In the tutorial code TireTransformCallback function all it needs to do is first check if the physics object has a linked network object. If it does and the network physics object is a master (tested by networkCar->IsMaster() ) meaning it is locally controlled then it will update physics values to the network object. If it is remotely controlled the physics code will update values from the network. This means any network physics object just appear to magically work.

When a network object is created in the client application instance there will be a PostObjectCreate callback. So creating network controlled physics objects is a simple matter of implementing NetworkRayCastCar::PostObjectCreate and creating on demand graphics and Newton bodies for that object.

There are some other code changes not immediately related to networking. For example OpenGLUtil.cpp texture loading has been improved to use a cache. This means network objects can be created from the separate network thread without blocking the main thread too much.

A demonstration of peer to peer networked physics with object migration between peers. There isn't that much extra code added to the tutorial to accomplish this. All of the complex physics object value updates and bandwidth saving is handled by the ReplicaNet library.

If someone has a more interactive vehicle or physics object demonstration or even game they want to be made network capable then you can send me a PM or email and I'll try to help.
Martin Piper
Posts: 1
Joined: Tue Aug 02, 2011 12:23 am

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 3 guests