Basic Information This is a track editor to create race tracks for the rFactor, rFactor 2 and NR2003 racing simulators. The reason I’m making this editor is because all of the track editors that I have used for building tracks either have severe limitations or don’t have features to help me find out why a track either fails to load or causes the simulator to crash. And also, I’m a perfectionist! I want pin-point precision on every track I make and there are no track editors available that allows me to achieve that. Not very easily, anyways! Concepts For Track Construction Since this track editor will be able to create tracks for NR2003, and since I already know the concept for track building for NR2003, I figured I’d just copy the concept and use it for rFactor and rFactor 2. You will build tracks by laying down segments to define the shape of the track. Then within those segments, you will be able to create splines to define surfaces, walls (including safer walls and catch fences) and elevation data (including banking transitions and bumps). Plus, outside of NR2003, you can create far more complex tracks. So for rFactor and rFactor 2, I’ll expand the concepts to allow for far more complex track structures including straight pit roads on curved segments with far better looks, pit roads that bridge under/over the race track to the other side, and multi-course tracks where the exact same geometry is used for the portions of the courses are the same. Planned Features Create tracks for rFactor, rFactor 2, and NR2003. Debug tracks with absolute precision before you even attempt to drive on them in-game. LUA interface to allow for scripts that make it easier to build tracks. Keyboard entry to make absolute positioning of track segments, walls, ect. very easy. Hierarchical object browser for easy navigation of the objects that will make up the race track. Multiple types of guides to help in the construction of track features. Guides are saved to the project files. Multiple background images allow for higher resolution maps without sacrificing performance. Easy-to-use context menus with detailed tool-tips on what everything does. Edit not only the track geometry and scenery, but also cameras and AI lines. Create meshes of the track geometry for different resolutions with a fixed-resolution physics mesh. (rFactor 2) Takes advantage of RealRoad technology. Requested Features A short list of features that have been requested. Requested features already planned are in blue. Requests under consideration are in orange, requests that have been accepted are in green, and requests that have been rejected are in red. Requests that are not necessary (eg: because of how the editor handles certain things) are in plain text. Some feature requests may be a mix of colored and plain text. (rFactor 2) Allow for RealRoad technology. Allow control points of splines to be constrained. Ensure a fast undo response. Copy Texture/Object Packs into local track folder. Easy reload of updated objects/textures in Object/Texture Packs. Ensure that tracks can have a different number of sections per segment. Make seamless transitions of different courses on multi-course tracks very easy. Allow customization of sky object. Allow overlay of the track and surrounding terrain onto a heightmap image. Linux or Wine compatibility. Make the track editor a global solution. (See Note 1) Track editor with blender support or as a blender plugin. (For Blender plugin, see this thread) Sketchup Support Please feel free to correct me if I have misinterpreted your request. Screenshots [Currently Unavailable] TODO List Note: Only a few items will be on this list at a time. And once the list is cleared, a new list will be created. Implement the 3D accelerator. Links The rFactor 1 Thread Official Track Editor Page Official Track Editor Forum Official Subreddit (No Longer Maintained) Note: By "Official" I mean official for the track editor, not ISI. Notes If by "global solution," you mean "support for all racing simulators," then as of a few days ago, I have decided to expand the editor's capabilities via DLL plugins after the editor's release.
Sounds interesting, you have a decent (large) job ahead of you.. some questions (Sounds like a mix of BTB with much more precise editing and controls without the 3dsmax complexity - learning curve). Please ignore my ignorance, but a few questions - Will you be able to edit vertex's and move them, join/weld them- IE so track merges dont need to overlap poly's. Will you be able to apply textures directly to surfaces and edit / move/resize them. Also edit properties on them (ie normals for polys and alpha channels for vertex's) - Or is it purely just for modelling ? And the visuals will be applied in other tools ? Will you be able to spline map textures (follow splines) in the editor for groups of polys (objects?) - ie grass / sand traps etc arent planar mapped. Will it be WYSIWYG (Ie support for shaders/bump/spec etc mapping) ? Importing of objects (3ds, .dae) etc would be nice for those that already have a library of objects. Import of GPS data for splines, for initial builds ? Likely many more -
Sorry for not keeping this thread up to date. Please check-out the linked thread in the original post. I'll try to keep both threads up to date. Just a quick summary of what has happened (for those who did not see the rF1 thread): I made a breakthrough in editor development a week or so ago. Object types that will be used to build the track are being made in such a way that they can be used for any simulator (most of them anyways). And there is the possibility of this editor being put on Kickstarter. ---------------------------------------------------------- Sorry I'm so late answering these (if I haven't already answered them): That will be one of the primary features of the track editor. This track editor will have advanced texture coordinate editing features (eg: transform gizmo). There will be a number of curve types to choose from to manipulate the texturing of track surfaces. That's the whole goal of this track editor. I have really only considered importing simulator-specific object formats (eg: gmt, scn, 3do, ptf). But libraries will be supported. That is a possibility.
Progress report: I found a few overly-specialized objects that will reduce versatility. I'm working to remedy that. Code for the objects are almost up to date with current C++ standard. I am almost ready to start binding the functions in the MFC framework to that of the objects that will be used to construct the track. Question: Should I put this project on Kickstarter?
I'm in the process of implementing the 3D accelerator. This needs to be implemented before the rest of the objects are fully implemented so that I can check their implementation to make sure that it is correct. So far, so good. Also, I've partially implemented the Scene Explorer and Properties Window. Here it is: View attachment 16655
I have implemented the 3D accelerator. Here are two screenshots: First test (just to make sure that it's working) View attachment 16769 Second test with Fraps running (after I realized that I need to tell the application to constantly redraw the scene): View attachment 16768
Hey TChapman500, Looks like fun... Couple of questions ... q1: Are you using the commercial version of Fraps? q2: Will Chapman Track Creator be a commercial product, or a freebee? q3: How will it set itself apart from other current ventures such as "Race Track Builder" http://www.racetrackbuilder.com/ q4: What language are you writing in? I've been writing an aiw creation script for 3dsMax for the past few years. As it's being written in maxScript, it's effectively limited to a single thread (the UI thread in Max). It's been able to create working rF2 aiw files for a couple of years now. Along the way, I've found some screamingly fast methods of editing long splines (30 - 50km), crunching offsets from waypoints, and various other things aiw. If you run in to anything about aiw creation that presents problems or questions, feel free to ask, and I'll be happy to share what I've learned about it these past few years.
Hello, Bink. Yes, I'm using the commercial version of Fraps. The Chapman Track Creator will be a commercial product. The main thing setting the Chapman Track Creator from RTB is that CTC is (a) designed to maximize flexibility while minimizing "specialized objects", (b) designed to have a flexible UI, (c) will give you a number of different spline types to choose from and are not limited to just defining the track's layout, (d) will have a built-in debugger, allowing you to (hopefully) diagnose and repair potential problems before you load it onto the simulator, (e) will have a Lua API to allow for even greater versatility, and (f) AI line creation will be mostly automatic, complete with apron-detection to keep the AI from touching the apron on banked corners and spinning out. I'm writing the Chapman Track Creator in C++ using the MFC library and using Visual Studio Community Edition as my compiler. Thanks for the questions.
Excellent. Sounds well thought out. This is a big part of 'usability', and is the main detraction of dev mode. It's a fine line though, as you want to give the user flexibility, but not enough to hang themselves. The most difficult part about writing the automatic 'fast line' has been making it with as few rules as possible. The more concrete 'rules' that are written into it, the easier it is for them to come back and bite you on a different track. The CADD designed 'Tilke' tracks have been easier to automate than the more organic 'natural terrain' and street courses. I considered writing mine as a Max plugin, but having done a few decades of c++ ride-simulation stuff, it kind of reminded me too much of actual work. I'd never written in a scripting language before this, and have found that while it makes a ton of stuff much easier, it compensates for that by making the rest of it that much more of a pain (less horsepower, single thread, and that feeling of being trapped behind the api). Making a working aiw file has been the easier part of the job. The majority of the work is defining the process so that the average rF2 user can understand how to find their way through it, and come out the other end with a working simulation. The software has to understand the process, because it's wishful thinking to expect that the first time user will.
Quick updates: I have two new screenshots of the track editor here. The screenshots are of the implementation of the Scene Explorer's context menu being able to insert objects into the scene. Also, I will soon be testing the track editor's WINE compatibility so that it can be used on Linux systems.
