Discussion in 'Track Modding' started by TChapman500, Dec 10, 2013.
Keep up. Well done.
One step forward . Good thing you don't let it die.
Unplanned feature added: When a new project is created with the setting of "Multi-Course" selected, the name of the main course will be set to "Main Course" if you select "Multi-Course Road Course," and "Oval" if you select "Multi-Course Oval." This new feature only adds one extra line of code to the "New Project" function (which is being completely redone so that I can implement usage of the viewport).
I'm trying to host a VLOG series on my gaming channel. It will sometimes contain updates to the progress of this track editor. Here's a link to the playlist (note that the first 3 videos were recorded 3 years ago).
Anyways, framerate tests are back. ~3,100 fps with nothing in the scene. As for the mesh generator, I'm currently working on the data structures that will be used to create and manipulate the generated mesh.
Might be a noob question...
How is important fps when nothing on scene?
From my experience with BTB, the start of the project is never a problem in terms of fps. It gets tricky when the scene is heavily populated.
I would understand that a benchmark with some minimum content in the scene should be more representative. It is handling the scenario itself which seems to use more computing resources.
The main reason I'm testing it with nothing in the scene is to see how resource-intensive the MFC interface is. The way I figure, I can test the resource usage of the non-rendering part of the interface the most accurately by doing as little as possible during the 3D rendering. And I need something to make a comparison with for when I put the rendering on a separate thread.
Where is your project at?
Moving forward i hope.
Keep up , looking forward to it.
I'm still busy with other things and still at the "figure out how to make the mesh generator" stage. But I do have a structure for the mesh generator that at least looks promising. I just need to make sure that the mesh generator is not in the MFC framework. And I also need to implement an event system so that the mesh generator knows when to generate/delete/modify the mesh. I'll continue to keep you guys updated.
Do you know the Gmsh (mess generator)?
Is used in the zaxxon method for rfactor tracks and other uses too .
It might give ideas to move foward (just saying).
Thanks for keeping us updated.
Never heard of it, but I will look into it. Thanks. In the mean time, I believe I can simply get away with having the CPU decide what information the mesh generator needs, and have the GPU actually generate the mesh. Should be much faster than having the CPU generate it. The only drawbacks are (a) GPUs aren't designed for high-precision math (which is what I will be demanding from it) and (b) I do not yet know how I would get the generated mesh from the GPU.
I'm going to try to make sure that on Fridays, I do an update on the weeks that I'm actually doing something with the Chapman Track Creator (or any project that the CTC is dependent on). Here's the first set of these "weekly" updates (no promises by the way).
I've implemented an event system for the track objects. It turns out that it was much easier than I thought it would be, and in two days I was able to implement a working event system (which works perfectly). This comes after I spent weeks trying to implement a mesh generator into the MFC framework (which is very bloated now, by the way). I really thought that a customized event system would take much longer, but it turns out that trying to put the mesh generator in the wrong part of the application took valuable time away from implementing an event system. Now I can put the mesh generator in the appropriate track objects, which will hopefully take only a few days to implement. It should also take only a few days to tweak all of the track objects so that they fully utilize the new event system. I'm going to make sure that I save the event system so that I can tweak it for use in other projects!
Because the current implementation of the rendering engine cannot support the mesh generator, I've been working on improving on and expanding it. Plus, it needs to be cleaned-up a bit. The goal is for users to choose which graphics API (DirectX or OpenGL) the rendering engine uses and which version of the selected API is used, all without me having to make multiple copies of my application code just to support all of those options. In other words, I write the rendering engine with enough code to support multiple APIs and multiple API versions, and then give a single "wrapper" to be used by the Chapman Track Creator which will automatically call the right functions for the chosen API.
In case anyone is wondering what I've been doing that's kept me away from the Chapman Track Creator, I have about a dozen or so other projects that involve programming and I've been playing around with those projects to gain more programming experience and get more efficient at programming. This has the added benefit of not breaking the Chapman Track Creator on functionality that I've never tried to implement before. And even code that would otherwise seem to not be relevant to CTC (even indirectly relevant) turns out to be a big help in accelerating the development progress of this track editor.
I know you dont like to give a date for a beta but i looks that you getting close to it. How are you going to pack the objects for the tracks like houses, signs,etc etc?
Will it be more or less like btb that anyone can create their own packs or only your ones?
Nice you decided to update us.
Thanks, but there's still a lot of work to do. And I still need to get my website (a) back up and (b) programmed to work with the CTC.
The plan for packs is that users can use stock tracks' models/textures (simulator-specific) as packs and derive their own packs from those. Or create their own packs from scratch. All packs will be simulator-specific.
Package directory structure will probably be something like this:
Have figured out how to export straight to rfactor 2 ? Cos that would be fantastic.
I have a file that defines the rFactor2 GMT structure thanks to Traveller. So when it comes time to implement file exporting, I won't have to do as much guess-work. The only problem I can foresee is that the file may be a bit outdated.
I guess it's time for the weekly update. During the first couple of days of the week, I spent time preparing the official CTC website, only for the power to go out three times in two minutes one day, and for the internet to go out for a total of about 10 hours a couple of days later. I am now looking into dedicated web hosting services.
For the development of the Chapman Track Creator itself, I've been adjusting all of the track objects to use my new event system. This turned out to be a bit more time-consuming because I had to clean-up some spaghetti-code and reimplement several functions from scratch. I still have not yet fully implemented those functions, but I'm getting close to it. These reimplementations are on the Arc object which will be used to define the paths that most track segments follow, and will take into account things like the total width of the segment so that segments cannot overlap themselves. I was not able to work on the rendering engine this week.
I guess it's time for the weekly update. Again, there have been numerous internet outages delaying the progress of the track editor leaving me wondering why there aren't any offline versions of documentation available for me to use. And it's also the case that I've been trying to learn how to translate algebraic expressions into C++ code (which I've never really done before these past couple of weeks) and I've been using online resources as a guide.
Mostly this week, however, I've been working on a small game which I'm hoping to be able to release in the next week or so, rather than on the track editor that I wish I was able to release a year ago. I've been working on this game on the side for about a month now and I figured that I'd push that out first just to see how it turns out. And it's a nice break from trying to teach a computer how to do algebra.
To finish off this update: I have worked on the track editor a little this week. If an end of an arc is moved, the editor will first check to see if it has been moved to a legal position (except for maximum radius, which is not yet checked) and accept the new position, or check and move the end of the arc to at least have the minimum allowable radius.
Keep up the track editor please
Progress Report Time:
This has been a slow week, but I did make progress on the track editor and I solved the complexity issue for the arc functions. Now, when you move an end of the arc, the editor will check the new position against the arc's local reference frame rather than the global reference frame. This will reduce the time it takes for the editor to know if you're moving one end of the arc to a legal position as well as reducing the time it takes to adjust the position if given an illegal position. Though right now, it only does something if given a legal position. And I haven't been able to test what I have of the new implementation because the rendering engine now has a bunch of compile errors that I need to fix. So I've been working on that as well.
Also, over the past couple days, because I have the opportunity to do so, I've been making a whole bunch of video recordings. Expect a video on my gaming channel on how the viewport can be used once it's fully implemented (the video will be done before the feature is fully implemented).
Thanks for the update
Separate names with a comma.