Converting rfactor tracks to racer

hi,
i am trying to convert an rfactor track to racer. i have followed the instruction in racer.nl to do so, but I get this when I import the dof/ase.

no surface in the imported tracks, just the wireframes.

I tried a few methods already:

i imported the GMTs after changing the dds to tga, in zmodeler2 and exported it to zdmodeler1, and then exported it to 3ds format in zmodeler1.

  1. method 1; then i used the CTR plugin in 3d studio max given by racer and directly i put it in tracked.
  2. method 2: i exported the .dof files directly from zmodeler and used import dof in tracked
  3. method 3: i exported the 3ds into ASE in 3dstudio and tried to use modeler.exe to export it. but crashed
  4. method 4: i exported the 3ds into ASE in 3dstudio max and used cut ASE in tracked.
Method 1 2 4 has given me the track without the surface/mapping.
Method 3 crashed modeler.

tes.png


can anyone help me?
 
Did you setup the special.ini file like other tracks in the track folder, just the gfx section? Are the track textures in the track folder? When doing splines it is always best to have just the track .dof's in the geometry.ini file.

I did make a track making tutorial for Blender 3D that may still be in the download section that has all the info about getting a track into racer. That may help as a guide.

Looks like a good track.
 
I don't think there is a direct way to move the track across elegantly.

There possibly is if you are a programming god :D


But considering the rFactor engine and Racer engine are quite different, it's best to manage the assets properly and adjust where necessary to work best with the Racer engine.

So, I'd just load in a few GMT at a time to Zmodeller, then export them to 3ds.

Then import, sort, rename and layer the assets in 3DS Max, so you can see what you have to work with.

Then start going through all the materials. If you are using Max 2011 material viewer, you may struggle, it's been broken afaik. In Max 2010 you should be able to select material from scene and list all the materials in the selection pane, with a nice thumbnail. You can then start to just go through creating shaders for each one and setting them up in 3DS Max too, so you can see the textures in place in Max.
You could also set the materials to pink in 3DS Max, so they stand out, so it's easier to find bits you have missed.

rFactor tracks also use TONS of sub-materials on any given mesh element, so be prepared for lots of selecting faces by ID's.

Ideally you'd re-work a lot of the track, break it up and then re-bind it by material. So rather than say 200m of the track being in one mesh with 20 materials on it, you'd have 20 material objects that go around half the track. This is more efficient for our rendering pipeline in Racer!
If you don't optimise it, then you get poor framerates with only average looking visuals, not ideal. Well optimised they should run maybe 4x more FPS I think.

Dave
 
also, i would be using obj, as it keeps naming conventions and also the smoothing and normals..as where 3ds is rather old and obsolete...
 
3ds keeps normals.

It doesn't do the best job of normals, but as said, the rFactor tracks are built in such a way that you want to re-work the mesh logic quite a bit. Ie, in rFactor, smooth boundaries are achieved with edge splits (so co-incident verts), rather than smoothing groups. You can save thousands of verts that way. Perhaps add in lots of new rows of edges too, using Graphite tools in Max, and then you have a great base for baking some Ambient Occlusion into the verts too (need a shader for this, but it'd look cool :D )
Racer and modern computers can handle tons more polygons/verts than computers from rFactor/GTR2 days, and the graphics system in Racer now is better used in this way.


Naming conventions are nothing to be precious about. Layer them in 3DS Max and rename bunches of items to more meaningful ones. Clump items together which use the same material/shader/texture.


I converted Spa a while back for private use, and although it wasn't heavily optimised, the straight process to re-work everything was maybe 40hrs, as a process to rename/import/clean up meshes/generate materials/shaders etc etc etc...


As said, the issue isn't so much trying to get the rFactor mesh over without having to touch it, because in practice you will want to re-work lots of elements.
Ie, the bumps into some of the corners on Spa were just stupidly large. Clearly in GTR2 the physics is a bit iffy, but the mesh bumps were like 1-2m wavelength and about 10-15cm amplitude! In GTR2 it felt ok, in Racer your car is airborne or getting thrown off the track :D

