/r/ChapmanTrackCreator
A subreddit for all discussion relevant to the Chapman Track Creator, which is being developed by /u/TChapman500. The Chapman Track Creator is a race track design tool being developed to allow users to create their own race tracks for the /r/rFactor, /r/rFactor2 and /r/NR2003 with the goal of not only being able to build tracks and place objects, but also draw AI lines, place cameras, and generate objects specific to that track with ease.
A list of pages dedicated solely to the Chapman Track Creator:
Development Thread (rFactor 1) on ISI forums
Development Thread (rFactor 2) on ISI forums
Official Chapman Track Creator web page
Official Chapman Track Creator Google+ page
A list of pages where the Chapman Track Creator will be discussed by /u/TChapman500:
TChapman500 Gaming YouTube Channel
Rules:
All discussion must be relevant to the Chapman Track Creator to some degree.
No profanity is allowed (strictly enforced).
Follow Reddit-wide rules.
/r/ChapmanTrackCreator
If you're interested and willing to moderate and grow this community, please go to r/redditrequest, where you can submit a request to take over the community. Be sure to read through the faq for r/redditrequest before submitting.
It may be a while before there are any further updates. I haven't been able to find the time to work on the editor lately.
UPDATE: I have now been finding some time to work on the editor. However, I need to implement code-optimizations before I can work on the mesh generator.
Just now, I have implemented enough object types with just enough of an implementation to start working on rendering the track. In addition to that, I have optimized the data structure of each object to reduce the memory footprint.
Although I anticipated needing to tell the editor that 350 degrees is the same as -10 degrees, what I didn't anticipate was that when I tell the editor to get a normalized vector going straight from the starting point of the arc to the endpoint of the arc, I would need to compare both the X and Y components of that vector in order to get an accurate heading calculation for that vector. So that's going to delay progress towards a screenshot demo a little bit while I try and figure out how to implement the checking system.
That was quite an adventure. And it looks like I correctly implemented the last function for this "bare minimum" on the first try. But I have not thoroughly tested it yet.
EDIT: Looks like it needs a little bit more work. But the basic implementation is correct.
I've partially implemented the F Section object type. And I've also poorly implemented the Arc object type (property changes are not saved).
The F Section defines drivable surfaces (Number Surfaces + 1 = Number F Sections). The Arc defines either an arc of constant radius or a perfectly straight line. I have to correct the implementation of the arc before I can complete the implementation of the F Section.
Once those two objects are properly implemented, then comes the part of actually generating the track mesh for display in the viewport. Screenshots coming "soon" (TM).
On another note, a little while ago, I said I would try to produce a video in Sandbox to try to explain the goals of the Chapman Track Creator. It turns out that the video is a bit harder than I thought it would be. So you're going to have to wait on that a bit longer.
I have found a compiler configuration that removes 6 DLL dependencies that are not available with WINE. But it increases the size of the EXE by a factor of more than 10 and adds at least 3 more DLL dependencies to the list. And I have not yet tested the build on WINE with this configuration. At first glance, it appears to be WINE compatible, but I would recommend against getting your hopes up.
The bug that inadvertently triggers the label editor in the Scene Explorer when expanding/collapsing an item has been fixed.
This bug triggers the label editing in the scene explorer when you click on the +/- squares to expand/hide a set of objects. Unlike the last bug (which took me a while just to figure out what's going on), for this bug, (I think) I know exactly what's going on. At least this bug isn't as important to fix as the last one.^1 Nonetheless, it will be fixed quickly.
I've implemented a feature to auto-populate a segment with containers for all the track sections (F, W, X, etc.) if certain conditions are met. If the geometry definition is single-layered or the selected simulator is NR2003, the inserted segment will be auto-populated with the above mentioned containers. That way, you can't break the track editor (theoretically) and editing is made a whole lot easier for you.
Note 1: I don't think that object rename bug is as critical as I initially thought it was. At worst, it would rename the wrong object. Otherwise, the editor would not be able to find the correct property and would thus do nothing.
It's been a while since I've updated you guys, so is a two-part update:
(1) A little while ago, I mentioned a bug in the program, where if you change the name of an object using the Properties Window, then end the editing by clicking on an object in the Scene Explorer, then the name of the object you clicked on would be changed rather than the object you wanted to rename. I have not yet found a way to fix that bug. And I am requiring that bug to be fixed before the Open Beta.
(2) A new object type named "Geometry" will be available. This will store one set of segments for your race track and you will be able to define multiple geometry sets per course (eg: pit road exit and racing line, ISI sims only). The geometry will have two "methods" of representation. (a) "Per Segment" (which is what Sandbox uses) and (b) "Layered" (separating elevation segments from wall segments, for example). I will attempt to make a video "soon" to demonstrate this using Sandbox.
PS: The "Layers" will be "Path" (defines the path that the track takes), "Elevation" (defines all of the elevation data for the track), "Surfaces" (defines all of the surfaces of the track), "Paint" (defines the paint on the track, ISI sims only), and "Walls" (defines the walls of the track).
This track editor has been tested on WINE. And failed miserably! However, I will eventually be working to make the application WINE compatible before the open Beta period starts.
Steps to Reproduce:
Result: The object you click to end the edit is the object that gets the new name.
Expected: The object that was selected for renaming (before you ended the edit) is the object that gets renamed.
Implications: Editing the property of an object that is non-existent in the accidentally selected object could corrupt the data and cause the track editor to crash. Though the results before hand may be hilarious (if not annoying).
Fixing this bug has just become top priority in this project!
I finally moved the project to a faster computer, but that meant upgrading the tools and that caused a lot of the code to break.
Code broken by the move:
Scene Explorer Object Rename [Stumped]
Properties Window Object Rename [Fixed]
Properties Window Validation Checker [Fixed]
Scene Controller Initialization Function [Fixed]
I now have the means to test this track editor on Linux using WINE and will now try to figure out how to (1) get it onto the computer and (2) seeing what setup steps are required.
WINE compatibility is on the requested features list for this project.
I tried making dynamic context menus for the Scene Explorer by using the insert menu functions. That failed. So I went with the delete functions instead which systematically removes items from a static list based on what is being selected. Now I have to create the functions that will allow you to insert the object type that you click on.
For that dilemma that I mentioned in the previous post, I've decided to wait on implementing the undo buffer until after the viewport is functioning exactly the way I want it to.
Before I complete the viewport functionality, I need to implement enough object types so that I can have the viewport render the track mesh according to those objects.
...and going straight into some complicated coding with the properties window! I need to resolve a catch-22 dilemma, somehow. Or does it's resolution mean it actually was not a catch-22?
The new web server that will host the Chapman Track Creator webpage has been (mostly) configured correctly. I'm still making a few tweaks here and there, but the webpage (or rather, the whole section of the parent site) for the Chapman Track Creator is now undergoing reconstruction.
The parent site (which has also changed), will now have an introduction page with some basic information about this track editor, with a link after the description to enter the section that is dedicated solely to the track editor.
I'll keep you updated on the progress. Work on the actual track editor will resume once the new site goes live. I'll try to resume work on the editor on Sunday. Preparing the new site first will take too long because I'm not very efficient at PHP.