1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

RBR long track making guide

Discussion in 'Bob's Track Builder' started by Brendon Pywell, Apr 22, 2009.

  1. Brendon Pywell

    Brendon Pywell
    Bob's Track Builder

    This is a guide to building long rally tracks using BTB v0.7 or later.

    After recently spending several days creating my first really really long rally track, I though it would be helpful to others to learn from my experience.

    Here's how the first part of the track looks after 3 long days of creation ...

    BTB is aiming to provide an RBR experience that is better than the original. The format we use allows us (eventually) to do much more than if we’d stuck with the original RBR format. Internally we use technology that allows several hundred thousand objects to line a long stage. The creation of that environment is easier with BTB by the use of the Object planting tools and String Objects. Everything created by these tools is efficiently loaded and displayed using the RBR RX plugin coded by black f.

    Having completed this stage, as much as I intend to for now, there are some things I would do differently had I to create it all again. So here are the steps I will take in my next track.

    The Track

    • Create a basic path using Nodes spaced 300-400 meters apart in the top view to create the whole track. (Note: For speed reasons I have recommended that you use multiple tracks, and I still do. I intend to create a tool to split tracks but that might be a while).
    • Adjust the height of one Node, then select XXX number of nodes nearby and use the Smooth Nodes by height popup menu to smooth out the change in height between those nodes. Repeat this step until you have a good height variation.
    • Add more Nodes by selecting and splitting track sections. Adjust the direction and height of these nodes. This will take some time. Leave some sections long and straight, others windy and hilly to give variety.
    • Use the surface modifier to add variety to the track’s cross-section. This can add bumps ditches and camber to the road. Initially set the Panel Size to 20m so that recalculation is performed quickly. Afterwards you can set it to lower values for more track detail. I steer clear of the width and camber tools.
    • Use the terrain tool to create 20 meters of terrain either side of your track. Use the randomness and slope it slightly upwards. This will act as a safety barrier when you test your track.
    • Place a large object such as house or large tree every 3 kms along your track. This helps to identify different parts of your track when editing it later.
    • Export to RBR and drive it. Then remove the terrain and go back to step 3 and adjust until you have a track that drives well. (I could have spent more time doing that myself .. but, well this was just a demo).
    It is important to get the above steps done and your track driving well before continuing further. It is much harder to go back from here and re-edit the track and terrain.

    You can move the start position to help test the track in smaller pieces.


    • Add/edit your own textures to the scenery. Some people have great skill in this area (not me) and it shows in the result. You can edit the textures in the RBR track folder and press F2 to see their immediate impact. The track cross section can be made to have the center part as road with the edges being grass or dirt.
    • Each texture file has a corresponding *.rbr file that provides the physical characteristics of the surface determining the sound and grip levels. These can be edited using the RBR_MaterialEditor in the Support\RBR\MaterialEditor folder. See the BTB manual for more help (press F1). I wish I had more time to devote to this myself as they play a very important role in obtaining a good feeling for your roads.

    • Add around 20m of terrain either side of the track. The Quick Add tool of BTB is designed to generate the driveable terrain very quickly. It is important not to try and overuse this tool to cover everything as you should only be trying to make part of the terrain a driveable surface. Anything that is going to be out of bounds should be marked as non-collideable.
    • Use the Pull tool to enlarge the boundary of your terrain for the entire track. This is best done by selecting the outer edge of terrain anchors and dragging it outwards. I set Reduce to 4 to dramatically lower the polygon count.
    • Section, by section highlight the polygons created in step 11 and Split them into a new Terrain Area. I name this “Outer” and keep it as one big terrain area to begin with. Later you could divide it into smaller areas so that the LOD ability helps increase frame rates.
    • Use the Raise/Lower and Flatten tools to alter the terrain in the 3d view. Limit the visible terrain to just a few Terrain areas Left and Right of the road and slowly work your way along it to add variety.
    • You can’t resist, so drive it again now. Go back to 13 until you are happy or fed up. ;)
    Objects and SObjects

    If you do go back to terrain editing after adding BObjects and SObjects, be sure to turn off these items to speed up recalculations of your track. Note when you switch back to editing BObjects or SObjects there will be a delay as they get recalculated to sit on the terrain.

    • Depending on the type of track you are creating will determine what objects you put in and how densely it will be populated. This is where your artistic and aesthetic talents are needed.
    • Keep Objects logically grouped by type, merge multiple groups of the same type of Object into one to make management easier.
    • Add SObjects in order from the start of the track to the end as this makes finding them easier later on.
    • Set LOD and collision values to fine tune the track.
    • Use the latest Object Add to Track tool for relatively rapid planting of the entire track. Test by click-dragging on the track first in order to get the density right (press the Delete key afterwards to remove). I will be making this faster in a future update.
    • Test many times and repeat until happy.
    OK, that’s it from me for now. My eyes are starting to blink and stay closed for longer than they stay open.
  2. Thanks Brendron for your "long RBR stage" guide :dance2:
  3. This is a long track Im working on it for a while [ame]http://www.youtube.com/watch?v=wyvFSNZ8qVM[/ame]
    Im still working on it............
  4. Huhu ... It can be faster? :party2:
  5. The idea is tunning shocks absorvers, test gears and driving fast just for pleasure.
    (in fact, in real world, this SS was a sort of relax for us)
  6. Wow. I'm a big RBR fan, but I never thought I'd see the day when it would be possible for people to easily create stages of the same quality as original RBR tracks. You are doing every RBR fan a HUGE favor Brendon, by adding a greater variety to the (at the moment) limited stages that RBR has to offer.

    I'm sure I speak for everyone when I say, great work! Before, I didn't believe that the standard of stage that could be created was worth the effort. I do now! Hell, I might even give an RBR stage a go myself, now that I've seen the quality which is achievable.

    Thank you again.

  7. i´m a bit confused about this point.... are you talking about set 20 m. in the surface length panel initially? it comes at 5 m by default... we need to change that?

  8. Brendon Pywell

    Brendon Pywell
    Bob's Track Builder

    You don't need to, but doing so will speed up your track changes because there are far less points to calculate.
  9. so if we do that... BTB works faster, got it.

    change this value is better at the end of the process?

    or we need to change that before start to generate the terrain area?

    jharro shows a grid model near to 2x2 meters in the surface length, for RBR collide model, and wixi used to show pics from theirs proyects and they seems to follow that 2x2 grid.

    the first thing i do when i start a new proyect is cut the track and change the surface length to 2/3 meters. to generate all terrain area in realtioship with this value.

    i´m noob and i want to learn how to, i´m not trying to say what you have to do.

    before that post i think we need to build an "organized" grid to get better preformance in RBR, that is why i ask about set 20 m.
  10. Brendon Pywell

    Brendon Pywell
    Bob's Track Builder

    Change it to 20m for editing the shape of the road, both in terms of Node placement and shaping corners / road camber.

    Keep it at 20m when doing the temporary terrain used only for when testing the flow of the road in RBR.

    Switch it back to a smaller amount (Country Roads is 4m, tarmac roads probably need less) before doing the terrain for real.

    Practice on smaller practice roads to begin with before undertaking something lengthy. ;)
  11. DMz


    cheers brendon, thanks for the tips looks like im going to have to redo all my veg now on my tracks v7 veg looks great! What a difference a bunch of grass makes to the verges. Ive been doing a bit more verge grass but its so boring laying it down 1 line at a time on a 30kay track. Looks like v7 veg planting rocks cant wait to get my licence now!

    Getting a google earth background in is pretty much my 2nd step now after importing and cleaning up the track made with the worth its weight in gold google earth path import, it really helps me with terrain you can see what the go is. I have also started using temporary terrain map from google maps imported as a background so you can see the topo of your area. I know you can use sketchup terrain maps but I really enjoy pulliing node around, Feel a bit like "LET THERE BE LAND!"

    Side Roads: Ive been using the trusty wall tool to create side roads I find it quicker to work with with a bit of practice they can transition nicely, rather than trying to create additional side roads as proper tracks.... also less pollies which means smaller file sizes and memory usage. Just flatten out the wall, material it to look like your track, section it up with control clicks, and adjust the height of the first node to match the track you are linking to to it goes below the yellow line and it will hook up with a bit of practice... You can pull a side section node (for want of a better term) of that first node up or down to angle the start of the wall track to match the angle of your main tracks road shoulder. Then adjust the position of the nodes so it sits nicely and there is no bump at the start. Having flat side surfaces with no randomness on the main track at the point where you want a side road to intersect is also advisable.

    Those fence string objects are also very large in file size even for smallish fence strings once gmt'ed, obviously they are fully 3d now which looks great but anyway Ive been sticking with the old wall tool for really long fences.

    It would be great to be able to scale and rotate sobjects like you can with normal objects, to get some more randomness in the fence heights etc. Excuse my blindness if this already exists.... too many hours staring at pollies!

    Would also be great to be able to change the z position of both sobjects and objects in btb...

    cheers again for your great tool.

    Drew (DMz)
  12. yea, as brendon says, when you first lay out your track, set the panel length to a larger number so that you can move around in BTB fast .. also, as he says, make a temporary terrain with this larger panel size so you can test without falling off the road.

    once you have your track layout nice and neat, start working on cambers and cross sections (ruts and crown and superelevation) once you have the road surface the way you want it, delete the temp terrain, shorten your panel lengths to final values you want - then you are ready to start to generate terrain from the shorter more detailed panel length - and get that terrain finalized before you add objects absolutely last.
  13. one question, Is there a performance penalty in RBR if you have variable panel lengths?

    like 1m or less in a detailed rutted corner and 5m on smooth straights? or does the polygon reduction of the less detailed bits overcome the FPS hit of variable panel length. (thinking physics calculations are affected by panel size - are they?)

    I remember testing way back many versions ago that the MAT does not scale with the texture scale - its independant of looks in otherwords, ie rough gravel mat will always feel the same regardless of the scale of the texture.

    I guess what I'm trying to ask is - is there a relation between the physics(rbr-mat) and the panel size? and how much does variability in panel length effect RBR framerate vs even panel length over the whole track?
  14. MAT does scale with the UVs, not with textures(ie. texture size doesn't matter but the UVs do).

    the MAT maps are for physics exactly what textures are for graphics. every ground poly has UVs for each vertex, 2 matMap ids and several other per-vertex values, like blending coefficients, so is safe to say there is a 1/1 correlation between visuals and physics, better yet, you can imagine the matmaps working exactly like a 2-diffuse blended material.

    curently we use only one mat map per poly and clone it internally but we could add support for a second map, this should go hand in hand with blended materials on road meshes.

    what the plugin does is it takes each ground mesh (collisionModel = 0) and extracts the vertex positions, the first UV channel and the first diffuse texture name for each poly. the texture name is used to identify the matMap from mat.ini.

    the issue with pannel space is not one of performance(if you have a good gfx card that is) but physics accuracy.
    imagine you have 2 poly, one 2 meters long and the other 5, both with the same texture(and matMap).
    you can use bigger textures to get better visuals the matMap stays the same (16x16) so what happens is with 2 meters long poly you will have a patch of phisical material of length (2 / 16) = 12.5 cm - a value comparable with the size of contact area between tyre and ground while the 5m one will give ~30cm
    which can result in bumps or loose of grip depending on speed of the car and framerate.

    a while back i've noticed the phiscs are updated aprox 14 times per frame so taking this in account and the framerate and the car speed one can estimate a proper polygon size(as in comparation) with RBR's averages.

    in the end the pannel size affects both simulation detail and framerate but since these 2 are already interrelated it would take some tests to find what's best for certain track and material.

    the pics below shows the physics materials as they are mapped on school yard and school track, you can notice the blending:
  15. thanks very much, I think I understand what is going on a bit better now.

    as you may know I'm graphics card limited at least on long tracks ATM.

    my comment on the rough gravel test I did ages and ages ago is that you can make a rough gravel texture look like fine gravel by adjusting the scale, but that didn't appear to change the properties of the material - so if the mat says there are 3" bumps every 1', if you change the texture so its replicated twice over the same distance (looks 2x finer) there will still be 3" bumps every 1'.(on same panel size-or any panel size) - in other words it will never be 1.5" bumps every 6" if you double the texture, the MAT is what it is, just updated more often at shorter panel lengths.

    I Think that you are confirming this - what is changing is that the Frequency of physics updates is changing with the panel length, and not the scale of the texture on that panel.
  16. to be honest the last time i've had a look at the code rbr is using to look up the matMaps was years ago. i will try to find it and see if the UVs are clamped to 0.0 - 1.0 interval or are wraped(tilled) like in gfx so hold on the definitive conclusions for a moment, who knows, maybe i'm totally wrong and indeed the physics also wrap the UVs but if not i belive we may hack that. :)

    edit: yeah, it's not gonna happen, not soon atleast, and the reason is both u and v coords for UVs for collisions are stored in the same byte, that means the range is 0 - 15 and since the matMaps are already 16x16 wide it means we don't have the space to use wrapping.:( oh well, atleast this thing worths exploring a bit more.