Every single tree is also double sided, often with a duplicate 'night' tree underneath it (different shader and so mesh for the night time?)... you'll want to clear out all that duplicate data too.


Honestly, do it right and these tracks can look really nice, and should run really fast. Do it badly and it'll look iffy and have poor FPS.

There is little point saving anything beyond the UV coords and the raw polygons, and the material name it had (which usually points towards the texture it used, usually :D )

Dave
 
For cars?

The one that comes with Racer, iirc, splits the object per material, so you'd have a DOF for each 'batch' or shader, of your car. I don't believe there is a way to export without it 'splitting' like that.

The one you have made will work, but the author must remember to combine their model at export stage into one Max object, with sub materials and objects.
Remember, Racer has a limit on vert count per geob (about 20,000 verts), so if you try combine all Max objects into one unified mesh with any given material having over 20,000 ish verts, it'll skip some in rendering in Racer itself (corrupted looking mesh)
Just something to look out for :D

I generally find the ASE export (I work in cm units in Max for cars), Modeller import, optimise, scale / 100, export dof really fast and useful.
I think the main thing is that it's fast. Although sometimes I've had issue with the multi-sub material break-up that occurs. I wonder if the Racer Max tool or your tool would work better in those situations... hmmmm.


Just to note Some1, your exporter had issues with some track objects I was exporting for Racer, I think it was a normals issue. I'll find the mesh in question and send it to you so you can see the difference and try fix it if you want?


In any case, the Racer tool and your tool, ideally, need to be made non-destructive for export purposes, and that basically means a tick-box to allow the select object/s to be exported to ONE dof. Combining objects to export, to then revert back to an un-combined model, is slower than ASE > modeller > Racer.
The Racer tool won't even do it (at last check), since it seems more optimised for tracks for now (which it is much better for if you get it into your pipeline fully :D )

Dave
 
For cars?
Dave

For cars & tracks, I use my exporter. I have had no issues whatsoever. For example, my Corvette is 30000+ tris and no issues in Racer, no corrupted meshes or anything. My exporter detects if a geob exceeds the limit of the vertices/faces and just creates a new geob during export.

Really, the "ASE to Modeller to DOF" flow was the reason I created my exporter in the first place. My exporter does practically all the same stuff the modeller used to do - I even got the optimizing code directly from Ruud.
Usually, when I export I immediately check the result in Racer which means exiting from Max without saving anyway... so the reverting part does not really apply for me. Collapsing the selected objects to one mesh is really just a button click in Max (there's a collapse tool/button fyi). Perhaps in the future I can implement automatic merging of selected objects to one mesh.

So, I'm not sure why you're still using the ASE method and what kind of problems you are having with my modeler... I sure would like to know though. :)

Can you send me the mesh and textures you had problems with?
 
For cars & tracks, I use my exporter. I have had no issues whatsoever. For example, my Corvette is 30000+ tris and no issues in Racer, no corrupted meshes or anything. My exporter detects if a geob exceeds the limit of the vertices/faces and just creates a new geob during export.

Really, the "ASE to Modeller to DOF" flow was the reason I created my exporter in the first place. My exporter does practically all the same stuff the modeller used to do - I even got the optimizing code directly from Ruud.
Usually, when I export I immediately check the result in Racer which means exiting from Max without saving anyway... so the reverting part does not really apply for me. Collapsing the selected objects to one mesh is really just a button click in Max (there's a collapse tool/button fyi). Perhaps in the future I can implement automatic merging of selected objects to one mesh.

So, I'm not sure why you're still using the ASE method and what kind of problems you are having with my modeler... I sure would like to know though. :)

Can you send me the mesh and textures you had problems with?

Hmmm,

Your 'collapse' method would work nicely, but unfortunately it doesn't seem to combine materials into a multi-sub automatically for you.

So you have to attach all the objects which is time consuming, so Max generates a multi-sub, just for the DOF exporter to split it all by material during writing anyway :D

