Racer How To - Using multiple computers

Racer How-To: using multiple computers

Some options using multiple computers are available.

Dolphinity Organiser - free planning, project management and organizing software for all your action lists

Multiview is only available to licensed users of Racer. Contact Cruden for more information.

Racer doesn't only run by itself on a single computer; you can use multiple computers in a (LAN) network for some nifty features. Some of these features are available under license only though!

For more information on frame-locking several PC's to each other, check this page.

Although not required, it can help to think about your network layout before hooking up other computers. Here is the system we use:

An operator computer, mostly has the IP address 10.1.90.10.
A simulator, consisting of master/center computer, left and right views, spectator. Each simulator has 10 IP addresses reserved, and the last digit specifies the type of computer. 1=master, 2=left, 3=right, 4=spectator. So if you have the master set to 10.1.90.11, the left machine would get 10.1.90.12, the right 10.1.90.13 and the spectator would be 10.1.90.14.

This system becomes extremely useful when you need to combine a multitude of computer to setup a Racer simulation park. The 1st simulator IP's would start at 11, the 2nd simulator at 21 etc.

To setup an extra computer watching the race, the following needs to be done:

Clone the Racer directory to the spectator machine (c:\sims\racer)
Modify the racer.ini to make this a spectator (see below)
Run Racer on the main (master) machine

To go from a normal racer.ini to a spectator version, follow these guidelines:

