TrackEd here splits by mult-sub material name first here, not object name.
Object names in Max isn't propagated at all here unfortunately.
That is after splitting of course. I've not checked pre-splitter so maybe it's ok pre-splitter
The trackED function
AUTO- Ase to Dof is converting the *.ase file into *.dof files per object/per material.
The
Splitter combines all objects which share the same
material as defined in 3ds max (and subsequently the shader as defined in track.shd) and creates dof's for those within a certain radius in meters. Example:
- You can have 500 dof's with grass sheets for example. After splitting with a radius of 100 meters, you can assign lod distances for the split dof's which might be only 50 in total throughout the entire track. That's already an fps gain right there.
- All the grass on the outside of the track and guardrails usually has less geometry detail so you could split that with a radius of 500 meters for example resulting in not too many dof's for this type of material.
Yes splitting keeps normals intact. But if you do split the track it isn't easily maintainable.
Again, that is besides the point. A split track shouldn't act as source used to continue working. You're not going to make a drawing in photoshop, print it, scan it back in, and make an adjustment, you'll just open the *.PSD file instead. In our case, you just open your 3ds max file.
Splitting is the final step, but how do you check for FPS performance without splitting/batching of alike shaders?
Usually you can get a really good idea pre-split when it comes down to performance and even then it is usually (expensive) shaders and shadows which are killing performance. After splitting you could do some LOD-ing for sure. That is why it always good to have backups of unsplit dofs and split dofs. For example, with a simple copy/paste and a namechange of two files I can do a revert to the unsplit' state of a track in 5 minutes at most. It's just a matter of working in an organized fashion and not shift-deleting work too soon.
Iteratively running splitter each time you want to check something is quite time consuming.
I really don't have a clue why you would want to do this?
Do you build blind and never check the end result, checking how different smooth groups or shaders or mesh flow techniques might work, or do you iterate perpetually checking things all the time and making sure target FPS are on target etc.
Mesh flow techniques, mesh smooth etc. is all stuff which is a modellers job to do inside of 3dsmax. Of course occasionally the unwelded vertex, manifold face, weird edge, might pop up, but that is quickly fixed. Of course there are some tests in between but more often than not it's just built the thing and double check your work in 3ds max and do 1 or 2 major exports before building the shader file. This does come down to modelling experience in general and secondary Racer/TrackEd experience though.
You might see you have some free resources at a certain point and decide to build certain assets to a higher quality than planned, or vice versa.
In a perfect world we should do this. In reality, we never have that time to go back into something while customers would hardly notice and improvement unless it's a corner radius which is off or a service road is placed too early.
Yes trackEd lets you do this but it starts to cost you LOTS of time running splitter each time to check things etc.
Again, you simply don't, there is no reason why you would want to do that.
And once it's split what if FPS is poor? Splitting works ok if you tune the split size, but it's still a compromise because some elements might be invisible to the renderer (sub-pixel) but you are still processing their shader/geometry.
So too small splits and we have too many batches, too big splits and we have less batches but might still be rendering elements we can't even see.
We like to see more performance in terms of visuals as well, believe me, especially when I'm seeing pCars running at 60fps with realtime reflections and all it's fancy schmancy stuff. It's possible, only we're short on rocket scientists..
Throw in a newbie real-time content developer and they may have over-shot on poly count and VRAM use by miles and just have a 5fps track
Thats the newbies' problem, no matter which engine, they'll find the limit.
Being able to fast prototype and check performance is very valuable to have
Actually, since Racer is so open with all the *.ini editing and such it's very fast to do
prototypes as I do sometimes for Ruud or for r&d stuff!
So we need LOD (been around forever), but we can't use LOD using this workflow either, which can usually find you a load of saved batches by turning stuff off.
I've found around 33% to 50% more fps using a managed exporting process and manual build of the geometry.ini file!
Another assumption which is simply not entirely true. It's a matter of planning and thinking about your work
Everything that managed exporting process does you can manually as well, we don't use automated tools at the office either. This way, we ensure a difference between geometry source and the track source. If you look at rFactor for example, what you state in your source files with the exporter plugin can be easily overridden in the *.SCN file creating a difference between source and actual track. That is tricky stuff in a production environment and good luck finding that mismatch when a customer has a driver in the seat, calling you in blind panic, no thanks
It's this exact batch problem and CPU bottleneck problem which is why AMD are releasing their Mantle API.
Since Racer isn't so well set up for multi-core optimisations (those alone can find us 25-30% more FPS in some cases but breaks scripting and Newton for example), then batching and LOD's are really really valuable for us.
We can take the good parts from trackEd and the good parts from other tools and make the perfect (ish) tool
If it's up to me we go the UDK way with Racer, but I can only dream
For the OP right now, trackEd is the way to go and will do a good job
Dave
Poor guy got more than he bargained for, I blame you!