I still think if you had a swatch box to turn selected objects into one dof, it would be much more powerful, vs having to combine stuff.

Also, I model in cm or mm scale for cars, so find the 'fast' scale option in Racers Modeller useful. I'd still have to visit modeller after using your tool.

Of course, that is my workflow difference to yours... :D

I'd use your tool all day long for cars if it just had a 'scale' factor spinner and a tick box to export all selected objects as one dof!



All that isn't to say your tool isn't good. I've used it almost 100% exclusively for track creation purposes. It has simply transformed track production and debugging speed for me.

The new Racer Max Dof tool is moving things on further, although I think it needs some work. I'd prefer more toggles for how it operates, as I don't really like the way it generates shader + object names for items when it breaks them up from a multi-sub object. It makes good sense to do that, but in some cases, especially development, you might want to keep everything wrapped in one DOF file (like a car), not split into each shader.
This is more so the case for example, if you have 10 pit buildings that are identical. If each one uses three shaders, you end up with 30 DOF. So you would logically combine them to one Max object, so it became 3 DOF (one for each shader, or batch). However now in Max editing is really difficult as you can't just move one object around or export it again without more clicks/processes to re-review how it looks in Racer.
Sometimes it's just nice to select a bunch of items, export, and then add a single line entry for that dof in the geometry.ini and then iteratively work with it.

Your tool enables that because it doesn't split multi-sub materials into individual DOF.


There is no right or wrong, don't take any of this is criticism. It's just nice to have flexibility to do what you want to do, not be limited by the workflow imposed by the tools. That is what made Racer track creation Soooo tedious for years, it was all centred around using the very destructive and linear TrackEd workflow.



Anyway Some1, I'm not sure if you have my email address, PM me and I'll email the object in question to you!


Many thanks

Dave
 
Hmmm,

Your 'collapse' method would work nicely, but unfortunately it doesn't seem to combine materials into a multi-sub automatically for you.

A-ha! Well, perhaps I missed this point earlier, but I if you don't work with multi-sub materials, things are bit different after all.

I, for one, work exclusively with multi-sub materials. I guess the rFactor way just grew on me. Multi-sub materials are somehow more logical for me to work with as they help me to manage my materials better. In the material editor I always have my materials visible, so I don't have to pick them from the scene all the time etc. Also, cars usually have many materials per object, so multi-sub to the rescue here as well.

Also, I model in cm or mm scale for cars, so find the 'fast' scale option in Racers Modeller useful. I'd still have to visit modeller after using your tool.

Of course, that is my workflow difference to yours... :D

Hmm.. I think I work with mm and I don't need scaling either. 1000mm should translate to 1.0 units in Racer without any hassle. Perhaps there are some settings in the Max unit setup dialog...
 
Yeah, if you use file units of mm in Max then it works ok, as the actual output DOF, I assume, is getting factored back up so 1000mm becomes '1' generic unit, which Racer will see as 1m :D

Perhaps in my old ways I just prefer to control what is going on, so working in dimensionless units is nice for me. I can quickly move the asset around and know it'll always be X units in size from Racer to an unbiased scale specific renderer for example. No worries over how other things 'see' the system unit and file unit scales.

But yes, in this case, it seems using Max's file unit scale and your DOF tool results in a proper 1:1 output to Racer :D


Yeah, multi-subs are a nice way of working sometimes. Sometimes I really want them, like in the object I sent you. It's crazy to have separate objects which you have to manage when they can be just one.
However, at other times it's nice to keep them split for easier management via layers for example (ie, you can hide all glass on a car, or all rubbers around windows, or whatever else quickly). I guess you could always use a multi-sub material AND many scene objects, just set the scene objects mat ID I suppose.

How come you would have to pick mats from the scene all the time? The viewer can hold about 24, and if you have the material browser open it can just fill a part of a 2nd screen with all your materials in it in smaller thumbnails (thousands to select if you wanted)



