Chapman Track Creator

TChapman500

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
This feature list has been modified to exclude features exclusive to NR2003. Only features available for the ISI simulators are listed here.

  • Create tracks for rFactor 1, 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 bluish-green, 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.
  • Track editor with blender support or as a blender plugin. (For Blender plugin, see this thread)
  • Setting to adjust viewport clipping planes.
Please feel free to correct me if I have misinterpreted your request.

Screenshots
View attachment 11015
Track editor opened, but no track project opened.
View attachment 11014
Track project opened, but 3D accelerator not yet implemented.
View attachment 16401
Screenshot showing progress of the Scene Explorer and Properties windows.

Project Progress
The following is a 10-step summary of the stages of development. Completed steps will be highlighted in green text. The current stage may have a percentage marker on it.
  1. Create project start point.
  2. Add prototype menus and dialogs for starting race tracks.
  3. Start developing a parallel 64-bit version.
  4. Brainstorm/develop track components.
  5. Program UI elements to create track components.
  6. Add and program settings dialogs enhance customizability.
  7. Develop documentation for the track editor.
  8. Text editor-developed tracks in the simulator.
  9. Start Open-Beta Stage.
  10. Release the Track Editor.

Official Track Editor Links
Official Track Editor Page
Official Track Editor Forum
Official Track Editor Google+ Page
Official Track Editor Subreddit

Other Track Editor Resources
My Blog for This Track Editor
YouTube Channel for This Track Editor
Twitch Channel for This Track Editor

Note: By "Official" I mean official for the track editor, not ISI.

The "Other Track Editor Resources" section is where I may post stuff about the track editor to, but is not solely dedicated to the track editor.
 
Last edited:
Hi TChapman and welcome over to the RF2 Forums.

Very interesting product, how far along the development process do you think you are currently? Do you have a estimated release date?

Also with regards to RF2 Track Creation will you be building in tools to setup features such as Real Road?

Regards

Rob
 
RJames said:
Hi TChapman and welcome over to the RF2 Forums.

Very interesting product, how far along the development process do you think you are currently? Do you have a estimated release date?

Also with regards to RF2 Track Creation will you be building in tools to setup features such as Real Road?

Regards

Rob
Click to expand...
I'm mainly in the very early stages of concept development. I'm developing the file structures that will be used to store project data. But my resources are rather limited right now. I prefer not to set a release date for any of my projects because if I have to put them on hold for any reason, I'd be guaranteed to miss that date.

For real world in rFactor 2, I do intend on having that feature, I just didn't know what it was called and I forgot to list a feature that would imply that.

Rik said:
great news! Thanks Mr. Chapman
Click to expand...
Thanks. And you're welcome.
 
Very interesting project. If you haven't done so already, I suggest you browse through the BTB forum to see what issues people have that you could address in your program.
 
R Soul said:
Very interesting project. If you haven't done so already, I suggest you browse through the BTB forum to see what issues people have that you could address in your program.
Click to expand...
Sure thing. But could you give a short list of the most annoying issues that you've run into?

Prodigy said:
You mean RealRoad?
Click to expand...
Yes.
First post updated. Added an item to "Planned Features."
 
Last edited:
TChapman500 said:
But could you give a short list of the most annoying issues that you've run into?
Click to expand...
Some of the issue's you've already addressed - lack of precision etc. It's been a while since I did any track editing work but I'll see what I can come up with.