Use a control set that doesn't really use any controllers. To do this, copy the regular data/controls/default.ini to data/controls/slave.ini and clear out all controllers from file (or disable all of them). You may just want to put an empty 'slave.ini' file in data/controls.
In racer.ini, set ini.controls to 'slave.ini' (without the quotes)
Set slaves.auto_start and slaves.auto_stop to 0 (if they aren't already)
Set multiplayer.server to the IP address of the master machine.
Set multiplayer.audience to 1 (indicating that this machine will only view the race, and not bring any cars into the race).
Set autojoin.slave to 1. This will let the machine try to connect to the master machine when in the menu.
For versions <0.8, set autojoin.master to the IP address of the master machine. Newer versions will just use multiplayer.server, since that is always the same.
Optionally set autojoin.delay to the number milliseconds that you want the spectator machine to wait before starting a race. Use this value to avoid timeouts when the spectator tries to connect to the master.

Multiview is a feature where you add extra views to create left & right views. An alternative is to use 1 computer where a graphics card sends out 3 signals, but multiview is based on using multiple computers for performance.

The main computer is called the master. This master computer runs Racer, does all the physics, controls etc. The side computers are simpler slaves, running the same racer.exe but using different configuration files (racer.ini variants). For simplicity, you can copy the entire Racer directory to the side computers, and use racer_l.ini and racer_r.ini files (these filenames are not hardcoded, they're just common practice) to overrule any settings defined in the regular racer.ini.

On the multiview computer, make a racer_l.ini file (in the installation directory, i.e. c:\sims\racer) and put these settings in it:

multiview
{
  ; Multiple PC rendering
  ; Are we a slave computer?
  slave=1
  ; Where is the master?
  master=+1
  port=25010
  ; Logical offset with respect to master computer's view
  offset_x=-1
  offset_y=0
  ; Track view?
  track=0
  ; Use time of day send/receive?
  use_tod=0
  ; Asym persp
  aspect_factor=3.0
  angle_factor=0
  ; Offset wrt center car
  project_left=0
  project_right=0.33
}

Some information regarding the settings:

slave - if set to 1, racer.exe will behave as a multiview slave computer.
master - this is the IP address of the master (center) computer. You can fill in an IP address here like '10.1.90.10' (omit the quotes) but at Cruden we often have several simulators hooked up on the same network, so you can also use a relative IP address. Here, the +1 stands for 'host IP adress, modulo 10, add 1. If you've read the Network Layout section, this makes more sense. For a left computer having IP 10.1.90.12, the '+1' would convert to 10.1.90.11, which is normally the master's IP address. Again, you can just fill in any IP address, but when having multiple simulators, this relative IP trick keeps software loads exactly the same on all computers, which is much easier to maintain.
port - the UDP port. Keep at 25010.
offset_x/y - the logical offset of this computer with respect to the center screen. So for the left screen, this would be -1. For the right screen, use 1. This is used to calculate a rotation angle to rotate the master screen's camera (using it's FOV - field of view).
track - if set to 1, this forces a trackcam view. Experimental.
use_tod - if set to 1, this enables receiving of Time Of Day from the master computer. This is only really useful if you use dynamic time-of-day. Often though, tracks will want to provide their own lighting settings and time of day would overrule any manual lighting settings. Leaving it to 0 is recommended.
aspect_factor - the multiview image is rendered as if the center screen image is extended sideways. You can see the wide view rendered by 3 computers as being a very wide virtual view. The left view here would just render the same view as the center one if not adjusted. We make a virtual frustum that is aspect_factor times as wide as the normal camera, and then extract the leftmost part of that frustum using project_left and project_right (normalized values). A useful Excel sheet can be downloaded here to help with calculating aspect factors and project_left/_right below. The example above does a quick initial estimation, using 3.0 for '3 screens wide' and cuts out the left part of the view frustum using 0..0.33 (1/3). However, real monitors have borders, and that's where the XLS sheet comes in. That allows you to fill in distances between the screens, and it will then calculate a better aspect for you, to make sure that the rendered view continues neatly on the side screens, instead of cutting lines, assuming the screens are 0 cm apart.
angle_factor - the camera will be rotated using the master's camera view by the 'offset' value. This is not often used, so you can set angle_factor to 0 to reduce this rotation to 0. Use 1 to fully rotate the view, although in that case you'd just use aspect_factor=1 and set project_left to 0, and project_right to 1.
angle_offset - added to the angle rotation (the unit is degrees). Normally, the use of angle_factor and angle_offset are mutually exclusive; either you use angle_factor to let the camera rotation be dependent on the master PC's FOV (field of view). However, in some situations where the FOV is hard set (usually in projector situations) it is easier to set angle_factor to 0 and use angle_offset to specify a rotation directly.
camera_flags - (v0.8.40+) This integer mask value lets you overrule the (car) camera flags directly for this multiview slave. flags are OR-ed together; 64=INCAR (cockpit model rendered), 128=NOCAR (no car model), 2048=NoHeadTracking. Use camera_flags=0 to display the full car. This is useful for example if you show only the wheels in the front view (i.e. you turn off the car model, or use the cockpit model) and use a multiview slave to render mirror images. In that case, you probably want camera_flags set to 0 to render the car model.
camera_offset - 3 floats (i.e. camera_offset=0.5 0 0) to offset the camera relative to the car. This allows you to move the camera position. Useful also for mirror views where you want to offset the camera position (and use an angle_offset close to 180 [degrees]).
camera_headtracking - a boolean (0 or 1) that indicates whether you want this slave to adjust its camera for headtracking. Headtracking is performed by the master PC, and independently sent on the the multiview slaves, so these can decide whether to include the effect or not. For example, for projector setups, all the multiview slaves involved in rendering the picture for the projection surface will use camera_headtracking=1 to match the master picture. Any PC's rendering mirror views will not however (camera_headtracking=0), since they don't move along with the head.
fov - a floating point value that lets you overrule the field of view. Useful for projection setups or mirror slaves. Will overrule the camera's FOV. The default is fov=0, which will just use the original FOV.
project_left - the left projection limit of the view frustum to render. Normalized, so use a value between 0 and 1.
project_right - the right projection limit of the view frustum. Use around 0.33 for left screens, around 0.67 for the right screen. Values here may need to be modified to account for the monitor borders between the monitor internals.
camera_send_count - defaulting to 1, this determines the amount of camera update packets. More than 1 may be useful to avoid packet drops to missed frames, which is a problem when synchronizing multiple graphics cards (like with nVidia Quadro cards).

Running the left screen is done then by 'racer.exe -f racer_l.ini'. This makes sure any values from racer_l.ini overrule those in racer.ini, but the values from racer.ini are still used for any unspecified keys.

In the same way you create racer_r.ini for the right computer, using project_left=0.67 and project_right=1.0 (or use the values calculated in the Excel sheet for more accurate values).

Racer currently only supports 1 camera type that is processed correctly for side screens. If the side screens show a quite misaligned view, it may be that you need to modify the car's first camera (in data/cars/<carname>/car.ini, camera0 tree). An example is shown below. You can freely modify FOV, but the src/dst settings indicate an SMD (Spring/Mass/Damper) camera.

camera0
{
  offset
  {
    x=0.34
    y=0.65
    z=0.42
  }
  offset_to
  {
    ; Look at offset
    x=0.34
    y=0.18
    z=10.25
  }
  angle
  {
    x=0.000000
    y=0.000000
    z=0.000000
  }
  ; Field of view
  fov=55
  ; Type of model to use; 0=outside, 1=inside, 2=none
  model=0
  wheels=0
  view=0
  name=incar
  ; Source/target inertia
  src
  {
    mass=1.0
    k=1000
    damping=50
    maxdist=0.2
  }
  dst
  {
    mass=1.0
    k=150
    damping=20
    maxdist=0.2
  }
}

Make sure to synchronize the car on all computers.

With multiview, you have the option of rendering a mirror view for a 2nd monitor. The idea is to cut the screen in half and to use the right half for the mirror. The mirror is a 180 rotated view plus a small degree to account for rotation of the mirrors. To do this, modify racer.ini's multiview section as follows for versions upto v0.8.6:

Set multiview.render_mirror to 1. This automatically divides rendering into 2 halfs; on the left the normal view, on the right the mirrored view. The mirrored part uses the mirror's settings, like visibility and FOV.
Set resolution.width to twice the normal size. You probably want the video card to render 2 monitors using a horizontal desktop span. Also, to keep the aspect of menu's ok, set resolution.monitors to 2.
You probably need to set resolution.render_aspect to adjust for the automatic aspect calculation. For example, for a 1024x768 normal view, whereas resolution is now set to 2048x768, use 1.3333 to bring back rendering to a 1024x768 aspect.
v0.8.5 requires a hack to get all this working when using FBO's (renderer.motion_blur.method=4): the rendered normal view is scaled badly. Add renderer.motion_blur.view_width_scale=4 to fix this (for the slave screen). Hopefully a more elegant approach will be developed later.

Version 0.8.7 improves this somewhat (the FBO was twice as big as it needed to be, resulting in wasted bandwdth). Do this instead of the above:

Set multiview.render_mirror to 1. This automatically divides rendering into 2 halfs; on the left the normal view, on the right the mirrored view. The mirrored part uses the mirror's settings, like visibility and FOV.
Set resolution.width to twice the normal size. You probably want the video card to render 2 monitors using a horizontal desktop span. Also, to keep the aspect of menu's ok, set resolution.monitors to 2.
You probably need to set resolution.render_aspect to adjust for the automatic aspect calculation. For example, for a 1024x768 normal view, whereas resolution is now set to 2048x768, use 1.3333 to bring back rendering to a 1024x768 aspect.
Bring the FBO's size back to the normal size by setting renderer.motion_blur.fbo_width to half the resolution.width. Also set fbo_height to the height of the window. For example, if you use a 2048x768 resolution, just use fbo_width=1024 and fbo_height=768.
v0.8.7 still requires a hack to get all this working when using FBO's (renderer.motion_blur.method=4): the rendered normal view is scaled badly. Add renderer.motion_blur.view_width_scale=2 to fix this (for the slave screen; it was 4 for versions below v0.8.7). Hopefully a more elegant approach will be developed later.

Stereo multiview is available since v0.8.7. Note that assumes separate PC's to generate the image for each eye. A combined dual-eye solution on one PC will be available in the future.

Add eye separation with multiview.eye_offset (in meters). Use a positive value for the left eye, negative for the right eye (around 0.03 and -0.03). Also set the focus distance using multiview.focus_distance (around 150 for example, this is in meters and represents the eye's distance at which it tries to focus).

Testing can be done with multiview.stereo_test. If set to 1, it will turn the separation on and off every half-second or so (mostly usable for internal development).

If you use the multiview computers to drive projectors, you need 2 more things: edge blending and distortion (click on the corresponding words for more information). You need distortion since the projections can normally not be overlaid without transforming the image. Hardware solutions exist, but with Cg shaders, distortion in fragment shaders is now possible. Racer uses a pixel-accurate map, controlled by splines which can easily be edited to quickly get a visual match.

Edge blending is needed to smoothly cross over from one projected image to the next. Just placing two projections exactly next to eachother is virtually impossible, so a combination of overlap and blending the one image in the other helps to smooth out slightly positional imperfections. Blending is not just a matter of linearly fading (to black), but requires a few parameters (p and gamma) since the properties of light are not linear: simply mixing 2 linearly edge blending images will result in a black dip at the middle. More information can be found in the documentation links presented at the top of this paragraph.

Dolphinity Organiser - free planning, project management and organizing software for all your action lists

(last updated March 28, 2013 )