I suppose it ultimately all comes down to work-flows that work for you.

When converting an rFactor track, multi-subs are the ONLY way to work, and using the scene material previewer was a god send for me (hundreds of duplicate materials in hundreds of unique multi-sub combinations, arghhh hehe)
BUT, that exact methodology is death for FPS in Racer right now, more so because there is little to no texture atlasing in rFactor content!


I'd say, half the time I want to export a single object with multi-sub and have it one dof, as I would the exporter split it.
And I'd say half the time I want to export a bunch of objects with single materials into one dof, as I would have the exporter retain each object as a single dof.


Basically, flexibility doesn't hurt if all it means is adding a tick box to toggle the way the exporter works. The end result is all that matters and limiting choice of how to get there is bad.

Your tool proved that, because it suddenly meant we could all stop using trackEd as much and do more work much more quickly :D




Short reply is basically, can you add a button to your exporter please, so it exports a bunch of objects as one dof, not many :D Pretty please :D

Dave
 
After reading Mr Whippy and Some1's comments I know why I use Blender 3D to make tracks.

One dof or many dof's with one or several materials exported and put into racer by adding to geometry.ini. Tracked used for splining, cameras, etc. Simple.
 
It's not really complicated, we are being rather specific about processes that don't have to be so rigidly followed, they are just how we each prefer working.
In practice both ways are perfectly viable and easy to work with, it's just a preference. If you knew one you could swap to the other and understand it in minutes.

In my view, the single biggest task for anyone converting today will be trying to atlas textures and combine geometry where they can, to speed up the rendering performance of their tracks.
I think Spa had about 200 shaders/textures, and in practice I used about 10 actual shader types (preset at the top of the track.shd file)... so in theory, I'm making maybe 20x more calls to the renderer than is ideal. Eeek! In practice it might be more like 5-10x, but it's taking FPS from what might be near 85-90fps to about 30fps on my machine!
Problem with atlasing textures is that many simply are not designed to be atlased, many are repeating/tiled textures. A legacy of how old gfx pipelines worked. Today it's cheaper to run bigger textures that cover whole objects with more details, in an atlas, with more polygon detail. Sounds wrong, but it's quicker :D

It's not essential of course, faster GPU's mean we can just power through poorly optimised tracks, BUT, it means we are wasting GPU power doing pointless things rather than running more meshes/textures/shader effects on screen.

This is part of why Racer feels very slow for it's visual quality. A big chunk is just due to the legacy of old tracks build techniques on a new graphics pipeline!

Dave
 
Very interesting discussion. You start to understand why in a studio of only 30 people we have documentation on how to do EVERYTHING a certain way.

When it comes down to it for racer though, it is personal preference. Personally I use Some1's way more I think. Using a bunch of multisubs for tracks (now it's more just one massive one for terrain + track, etc and separate multisubs for trees and other unique objects) and probably one multisub for cars. Having said that though I'm trying to use less and less shaders now, to the point where I'm considering creating one "megashader" that you could potentially use on EVERYTHING (probably minus trees) and possibly combine a whole car into a single material. Unfortunately it'd probably require a material plugin for max that I've been wanting to write, but lack the skills to do so.

On topic however, I've been looking at a rFactor track recently that I want to create, but lack the proper data for. I know a guy got some good data so am attempting to import his track into max to use as a guide. The max GMT importer SUCKS. That's the slowest script I've ever had the displeasure of using. How does zmodeler fare in importing say 50mb of gmt files? Because it literally takes minutes for the max importer to do just one 1 point something mb file. Ideally I'd just like to raw dump the entire geometry into a single max file, I don't need textures or shaders, just geometry but it's taking forever to do so. Is there a better way of doing it?
 

Latest News

Do you prefer licensed hardware?

  • Yes for me it is vital

  • Yes, but only if it's a manufacturer I like

  • Yes, but only if the price is right

  • No, a generic wheel is fine

  • No, I would be ok with a replica


Results are only viewable after voting.
Back
Top