* Moving a node's control points. If you plan to allow the user to use nodes and control points to manipulate the spline, bear in mind that in BTB it's very difficult to move a control point without accidentally rotating it about the node. So an attempt to modify a corner can easily un-straighten the preceding straight.
* The undo system is very slow. I think BTB just copies old versions of the track file and loads them when Undo is used.
* File duplication. Object/texture packs (XPacks) are stored in a folder, and when imported into a project they are copied to its local folder.
* Importing objects. We have to use BTB's separate XPacker program to import a new object. It's okay if it all goes to plan the first time round, but updating the object requires re-importing to XPacker, then updating the XPack file. XPacker only updates what's in the XPacks folder, but not the project's folder.
* Track merging. BTB tracks are spline-based, so it means two tracks cannot just be joined together. My preferred method is to align the polys in a certain way, and then use an external program to delete/move vertices and remap textures if necessary. It gets good results but is very time consuming, and cannot be imported back into BTB for further use. Changing the track layout requires the merging to be done all over again. I think a good solution would be to allow some polys to be extruded from the end of one track to the side of another, but leaving the tracks under the control of splines or whatever other parameters you would use.
* Cross sections. Each track has a default cross section with 5 points. Multiple cross sections can be used at different parts of the track but they all have to have the same number of points. If one part of the track needs a lot of points, say to make a smooth curved banked corner, the whole track will have extra polys.
* BTB has a skydome/horizon template but it's within a .mas file and we cannot see it in BTB. This makes it quite hard to customize these elements.

And here's an idea:
* Drape a track and terrain over an object or heightmap image. BTB can import kml/gps data but the generated tracks are often too jagged. We can reduce the number of points processed but then the track loses its profile. A while ago I found a set of heightmaps and was able to make a 3d object out of it. I imported it into BTB and began draping my track over it. It was a tedious process, especially when it came to the terrain where I had to do one node at a time. I've never done a complete track that way but I think it has potential.
 
Okay. My comments in red.

* Moving a node's control points. If you plan to allow the user to use nodes and control points to manipulate the spline, bear in mind that in BTB it's very difficult to move a control point without accidentally rotating it about the node. So an attempt to modify a corner can easily un-straighten the preceding straight. - Already anticipated control nodes problems related to splines because of 3DS Max/gmax modeling.
* The undo system is very slow. I think BTB just copies old versions of the track file and loads them when Undo is used. - I'll keep this in mind and find a way to keep the undo's as fast as possible.
* File duplication. Object/texture packs (XPacks) are stored in a folder, and when imported into a project they are copied to its local folder. - I haven't planned on any object/texture packs. However, I already have a plan in place for pre-done textures/objects. It has to do with unpacking what the simulator has and putting it into a directory that can be referenced by the projects.
* Importing objects. We have to use BTB's separate XPacker program to import a new object. It's okay if it all goes to plan the first time round, but updating the object requires re-importing to XPacker, then updating the XPack file. XPacker only updates what's in the XPacks folder, but not the project's folder. - I haven't planned on any object/texture packs per-say. But I do have plans for shared objects which will not require you to go through the process that you have described.
* Track merging. BTB tracks are spline-based, so it means two tracks cannot just be joined together. My preferred method is to align the polys in a certain way, and then use an external program to delete/move vertices and remap textures if necessary. It gets good results but is very time consuming, and cannot be imported back into BTB for further use. Changing the track layout requires the merging to be done all over again. I think a good solution would be to allow some polys to be extruded from the end of one track to the side of another, but leaving the tracks under the control of splines or whatever other parameters you would use. - I've also noticed this issue in BTB. My editor will use a spline for the shape of the track, and additional splines for each surface. Also, in addition to defining the "centerline" (or the primary path) of a segment, you can define "sub-paths" to those segments as a means to seamlessly branch-off a new track.
* Cross sections. Each track has a default cross section with 5 points. Multiple cross sections can be used at different parts of the track but they all have to have the same number of points. If one part of the track needs a lot of points, say to make a smooth curved banked corner, the whole track will have extra polys. - Because I'm expanding off of the concept used by the sandbox track editor, you won't have this problem.
* BTB has a skydome/horizon template but it's within a .mas file and we cannot see it in BTB. This makes it quite hard to customize these elements. - The skybox objects (that you define/model) will be a property of the track.

