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.

3DS Max 2014 Full Track To Racer

Discussion in 'Racer' started by ScottWalker92, Nov 18, 2013.

  1. I go to the University of Hertfordshire and I am trying to build a race track for our cruden simulator which runs racer pro.

    I have modelled a full track on 3ds max 2014 and its very detailed.

    I now want to import it to racer, but I am really struggling. I have read the tutorials on racer.nl but they aren't helping.

    Please can anyone help.
     
  2. really im looking for a Racer DOF exporter plugin for 3DS Max 2014?
     
  3. How are the tutorials on racer.nl not helping?

    You can export all the files you want into the track as *.ase and in trackED use the auto ASE to DOF function. this will covert the ASE files to *.dof files, splitting them per object and material :)
     
    Last edited: Nov 19, 2013
  4. Doesn't trackEd ASE parser require all materials to be in a sub-material material type?

    Also note their is a per object triangle limit per material type. So no more than about 20k verts per object if that entire object uses one shader/material in Max.

    Just a few things not mentioned on racer.nl among many other little operational details that are missing.



    The trackEd workflow works ok, but it leaves no place for making changes later without re-doing the whole process, so planning and checking are key otherwise you just end up doing many tasks again and again.

    It certainly isn't a non-linear workflow.

    Given the exacting nature of the workflow I can see why you want better instructions.

    I'll try write something with images at the weekend but I'm super busy so it might not happen till the Christmas break hehe.


    I think for this uni project given you have to learn something, learn trackEd, you really have no option given you are using Max 2014.

    And don't think the other approaches are 'easy'... some of them can probably look just as complex to a newbie track exporter I think!

    Dave
     
  5. Yes they need to be in sub-materials, but that is probably in the documentation as well.

    I've used this workflow for almost 2 years now, I think it works fine,very straight forward and almost fool proof. No need to make it more complicated than things need to be.

    You don't need to export the entire track again just because you have updated a piece of guardrail, that is why the dofs are split per object and material so you can easily adjust stuff :)

    Actually, compared to other pieces of software, I think Racer is very accessible once you get the basics figured out. At least on a track level, it's never like rocket science.

    Maybe the most obvious tip of all, go bother you classmates, they are possibly struggling with the same issues, team up and gather more knowledge in a shorter amount of time :)

    And another one, before doing your complete track, it might be worth building a small test scene first to (ab)use to learn the workflow more quickly and easily.
     
    Last edited: Nov 19, 2013
  6. So if a guard rail needs updating, you need to name the guardrail the name the trackEd called it, then export it to DOF how?

    Also after splitter splits things, you can have objects split down the middle. Ie, a kerb might be chopped in half at a funny angle.

    Also if object elements are batched together if they share a material via splitter, then we have even harder time just replacing one part. Ie, kerbs at many points may be part of the same object, and cut in non-ideal locations by splitter.

    Splitter makes what you suggest almost impossible. I'm struggling to understand how it's trivial to say pick up an old track and just update one corner on it. It's easier to just re-export from the original than try work out where the split edges are and cut your Max mesh to match so the new pieces fit in properly.




    The biggest one still in my mind is that it's a totally destructive workflow. Splitter cutting meshes up, naming conventions changed, flags decimated through split items, no LOD's able to be propogated etc.

    I totally agree on using a small test track to understand the functionality of how trackEd deals with things.

    I also agree it's the right way and only way to go in this guys case, and it will turn out ok in the end :D

    Dave
     
  7. No, because trackEd splits by object first, the name will be the name you give it in 3ds max :)
    Splitting keeps all normals intact, i have never seen weird artifacts due to splitting actually. It is however wise to keep kerbs separate as it just easier to handle.

    Splitting a track is the final step. just like building Mas files for rFactor, building the packages in UDK, zipping a bunch of files, etc. You don't use that as source, period. Splitting should not appear anywhere in your workflow unless it is the last step.

    It seems you have some assumptions of problems going on which aren't problems in the first place :p

    edit:
    Don't know if this made it to the free version, but I believe right now when you split a track trackEd even creates a new track folder for you with all the split dof's in there so you can keep the actual track and the split track separate.
     
  8. 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 :)



    Yes splitting keeps normals intact. But if you do split the track it isn't easily maintainable.

    Splitting is the final step, but how do you check for FPS performance without splitting/batching of alike shaders?

    Iteratively running splitter each time you want to check something is quite time consuming.

    I suppose there are different logics here to asset development.

    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.

    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.

    Yes trackEd lets you do this but it starts to cost you LOTS of time running splitter each time to check things etc.





    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.

    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 :D

    Being able to fast prototype and check performance is very valuable to have :)



    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!

    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.



    So pros and cons for each approach.


    Personally no current approach is ideal which is why I want to write a decent plugin for Max that just manages it all for you so there is great non-linearity in the build, but also fast prototyping performance.

    We can take the good parts from trackEd and the good parts from other tools and make the perfect (ish) tool :D



    But as time goes by I get more lured by Blender/python since Max doesn't seem to be going anywhere good for games dev stuff :D



    For the OP right now, trackEd is the way to go and will do a good job :)

    Dave
     
    • Like Like x 1
  9. 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.

    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.

    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.

    I really don't have a clue why you would want to do this?

    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.

    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.

    Again, you simply don't, there is no reason why you would want to do that.

    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..

    Thats the newbies' problem, no matter which engine, they'll find the limit.

    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!


    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.


    If it's up to me we go the UDK way with Racer, but I can only dream ;)

    Poor guy got more than he bargained for, I blame you! :p
     
  10. Flexibility is important in tools so artists can be free to express themselves without high cost or artificial constraint.

    Rigid workflows are important when you need rigidity for a reason, such as making sure a client gets exactly what they asked for.

    However trackEd offers limited flexibility for other tasks except pure full-track exports. Or if they do exist it's less optimised to achieve them vs alternatives.

    There is nothing wrong with that, it has it's job and it does it well.



    Once you are just trudging through the production process then these things might not be so important, but when developing ideas, shaders, techniques, they are really important to be able to do quickly.

    If you iterate say 30 ideas in a Sunday afternoon in your free time, and it takes 2 mins to go via TrackEd, an hour of your afternoon is wasted vs say 5 minutes using direct DOF export and geometry.ini entry insertion and reloading right inside Racer.

    Lets say you are trying to figure out why your trees look blue rather than green, or why the vert colour isn't being passed properly, or why vert normals are not being set right... each time is a new DOF, and going via ASE is slow.

    Or just good old previews of shaders/materials. Years ago in Racer we had shady.exe to preview shaders a bit, but these days the only way to see a shader in context is usually to just load it in the track you are working on to see how it looks. So again fast tools make so much sense for these tasks.




    I completely agree with your points, if you just build models, texture them, fire them out of the door. That is your job and you don't need to think about anything else.

    If you produce content that is your job and trackEd does it as good as anything else in the end.

    But if you are not familiar with all that then trackEd can feel like it's fighting you, or consuming lots of your time.

    This is where this guy is now. But this is his only choice and to be honest it's no harder than the other routes in the end. Given the project is apparently finished then this process may work out as the best one too :)






    In the end UDK is where the Racer tool-set might arrive after years of development and no cost on development of such tools :D

    Thomas Kinet invested some time in CTR, Some1 invested time in making his own DOF exporter (thanks!), and Camsinny helping me write scripts to prototype ideas and develop content in a more non-linear fashion.

    All these people didn't waste their time because trackEd already did it all for them and did it perfectly... they did it because things can be improved, and they are all doing the bits they can to make steps towards something better, or just to fill in a gap where other tools didn't make sense for their specific tasks.



    In the end the goal is to just make it so we can realise our visions more easily. So a wide tool-set and range of approaches allow us to meet that demand more easily.

    How we arrange those into workflows that fit with production needs or hobby needs, or uni project needs I guess is another thing :)
     
  11. Yeah so going back like a million steps here :p the main problem I am having is with allocating the materials correctly. I use the multi-sub materials and assign materials under this via the ID's. However when I export the item to tracked, everything is purple. Other thing is that the loft I create doesn't appear in tracked but if I create say a simple box in 3DS MAX and export it, the box appears.

    Confused :S
     
  12. Other thing, I can't ask anyone else about it as I am the only person doing track design for my final year project :)
     
  13. Convert your loft to editable poly before exporting and it should appear just fine.

    When all the geometry is loaded into the track, hit the Make track template.shd button in order to create a template shader file (track_template.shd). This will contain
    all the materials you have assigned in 3ds max and their textures, as well as a standard shader definition (vf_standard). If you rename this file to track.shd you will see all textures on your objects and you can begin to adjust the file however you wish to :)

    Note: if the template file remains empty, reload the track and try again, building a template directly after importing dofs won't work for some reason :)

    @Dave
    Obviously we have limited flexibility, but in return our tracks are very easy to debug, maintain and update.

    A more streamlined solution would be great, but for now we don't see the added value as we like to develop tools like that ourselves to fit our own needs.

    We don't tinker with shaders for two days for example, when we spend time on something, we have to account for it. In this manner, our current workflow is very simple and efficient :)
     
    • Like Like x 1
  14. Yep that's it, your tool fits the need you guys have there really well. But it shouldn't stop evolving I suppose.

    Superior ASE parsing would be nice. Things like x-form on normals seems a bit broken possibly, the 20k vert limit etc. They just let artists be a bit more WYSIWYG and not having to plan around these things.

    I suppose this is just documentation related though and we can certainly improve that together :)


    Just this thread alone covers some great topics and ideas and is good brain food for anyone wanting to learn more I think.

    I'll try add some images/explanations at the weekend if I get chance, then you can feel free to add to it or suggest changes/improvements if you want William. If we work together it'll always be better than working alone but in the same direction :D

    Dave
     
    • Like Like x 1
  15. Sorry to be a pain but I keep getting an error.

    Every time I try to use the Auto ASE to DOF function. The program will give an Fatal error and close.

    Then every now and then it will work again. I have no idea why, can you guys help?

    Scott
     
  16. What are your ase export settings in max?
    Also, what does QLOG.txt state?

    edit:
    Recommended settings
    [​IMG]
     
    • Like Like x 1
  17. Scott, how soon do you need the track doing?

    If you can wait till the Christmas break I can help you sort all this out and get it into Racer.

    But no harm in trying to keep going in the mean time with ASE/trackEd workflow. If you can get it working that is.


    As William said earlier, just try set up a really simple scene and make sure everything works with a simple and properly set up scene.
    Say just a patch of grass and road, very basic and easy to try work out what is going wrong :)


    Also try download the latest version of Free Racer and try build the track using it's version of trackEd. It could just be something wrong with your version currently?!

    Dave
     
    • Like Like x 1
  18. Thanks guys for the continued help...

    Unfortunately I am due to show my progress in the next few weeks, so I'm starting to panic.

    At the moment all I am trying to do is to get a simple box with texture into trackEd.

    William those settings work fine for exporting thanks.

    Problem is now, when I choose save and rename the track_template after importing the DOF, it will disappear if I reload the circuit and does not save properly.

    Any ideas? thanks!
     
  19. trackEd needs to be used with 'save track' first iirc, then reload.

    I think. Your description is quite vague exactly what you are doing.


    Can you get hold of Max 2010?

    Dave
     
  20. Get used to checking the QLOG.txt when something happens like stuff dissapearing.

    Objects dissappearing may mean there is something wrong with the:

    - shader
    - illegal character in the name of the material
    - illegal character in the name of the shader
    - no geometry.ini
    - empty geometry.ini
    - no track.shd
    - empty track.shd
    - shader which is used by object not defned in track.shd

    It's not a problem that you can't describe what is going wrong very clearly, especially when you are not sure about what you should be doing in the first place ;)

    Start small, check the qlog.txt file in the root of the racer directory. And especially, if you're smart, you'll make good use of the weekend when everyone is online most of the day and has some spare time, wink wink.
     
    • Like Like x 1