This is an ongoing personal edit to the track. Unless someone is in contact with the original track maker and confirms if I have permission to release it then it is just for my personal use to race with otherwise.
I am also well aware at the BBMC website and track readme the steps they suggested to reduce performance issues, in this instance I know how to fix it without compromising on quality so thats what this thread is for.
As NR2003 has evolved over the years tracks and mods have become more and more graphically intensive. With the 4GB patch and dll its unfortunately allowed performance to take backseat more than you could get away with previously. While the 4GB Patch and dll are highly recommended to always use as it can fix 90% of the framerate issues you see with most tracks + mod combos its the Superspeedways (especially Daytona) is where it cannot be escaped from unless the proper performance steps are taken.
While I could just go back to an older Daytona version I didn't want to discard this version. I almost never fix or edit tracks by others (not worth my time) only if its a quick ini fix usually where AI were having issues or you'd get an unfair black flag because the track maker put the wrong coordinates in for pit entry or something. In this case I decided to spend a little time and increase the performance just enough so crashes when in replay mode no longer would occur. I to want to state this performance boost is probably not going to prevent the FCRD 22 mod from crashing, its extremely performance heavy and could probably use more reduction in vert count to stop the crashes I hear many players have (especially in replays). However I wanted to make sure the track would well enough for general performance heavy mods like my ICR one ... which is the reason why I am even bothering to fix Daytona BBMC in the first place because I noticed in rare occasions the game would crash in replay mode when on this track.
There are two factors that have contributed to superspeedway tracks always being more framerate intensive and crash prone:
- The tracks are very large meaning the volume of 3dos on the track will be more than you see on average for other track types
- The cars are bunched up 3 or more wide and when in replay mode the game is having to render more of these cars all at higher LOD levels the closer the camera is to the cars, road courses might be huge but cars are always spread far apart
The absolute worst (or best in the case) way to crash NR2003 at a modern track with a performance heavy mod is choose in replay mode from TV1 or TV2 the car that is mid pack as all 40+ cars are 3 or 4 wide. The camera is forcing the mod to have its highest poly count render all at the same time. Throw in a wreck occurring too and you've got even bigger issues because as the cars crash the damaged version of the cars is popping in and usually that is even HIGHER poly count because the damaged version has to show the insides of the car if the pieces get removed. Its a absolute disaster at that point and NR2003 uses your CPU more than GPU to render geometry and it hits the threshold the game was able to handle.
No 4GB patch or DLL will save you at that point. They can give you much more memory for things like textures but the NR2003.exe was only coded to handle a certain vert count on screen at a time and this is where the bottleneck occurs. So what is the solution outside of a mod itself but the track? 1) Lower the vert count on the track 3dos so the budget given tot he car mod is higher 2) adjust the camera settings so the zoom is not aggressive at angles all the cars would appear in full view
Most tracks that are making 3dos unfortunately create them using 3dsimed3. Yes, even my older tracks used this method (spoiler: my new version fo Armory Superspeedway I am wokring on fixes this so I am not saying I ddin't use this method in the past either) but now that I know how to create true 3dos I can gain all the performance benefits that come with it. As you can guess Daytona BBMC did not compile their 3dos the real method. As a result all of the models on track are TRIPLE or more the vert count because when 3dsimed3 makes a 3do it has a bug where it decimates every face on an object as a single piece thus increasing the verts because no part is actually connected. Included with this 3dsimed3 3dos do not have any LODs so it means the model regardless of the distance is always rendering in full all the time. So you can imagine a huge track like Daytona its why it takes such a massive FPS dip or outright crashes the game in replay mode.
To fix this I extract the 3dos from the track, clean them up in blender then using 3ds to create a PAS file that includes LODS I re-export the model and write a script to make a true 3do. Then I simply replace the 3do from the track with y new ne. It loks eaxtcly the same as the original but behidn the scenes the vert count is way lower and farther away the model will be reduced poly count or outright disappear.
Take this camper cog 3do that is spread across the track for example. The unrefined version is almost 2000 verts:
If I do simple cleanup by removing double vertices I get it down to less than 1k:
In my opinion for a trivial 3do that is just for decoration (and it is duplicated many times across the track) that is still a ton of verts. So of course in 3ds I give it LOD levels too:
Level 5:
Level 7:
Then at a certain distance far far away I make it no longer render anything. I have so far done this with all the campers, infield pit/musco lights, and the foam safer barrier 3d objects. Basically the biggest offender 3dos I am going after first, the ones that even though alone are 'low poly' when there is 10-50+ of them on the track it really adds up quickly. For example take this infield light:
Before I cleaned it up it was 150+ verts. Lets say there were 100 of these around the track that is 15k verts alone. By my reductions and LODs methods I can reduce that number down to less than 1k. The smaller the object the sooner I script it in the LODs to no longer render when you are very far away from it. All of these small performance fixes increases the 'budget' NR2003 has to work with for heavier mods and prevent it going over the limit and crashing.
One last example the 3D foam that sits in the safer barriers, the unrefined version was 15k. I reduced it by 3 times down to 5k and made it so when far away those objects don't appear. I also combined all of the foam 3dos into one. 3dsimed3 method doesn't allow you to group models as one like a true 3do compile does:
When you are in fly cam above the track you can't see them so it made no sense to have it still render too so even more fps gain.
So how does the track compare performance wise after just a few adjustments? For this benchmark I compare in sandbox as that does not have the DLL. It may seem trivial that its only a 10-20 fps gain right now but that can mean all the difference in the game crashing or not. I also have a few more 3dos I want to tackle before I declare I am done. I took a few comparison angels that were really bad in fps. I've managed to get other angles that were at 40-50 fs now straight 60+ which are not shown below:
There are a few more 3do's I want to do performance work on before I am probably 'done'. For example all the light poles around the track contribute to tens of thousands of verts and the main grandstand has a ton of unnecessary verts too (like double the crowd models when 1 set should be used for the front and back sides of the textures).
In NR2003 I've been looking at a replay I saved with my ICR mod where they are in massive 3 wide pack and adjusted the BBMC cameras slightly as well so its not as aggressive with the zoom. Between my performance updates and camera tweaks my mod no longer crashes on this track anymore, I still need to do more testing with massive wrecks occurring in a pack until I feel 'safe'.
I am also well aware at the BBMC website and track readme the steps they suggested to reduce performance issues, in this instance I know how to fix it without compromising on quality so thats what this thread is for.
As NR2003 has evolved over the years tracks and mods have become more and more graphically intensive. With the 4GB patch and dll its unfortunately allowed performance to take backseat more than you could get away with previously. While the 4GB Patch and dll are highly recommended to always use as it can fix 90% of the framerate issues you see with most tracks + mod combos its the Superspeedways (especially Daytona) is where it cannot be escaped from unless the proper performance steps are taken.
While I could just go back to an older Daytona version I didn't want to discard this version. I almost never fix or edit tracks by others (not worth my time) only if its a quick ini fix usually where AI were having issues or you'd get an unfair black flag because the track maker put the wrong coordinates in for pit entry or something. In this case I decided to spend a little time and increase the performance just enough so crashes when in replay mode no longer would occur. I to want to state this performance boost is probably not going to prevent the FCRD 22 mod from crashing, its extremely performance heavy and could probably use more reduction in vert count to stop the crashes I hear many players have (especially in replays). However I wanted to make sure the track would well enough for general performance heavy mods like my ICR one ... which is the reason why I am even bothering to fix Daytona BBMC in the first place because I noticed in rare occasions the game would crash in replay mode when on this track.
There are two factors that have contributed to superspeedway tracks always being more framerate intensive and crash prone:
- The tracks are very large meaning the volume of 3dos on the track will be more than you see on average for other track types
- The cars are bunched up 3 or more wide and when in replay mode the game is having to render more of these cars all at higher LOD levels the closer the camera is to the cars, road courses might be huge but cars are always spread far apart
The absolute worst (or best in the case) way to crash NR2003 at a modern track with a performance heavy mod is choose in replay mode from TV1 or TV2 the car that is mid pack as all 40+ cars are 3 or 4 wide. The camera is forcing the mod to have its highest poly count render all at the same time. Throw in a wreck occurring too and you've got even bigger issues because as the cars crash the damaged version of the cars is popping in and usually that is even HIGHER poly count because the damaged version has to show the insides of the car if the pieces get removed. Its a absolute disaster at that point and NR2003 uses your CPU more than GPU to render geometry and it hits the threshold the game was able to handle.
No 4GB patch or DLL will save you at that point. They can give you much more memory for things like textures but the NR2003.exe was only coded to handle a certain vert count on screen at a time and this is where the bottleneck occurs. So what is the solution outside of a mod itself but the track? 1) Lower the vert count on the track 3dos so the budget given tot he car mod is higher 2) adjust the camera settings so the zoom is not aggressive at angles all the cars would appear in full view
Most tracks that are making 3dos unfortunately create them using 3dsimed3. Yes, even my older tracks used this method (spoiler: my new version fo Armory Superspeedway I am wokring on fixes this so I am not saying I ddin't use this method in the past either) but now that I know how to create true 3dos I can gain all the performance benefits that come with it. As you can guess Daytona BBMC did not compile their 3dos the real method. As a result all of the models on track are TRIPLE or more the vert count because when 3dsimed3 makes a 3do it has a bug where it decimates every face on an object as a single piece thus increasing the verts because no part is actually connected. Included with this 3dsimed3 3dos do not have any LODs so it means the model regardless of the distance is always rendering in full all the time. So you can imagine a huge track like Daytona its why it takes such a massive FPS dip or outright crashes the game in replay mode.
To fix this I extract the 3dos from the track, clean them up in blender then using 3ds to create a PAS file that includes LODS I re-export the model and write a script to make a true 3do. Then I simply replace the 3do from the track with y new ne. It loks eaxtcly the same as the original but behidn the scenes the vert count is way lower and farther away the model will be reduced poly count or outright disappear.
Take this camper cog 3do that is spread across the track for example. The unrefined version is almost 2000 verts:
If I do simple cleanup by removing double vertices I get it down to less than 1k:
In my opinion for a trivial 3do that is just for decoration (and it is duplicated many times across the track) that is still a ton of verts. So of course in 3ds I give it LOD levels too:
Level 5:
Level 7:
Then at a certain distance far far away I make it no longer render anything. I have so far done this with all the campers, infield pit/musco lights, and the foam safer barrier 3d objects. Basically the biggest offender 3dos I am going after first, the ones that even though alone are 'low poly' when there is 10-50+ of them on the track it really adds up quickly. For example take this infield light:
Before I cleaned it up it was 150+ verts. Lets say there were 100 of these around the track that is 15k verts alone. By my reductions and LODs methods I can reduce that number down to less than 1k. The smaller the object the sooner I script it in the LODs to no longer render when you are very far away from it. All of these small performance fixes increases the 'budget' NR2003 has to work with for heavier mods and prevent it going over the limit and crashing.
One last example the 3D foam that sits in the safer barriers, the unrefined version was 15k. I reduced it by 3 times down to 5k and made it so when far away those objects don't appear. I also combined all of the foam 3dos into one. 3dsimed3 method doesn't allow you to group models as one like a true 3do compile does:
When you are in fly cam above the track you can't see them so it made no sense to have it still render too so even more fps gain.
So how does the track compare performance wise after just a few adjustments? For this benchmark I compare in sandbox as that does not have the DLL. It may seem trivial that its only a 10-20 fps gain right now but that can mean all the difference in the game crashing or not. I also have a few more 3dos I want to tackle before I declare I am done. I took a few comparison angels that were really bad in fps. I've managed to get other angles that were at 40-50 fs now straight 60+ which are not shown below:
There are a few more 3do's I want to do performance work on before I am probably 'done'. For example all the light poles around the track contribute to tens of thousands of verts and the main grandstand has a ton of unnecessary verts too (like double the crowd models when 1 set should be used for the front and back sides of the textures).
In NR2003 I've been looking at a replay I saved with my ICR mod where they are in massive 3 wide pack and adjusted the BBMC cameras slightly as well so its not as aggressive with the zoom. Between my performance updates and camera tweaks my mod no longer crashes on this track anymore, I still need to do more testing with massive wrecks occurring in a pack until I feel 'safe'.