And here's an idea:
* Drape a track and terrain over an object or heightmap image. BTB can import kml/gps data but the generated tracks are often too jagged. We can reduce the number of points processed but then the track loses its profile. A while ago I found a set of heightmaps and was able to make a 3d object out of it. I imported it into BTB and began draping my track over it. It was a tedious process, especially when it came to the terrain where I had to do one node at a time. I've never done a complete track that way but I think it has potential. - Something similar to that had crossed my mind. But it might be a bit difficult to implement.
The following tasks on the TODO list are complete:

  • Move the new track dialog call to the window that comes up when "File->New" is called.
  • Modify the new track dialog to request the simulator that the track is being made for.


Also, the following tasks are important and have been added to the list.

  • Implement the 3D accelerator.
  • Implement text editor window for text files related to the track.

First post updated.
 
Very interesting. However, people working independently and not altogether is not desirable IMO.

We have Mario Morais and his track making tools.
Dave Noonan and his 3dsimed.
Brendon Pywell and BTB.
And now you.

The first three programs are quite different conceptually between them.
The only complete track making tool
Is BTB but is quite limited in some aspects especially regarding geometry and texture editing because the development stopped.
3dsimed is nice for solving some of the issues of BTB (shader editting) but is not actually a track making but editting tool.
Marios tools work under 3dsmax so its not properly a track making software IMO. Scripts are not user friendly and should be avoided from this type of sofware.

I will give you later on my list of things that would make BtB the perfect tool. Some of them have been already mentioned.

enviado mediante tapatalk
 
Looks like a great project, Mr. Chapman. #1 on my wish list would be Linux compatibility (wine is fine) as I spend most of my time in Linux these days and could work on a track I've been thinking about for a long time at leisure there. What language / dev environment will you be using for your project?

Keep up the good work,

Uwe
 
SPASKIS said:
Very interesting. However, people working independently and not altogether is not desirable IMO.

We have Mario Morais and his track making tools.
Dave Noonan and his 3dsimed.
Brendon Pywell and BTB.
And now you.
Click to expand...

Don't know if it was intended but that comes across as a bit insulting. Personally, I thank you TChapman500 for attempting this. It would be great to have a more user friendly track creator. Best of luck with it.
 
SPASKIS said:
Very interesting. However, people working independently and not altogether is not desirable IMO.

We have Mario Morais and his track making tools.
Dave Noonan and his 3dsimed.
Brendon Pywell and BTB.
And now you.

The first three programs are quite different conceptually between them.
The only complete track making tool
Is BTB but is quite limited in some aspects especially regarding geometry and texture editing because the development stopped.
3dsimed is nice for solving some of the issues of BTB (shader editting) but is not actually a track making but editting tool.
Marios tools work under 3dsmax so its not properly a track making software IMO. Scripts are not user friendly and should be avoided from this type of sofware.

I will give you later on my list of things that would make BtB the perfect tool. Some of them have been already mentioned.
Click to expand...
Not sure how to interpret this. The funny thing is that this track editor is being based more on the sandbox track editor than BTB.

hoover said:
Looks like a great project, Mr. Chapman. #1 on my wish list would be Linux compatibility (wine is fine) as I spend most of my time in Linux these days and could work on a track I've been thinking about for a long time at leisure there. What language / dev environment will you be using for your project?

Keep up the good work,

Uwe
Click to expand...
Thanks. I have no experience programming with Linux or this "wine" thing. The track editor is being developed under the C++/MFC environment.

R Soul said:
Sounds good. Thanks for replying. :cool:
Click to expand...
You're welcome.

kmw said:
Don't know if it was intended but that comes across as a bit insulting. Personally, I thank you TChapman500 for attempting this. It would be great to have a more user friendly track creator. Best of luck with it.
Click to expand...
Thanks. And you're welcome.
I am attempting to implement the 3D accelerator.
 
TChapman500 said:
Not sure how to interpret this. The funny thing is that this track editor is being based more on the sandbox track editor than BTB.
Click to expand...

I just wanted to say that it is a shame people working on different projects and none of them provides a global solution to modders. I shouldn't be using so many different programs to build a track for rf2.

enviado mediante tapatalk
 
My dream would be proper Blender modelling support being available both for rf2 tracks, assets and cars. We have such a powerful, free and open source modelling tool available it's a shame we're not making better use of it.

