HELP!!! track crashes rf and 3dsimed....!

My track has suddenly started crashing rf at the tail end of loading. Progress bar reaches 100%, pauses and then crashes rf. 3dsimed begins to import the track, then does the same thing. I was told this could be an issue with the .scn file. But not being able to open it in 3dsimed, I'm stuck. Any clues? HELP!!


The SCN file is just a big text file. You can open it in any text editor (eg Notepad). Even so it might be hard to find the problem in there. Another possibility is material naming. If you have forced your own naming on some of your materials and you have two with the same forced name it usually crashes.

Alex Kyriak

Not sure if this will help but the problem sounds familiar to one I encounter. I find this happens sometimes when I move the track around a bit in BTB, and don't export the AIW when I export the track from BTB.

If the track is moved about and I don't realign the AIW, I think it can sometimes cause problems. It gets solved if I re-export the AIW (even if I haven't worked on the AIW) - I just tick the box in the export dialogue and it gets sorted.
Will try that.

Also, BTB won't open it anymore. So, my guess is that it's not the AIW, since all I was doing at the time was adding textures(wall banners/logos) on the tire walls, testing, adding textures, testing etc. Then all of a sudden it crashed rf and I've been stuck ever since.
I am importing it into max right now. Right now I see a bunch of Trackside Objects with surface material names (roada*) that are tagged as HAT. Haven't found anything else that looks wonky. Still working on importing everything though.
I separated meshes into groups by name to see if I could break down what objects are causing the problem. I got everything, Cones, Nightglow, Walls, obj, objc, (and the rest) to import. It is really hard to say what went wrong. It looks like something went fubar with materials. obj_429.gmt has material roada1508 assigned to it although there are no textures assigned to any of the shader levels. A lot of the other "tree-looking polygons" are not showing any textures. There is a car mesh (obj_49) with no texture. If I had to guess I'd say the png textures are doing it. I would use tga if you can't be bothered to convert to dds. Hopefully you have an earlier version that opens in BTB. Since I am falling asleep I'll see if I can get you a list of textureless objects later this week. At 397 material names, and thousands of objects and millions of polygons the entire track is taking huge amounts of memory to open, so much so that it is crashing max. :S

Once you get back to editing double check your xsectors, one of them doesn't intersect the ground plane and could be missed, I didn't check the other 2.

Thanks. But, I have to admit, the ease of using BTB can keep builders from looking at the details. I think the reason for all the extra materials is that I have tried many, then deleted them later. Unfortunately, BTB doesn't have a 'purge' option to remove anything that is not used prior to exporting to rF, to my knowledge, like I could do in 3dsimed. But, 3dse won't open it either.
As for the texture naming, this track has been a slow progression for about a year and a half now, mainly for testing purposes, long before my understanding of the need for proper naming of everything. I guess I should never assume that Xpacks will never clash once in the track file. I don't have enough time to browse forums for hours to learn everything that makes a good track great. (that's why I've created a track builders wiki) Hopefully I'll get there..
It very well could be that the import script is duplicating materials. While importing it almost looked like 1 object=1 material. I have no clue if there is a limit on the number of materials in a track. All I know is there were a lot of things to import. Moving forward in this case involves stepping back to an earlier backup where you had not so many objects. It is the only method I've seen here for recovery of a project that won't open. I would set aside the Schenley folder and contents you currently have for safe keeping. Like I said the cones, walls, and track surface are good. You may have to copy good scn entries out of the archived version into a newly extracted. Worst case scenario is you have to do this one by one with a load of 3dsimed or rf in between.

I wish BTB would accept gmt objects, because some of what you have is fine, and would make rebuilding the project back to where it should be that much quicker.

<elapsed time>

So the good news is I can open you scn in 3dsimed 1.18a. It looks like there is a problem with sobj_14.gmt.
Objects missing materials are:
obj_162.gmt (these are the flags)

While 'walking' around your track I noticed bunches of tires. If these are all tagged as Collision they may kill frame rates on impact for everyone nearby regardless of what car hits them. There was a Mosport recently released that had individual tire stacks that had separation between each stack, it killed fps.

Hopefully you can comment these objects out and it will load in rf again. Then you just have to worry about fixing the BTB project.


BTB doesn't handle materials optimally. Unfortunately it tends to keep creating new materials with identical copies of textures rather than re-using existing materials or existing textures. Xpacks compound the problem. This is counter to rFactor itself which loads all textures into a common pool of memory and re-uses them when a material calls for one. The result means that a complex track with many objects can end up choking rFactor by filling up all the texture memory. Track makers need to optimise the material use by naming all their own materials where possible. I had a crash problem like this and it turned out to be due to two materials having the same name where I'd ticked the box to force the naming on both of them. I had to manually edit the material XML files to fix the issue and I was then able to open the project in BTB again.
Top Bottom