Racer
How-To: using multiple computers
| Some
options using multiple computers are available. |
|
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!
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:
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.
- 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.
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.
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.
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.
(last
updated
July 22, 2010
)