Cheers, Uwe
 
SPASKIS said:
I just wanted to say that it is a shame people working on different projects and none of them provides a global solution to modders. I shouldn't be using so many different programs to build a track for rf2.
Click to expand...
It is possible to make it so that the time you spend in other programs is reduced, but I just don't think that a "global solution" is possible. The primary goal of this track editor is to make it easy to create tracks with absolute precision and seamless transitions between different "tracks" on multi-course tracks. However, I have given some thought as to how certain objects like grandstands would be built (since grandstands usually inherit the shape of the race track).

hoover said:
My dream would be proper Blender modelling support being available both for rf2 tracks, assets and cars. We have such a powerful, free and open source modelling tool available it's a shame we're not making better use of it.
Click to expand...
Now there's a thought. Make my track editor just a Blender plugin/extension. I'm not sure that that's such a good idea. None-the-less, I will consider it.
First post updated.
 
Last edited:
I should point out that Traveller is already making good progress with a Blender plugin:
https://community.racesimcentral.ne...Blender-Importer-Export-for-rFactor-(1)-GMT-s

Having used BTB for a while I think it's fair to say there are advantages of dedicated track programs. Blender/3dsMax can be quite daunting whereas BTB or CTC can omit irrelevant materials settings (for example) and provide things like cross sections which Blender doesn't have (not sure about 3dsMax).

BTW, another issue with BTB was that Brendon stopped communicating. It's understandable since there's a real world out there, but given BTB's potential, the lack of info has caused a bit of aggro.
 
Last edited:
3DS Max does not have cross-sectioning. That is, not unless you really know how to manipulate splines in 3DS Max.
Updated first post.
 
Last edited:
I'm having trouble implementing the 3D accelerator. So for now, I'll work on getting the file formats up. Here's a little code-snippet (which will vary from the final result).
View attachment 11064
 
Should I copy the first post of this thread and start a new thread on the rF2 forum?
 
I think you should start a new thread but add a link to this one. That way all discussion can be kept in one place.
 
R Soul said:
I think you should start a new thread but add a link to this one. That way all discussion can be kept in one place.
Click to expand...
Already done. There is a thread in "Current Products -> rFactor 2 -> Modding -> Track Modding"

K Szczech said:
Feel free to ask - here or via PM.
I may not be able to reply immediately, but I could still help a lot.
Click to expand...
Okay.
 
I'm currently working on the code for the NR2003 geometry. Note that the NR2003 and ISI geometry objects will be incompatible with each other.
 
Do you think a maximum of 2 billion track segments will be enough?

If you were to build Daytona using 1-foot track segments, you would use only 13 thousand segments.
 
I am not sure what do you mean with segments. Rfactor uses tris of about 1m by 2m which is 1m2 in area. A 10 m wide by 5000m would be about 50.000 m2 or tris, as you want. More or less that is about 5Mb gmt altogether. You are speaking about 40.000 times more. Right now a 200Gb track surface would kill any computer so I think it is a good number of tris.

enviado mediante tapatalk
 
The track will be built using splined segments, which will then be used to by the editor to generate the polygons that will be used by rFactor.
 
It looks like my hard drive is about to break down. So instead of working on the editor, I'll be backing up the project files.
 
I'm working on a formula to predict the characteristics of D-Ovals, Tri-Ovals and Quad-Ovals. But I need to narrow the number of unknowns down to one or the equation will not be solvable. The trial-and-error method will only serve to slow the program down.
 
I've posted a few updates on Facebook that I forgot to post here. First off, the track's Facebook page is https://www.facebook.com/pages/Chapman-Track-Creator/116403485222139.

To get you up to speed, I've been working on putting in handles for the various objects that will be used to build the tracks. I've decided on having those handles store structures rather than classes for performance reasons. Classes store both data and functions while structures generally store only data and therefore will have a smaller memory footprint than classes. The classes will be used to retrieve and modify the data stored within the structures.
 
Great thing. Good progress :) I'm looking forward to try your Track Creator :)
 
