1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
Dismiss Notice
Like RaceDepartment on Facebook.

Bobs Track Builder Export Issue

Discussion in 'Off Topic' started by PTSoftCorp, Sep 17, 2012.

  1. Hello,
    I have a problem exporting on my computer and I was wondering if anyone could export for me. I am trying to export to rfactor on windows 7. Here is the file.
     
  2. Hi,

    I'm running XP, and it doesn't export for me aswell. I've tried deleting the terrain, and tree's and unticking the individual files like cam etc so far, but still doesn't export. Run out of time as I've gotta go to work.
     
  3. Both jpgs in your pits xpack are wrong dimensions. All textures have to in powers of two: 32,64,128,256,512,1024,2048 etc. Your jpgs are 548x357 pixels, convert them to 512x256 or 512x512 DDS.

    Use DDS format when ever possible, it's compression is fully supported by the GPU, it's fast and it doesn't suffer from the same faults: DDS won't diffuse the edges but keep them untouched. JPG compress the whole image so tiled patterns have lines in them (unless the opposite edge has the exact same color value, ie single color edges..). Also you can get the really important alpha layer in DDS. If you have to use something other than DDS, use PNG format. It's a bitmap, supports alpha layer, fast to process but are slightly larger in filesize than JPGs. They all reserve the same memory print while they are been processed by the GPU.

    EDIT: Forgot, te most important feature of DDS: mipmaps.. They are smaller versions of the original image so the game don't have to scale 1024x1024 textures that appear on screen 5 km away, using only small number of pixels. Each step smaller is called level and we can use the mipmap bias to control what level mipmap is used at what distance. For ex mipmap level 1 from 1024x1024 texture is 512x512, level 2 is 256x256, level 3 = 128x128 and so on. Now you see why we need to use powers of two, it's fast to scale up and down, doubling and halving is very fast to do in binary systems. Mipmap bias controls ahow much "oversized" texture size we are using. For ex, you would only need 256x256 size texture (it doesn't tak more than that area from your screen..) but it looks kind a fuzzy. You can tell the game to use one mipmap level higher resolution (512x512), resulting in higher quality texture projection but more strain on the GPU. gMotor2 has a tendency of using too low mipmap levels at default, that's why you see most textures to use mipmap bias of -2 or more. Roads are difficult, they can be at the same time very close to viewport and extend quite a long way in the distance. We need to use even more negative bias to ensure we get the highest quality. You can use positive mipmap biasses but that is basically just blurred texture then.. If you need to use positive bias, make the changes in your texture instead, make it smaller and blur it in photoshop

    wow, that edit was long...

    TL:DR: Don't use JPGs, use DDS.

    EDIT: The conflicting texture seems to be the pitroad. Remember to change "LeftsidePits = 0" to 1 in your AIW since your pits are on the left side. You need to edit it with notepad.
     
  4. I took a look at the project to see future pitfalls. First thing came to mind, decrease road panel length in the turns. Too long panels make the road look jagged, elevation changes become angular, sharp. Smaller panel lengths make the road smooth but don't use short panels for the entirety of the road, you'll end up with a huge road mesh.

    I'll make some changes to the project, rename it and upload it back to you... Look at it and apply it to your project at your own disgression.
     
  5. Here you go: https://dl.dropbox.com/u/84727521/WityTestCircuitEdit.zip

    What i did:
    - Splitted new sections to the road using material cross-section. It was 10km long, the preferred length of one section is 300-500m, about the size what you can see from the car. With only one huge mesh, the game has to load it all in the memory at all times, with smaller sections, the game can load only the parts of the track shown on screen.

    - Decreased panel lengths. I did this only from start to the end of that long straight. Check the panel lengths in different sections.. You need to wiggle the control arms, move nodes etc, there were un-naturally tight and too big elevation change at the same time, there's a limit of how radical changes you can do to a track in both gameplay and technical issues. There's no rule, it's case by case. But for sure dropping 2m in a span of 5m while turning 200 degrees does not fit to any road suitable for automobiles.

    - Did some example of how to merge terrain anchors. Since you're still doing the basic layout work it's not yet necessary but it is before you can make the terrain around pits permanent. After you are satisfied with the start/pit area, you should merge the two tracks. The procedure for this is not intuitive, it's a workaround, BTB can't merge roads the right way.. There are tutorials for that procedure in BTB forum, this is general modding forum.. You'll find more help there.

    I also fixed the XPack. Following things were done:
    - ground.jpg converted to ground.dds (DXT1, 6 mipmaps)
    - the other jpg -> the same thing
    - opened it in xpacker, loaded the new dds, replaced the jpg with them and deleted the unused textures.

    If you don't need two identical textures in two different materials, you can merge them too in XPacker but it can wait until later stage. Try to avoid replacing textures used in XPacks in venue materials, that'll make the final phases, optimizing textures and materials, really laborious. If you just want to introduce new textures, you can either make an XPack or use the venue material editor in BTB. Copy material and replace it's textures using some of the default materials. Custom XPacks should never have their textures edited in venue material, it affects the final phase (you can't merge materials in XPacker if they are edited in venue material editor, you'll get the wonderful error message that prevents you from opening your project, possibly making the whole project unusable...)

    Make backups.. Make lots and lots of backups. Everytime you feel like you've accomplished a task that you don't want to repeat again, save the project. If you've just done 4 hours of terrain editing doing huge changes, make a backup... Save the project with different name each day, before you start you daily work, create a backup. Keep at least one version from early stages and one from yesterday. I'll keep a lot of them, i'll use following format when keeping track of versions: trackname001, trackname002 and so on. It's easy to rollback to earlier working version after the inevitable crash or design error.
     
  6. Thank You Guys. I will do what you said. Thanks a lot.
     
  7. Am I supposed to get 1847 items in the exported track? Am I supposed to do anything further than exporting it?

    Thank You
    PTSoftCorp
     
  8. Sounds about right. You have a lot of trees there, they arranged in to groups (5-6 trees per group), you get one object from each group. There's sobjects, road meshes, terrain, all those are actually just objects too. Textures count too, the finished track may have thousands of individual files. You will combine them all to one MAS file later but it works prefectly fine without it. I'm EVO user so i have very little knowledge of rFactor.

    Your track is long, wouldn't recommend doing such a huge track at this stage of learning, BTB starts to get reaaaaly slow right about 10km mark. AIW edits take few seconds per node, zooming and moving camera around the track starts to get slow. BTB uses openGL graphic acceleration, it also doesn't use culling (citation needed..), it projects all textures as double-sided etc. Your project will be considerably heavier in BTB than in game. Luckily it's quite a small area so you won't get into troubles due to long distances. But working becomes very slow with huge tracks, you need to have everything planned before you start building the thing.

    What i would do: keep this track in backburner and do a short test track where to learn new techniques. When i was learning i did hundreds of temporary small tracks, also i test new XPacks in a new very short test track, ~1km long. I started of doing a complete release as my first project but the way the learning works in BTB, i made so much huge elemantary mistakes early on that were pain in the butt to fix later. Needless to say, that track never worked fully, it was out of scale. This is very easy mistake, our last release, Cicada had huge scaling issue due to extra wide road that i noticed about 10 iterations from the final release. There is very little reference points where to compare the size of objects, the whole track can suffer from this. Ther is car-for-scale xpack to check road dimensions.

    BTW, your road width is good for one car only, if that was the purpose, good. If not... you need to move EVERY tree on that 10km stretch or remove them and create new ones when you widen the road. Don't use road width tool, it distorts AIW. he tool has useful applications, fixing driveable road width is not one of them... Use track cross-section tool to shape your road width roughly what it's going to be. . So before placing ground objects, make the layout as close to final as you can. Before you start to really split the track in to sections or start to place roadside objects etc. I auto-generate temporary objects like trees while testing the layout to get some references.

    I'm pretty sure you need to rework the whole terrain and also you may want to use multimaterial cross-sections when more experience is gathered. Terrain needs reworking, the 1st panel width is too much, it looks like default values were used. It's too wide on those places where the road is "carved" in to the ground making the really steep inclines look odd and angular.
     
  9. @Kennett Ylitalo

    I havent really touched on the DDS format as I'm not artistic, but I've started using paint.net as it's free.
    I'm confused with the saving options as they are different terminoligy/options to what you've stated. Which options should anyone be selecting from the following when saving textures for rFactor?.

    Compressor Typre;
    • Range Fit
    • Cluster Fit
    • Iterative Fit

    Error Metric;
    • Uniform
    • Perceptual

    Weight Colour by Alpha;
    • On
    • Off

    Generate Mip Maps;
    • Super Sampling
    • Bilinear
    • Bicubic
    • Nearest Neighbour

    Also is DXT1 the correct setting when creating transparency for saving tinted glass?
    ;)
     
  10. Never seen those option, i use photoshop with nvidia plugin. Guess you have to experiment with them. Compressor type seems to be connected to what kind of image you have, if it has large almost single color parts, use range, if it has repeating patterns or clusters, then cluster and complex textures would be the last. Weight color alpha, never even heard of it, error metric the same. I can't now see what mipmap creation method i'm using, i think it was bi-linear.

    DXT1 is the simplest one, no alpha layers there. DXT3 and DXT5 are more complex. So i would say use DXT3 if the transparency layer is uniform and DXT5 if it's detailed. I can't reach my work pc so i'm just referring from memory,
     
  11. ok,

    I'll just play around and see what happens
    ;)
     
  12. For 'Generate Mip Maps', try anything other than Nearest Neighbour. If you're not familiar with mipmaps, there's a definition here. These four options determine how the smaller images are generated, just like when an image is resized.
     
    • Like Like x 1