Thanks.

Here's another update. Because the page has 25 likes, it can now have a URL that is easier to remember. Just type in "ChapmanTrackCreator" after "facebook.com" and you'll find it.
 
I made a new spreadsheet that you can use to make the more "complex" tri-ovals, quad-ovals, D-ovals and figure-eight tracks. I have a backup just in case, so go ahead and play around with it. I'm going to put a similar system in place for the track editor, though you might not get quite the level of precision that you get in this spreadsheet (depending on the data-type used by the editor for positioning and heading information).

https://docs.google.com/spreadsheet/ccc?key=0Ak3SeqasZZyxdGhCbHZYX004ZHI2cl8tZDhycnpqa0E&usp=sharing
 
This update is a bit late, but I've installed a new hard drive on my computer and have resumed work on the track editor. Stay tuned for some new previews.
 
First post has been updated. Here's a new screenshot of the New Track dialog box.

View attachment 11925
For rFactor and rFactor 2, the "Full Track Name" is what goes into the "VenueName" line of the Event.gdb file.

The "Primary Course Name" is what goes into the "TrackName" line of the Event.gdb file. For single-course tracks, this is the same as "Full Track Name." For multi-course tracks, it can be the "Full Track Name" plus an appended "Oval" for example. Or the "Oval" example can be put in without the "Full Track Name."

Some Examples:
Example 1 (multi-course oval):
- Full Track Name = Daytona International Speedway
- Primary Course Name = Oval
or
- Primary Course Name = Daytona International Speedway - Oval
Example 2 (single-course road or oval):
- Full Track Name = Bristol Motor Speedway
- Primary Course name = Bristol Motor Speedway

The "Track File Name" is the physical name of the file given to the folder containing the track as well as the files containing the track data. The Naming convention for rFactor is typically either "TrackName" or "Track_Name." Examples:

Track File Name = NewHampshire

Directory Result
NewHampshire
NewHampshire/NewHampshire.mas
NewHampshire/NewHampshire_Maps.mas
NewHampshire/NewHampshire.tdf
 
TChapman500 said:
First post has been updated. Here's a new screenshot of the New Track dialog box.

View attachment 11925
For rFactor and rFactor 2, the "Full Track Name" is what goes into the "VenueName" line of the Event.gdb file.

The "Primary Course Name" is what goes into the "TrackName" line of the Event.gdb file. For single-course tracks, this is the same as "Full Track Name." For multi-course tracks, it can be the "Full Track Name" plus an appended "Oval" for example. Or the "Oval" example can be put in without the "Full Track Name."

Some Examples:
Example 1 (multi-course oval):
- Full Track Name = Daytona International Speedway
- Primary Course Name = Oval
or
- Primary Course Name = Daytona International Speedway - Oval
Example 2 (single-course road or oval):
- Full Track Name = Bristol Motor Speedway
- Primary Course name = Bristol Motor Speedway

The "Track File Name" is the physical name of the file given to the folder containing the track as well as the files containing the track data. The Naming convention for rFactor is typically either "TrackName" or "Track_Name." Examples:

Track File Name = NewHampshire

Directory Result
NewHampshire
NewHampshire/NewHampshire.mas
NewHampshire/NewHampshire_Maps.mas
NewHampshire/NewHampshire.tdf
Click to expand...

Hi TC,
What are your expectations about the time it will take you get the first functional beta version?

I am really interested in dedicated software for building tracks and for sure can help providing feedback, ideas, ...

However, up to today this thread has been something that IMO only a software developer would be interested in reading and where the target end user like myself probably does not undestand anything.

This makes me lose interest in the thread since my perception is that it will take years before anything where I can contribute is released.
I could be wrong but I have no other input so that I can have a different idea.

I guess that when you open this thread you are pretending to get back something from it. I don't know if you wanted feedback more from IT people or from end user profile people.

Dont take me wrong. I thought you would like to know what your final target public perceives when reads this thread.

enviado mediante tapatalk
 
You must log in or register to reply here.

Back
Top