[Genma Saotome]

There is a lot of mess everywhere in the KUJU track design. For example, the first half of the tsection.dat file contains the dimensional specifications... there are duplicates. The second half contains the linkage between a shape name and the set of specifications that describe it. That linkage could have been put into the .sd file (shape description file). Drop global shapes like roads and tracks into \global\shapes and their .sd file defines which specification entries to use to define the .tdb pathing. Or simplify further and drop tsection.dat entirely by placing the dimensions into the .sd file. Bingo, every track or road shape defines it's own pathing dimensions. Include one new data: RailTop(real number) and toss that in too. Over in the editor when snapping shapes together instead of using only the origin point to locate it use that plus the defined offset to the top of the rail. With that you could join different weight rails and the result would remain smooth.

Second alternative universe: Fact: Shapes for pathing do not need to remain constant. I've always said your shapes could be 39 foot long snakes lying perpendicular on 8 foot long alligators and so long as there is a pathing spec the shape itself is totally irrelevant to running trains. So use the editor to lay a path instead of shapes. Either procedurally generate the shapes (what happens w/ DT) or have the editor ask you what shape you want to use. That may sound a whole lot like what happens today but it isn't... it's turned around and by that I mean instead of using hte shape's file name as the functional driver you use the pathing specification instead. What this alternative lets you do is replace the shapes with any other dimensionally equal shape at NO RISK to either .tdb or specification of interactives and do so because the pathing spec is not edited... only the shape file name.


One learns something after 15 years of doing route work.

[ErickC]

What really irks me is that MSTS2 was going to use a spline system for automatically generating track using a higher resolution version of the existing databases that were used in FSX (which, as one might expect, has most of the world's rail lines in it). Hypothetically, model-wise, one could create just what the sim needs to generate the track and be done with it then. The community balked at it because they couldn't be bothered to learn how spline objects work in ESP scenery (I mentioned it in a recent post at t-s and one of the run8 fanbois made the same nonsensical comments that people made at the time). It would have been more or less precisely as you described.

[Genma Saotome]

ErickC, on 14 February 2019 - 05:48 PM, said:

It would have been more or less precisely as you described.

No.. what I was speaking to was all about shapes. My ideas for procedural track are quite different.

Like you described the path itself has to come from a map... nothing really innovative about that, it's just common sense. What the editor has to do is allow the route builder to specify (when needed) a change from 1t to something else (can't forget about older eras), to insert track switches (again, older eras when rail service was pervasive), stuff like turntables too. That can all be 2d work. Some (many) of the lines one starts with will not be tangent or fixed curvature ("pencil" them in??) and in other situations where editing occurs you have to work in spiral easements so basically if you are going to edit the pathing you need a pretty sophisticated editor. No editing is a non-starter simply because it dictates modern railroading, which to many, myself included, is the definition of boring.

The innovative part is you need to do the grades quite differently than anything we've done before. My proposal is to loft a plane / curtain, above the centerline of the track layout on the 2d map so it emerges 10m above the 3d terrain. At various locations along that vertical plane you mark grade change. Between any the grade change markers you assign a grade value. The software then draws the line of grade on the lofted plane so you can see where the track will lie. No more trial and error trying to cross the high mountain pass. When you got what you think is right, generate the track from the data in the 2d map and the data from the grade work you did. Done.

[waivethefive]

Whatever system is developed, it needs to offer a combination of useful features. Things like:

Concrete ties for mainlines while simultaneously allowing wood ties for passing sidings if that fits the prototype location, and rusty rail conditions for little used house tracks and industrial spurs. And it needs to allow route builders to specify crosstie type or banking requirements for a track segment with a few clicks of a mouse button (this is where any good editor could help make routes look better, and do it faster)

It also needs to be able to handle super-elevation differently based on track use. A 60 MPH mainline should have a steeper super-elevation banking adjacent to any 10-25 mph controlled siding. And it goes without saying that any 5-10 MPH industrial dead-end spur should have NO banking anywhere whatsover.

https://i.postimg.cc/vmcb90Qp/Screenshot-631-copy.jpg

The closest we get to that right now is Xtracks replaced with USTracks, provided mainline and siding are laid individually. Other dependencies at present are an accurate and flaw-free TDB. Of course, that's not going to stop Open rails from using the wrong crosstie type when the super-elevation function calls on dynamic track replacement using the same crosstie textures for both main and siding in situations where that is inappropriate. And when you add in the present day flaw of Open Rails super-elevating tracks that should not be banked (like any curve on any FRA-exempted spur), one must conclude that in general, the "all or nothing" super-elevation function in OR today seems to fall short in handling such diverse situations.

In terms of crosstie and rail condition "situational diversity", the height of the bar has already been set high now. We just lack better tools that would make it a much easier job. And the super-elevation and dynamic track modules need some continuing improvement. Any new track system, procedural or otherwise, that fails to clear that bar as it stands now is just urinating into the wind.

Right now I am struggling with converting an Xtracks route over to USTracks and still have all the curves respond to super-elevation calls and proper conversion on the fly to USTracks via an established track profile. Some curves ARE super-elevating, but are not converting to USTracks profile. A handful of others flat out fail to do either. You would be surprised at how any stray TDB issues (pre- and post-rebuild) or the presence of dynamic track immediately adjacent to both ends of a fixed X-tracks curve is currently causing failures of Open Rails to properly super-elevate. Roughly 95% of the curves are super-elevating properly with respect to this one route, but that still leaves 5% of fixed track curves that are not activating when they indeed should. And of course, 100% of curves on spurs are elevating when I don't want them to, but noting can be done about that given the lack of a solution.

And Ive been told the person who designed our current super-elevation module is no longer working on the project.

[ErickC]

I don't think you're understanding the purpose of this project. The purpose is to create a true-to-scale, public-domain, and open-source direct replacement for XTracks. At any rate, I've been pretty busy with school lately, so I haven't spent much time refining the basic pieces.

[Genma Saotome]

ErickC, on 07 April 2019 - 06:50 PM, said:

I don't think you're understanding the purpose of this project. The purpose is to create a true-to-scale, public-domain, and open-source direct replacement for XTracks. At any rate, I've been pretty busy with school lately, so I haven't spent much time refining the basic pieces.

Erick, what is the current status of your project?

I ask out of both curiosity as well the fact I have to export yet again a track library because I forget the top of the railhead must be 0.325m above the origin point of the shape. Aside from the curiosity of that specific number there is a certain irritation in knowing that the tsection file has a value for where the path offset is from the origin point -- virtually all values are zero because the 0.325m offset is hardcoded in train.exe and probably OR as well -- and that if you set up a road or track entry with a non zero value you can't place it correctly with TSRE, nor, if you solved that, will OR use the offset specified in the tsection. So... I was also curious about what were your plans about this "feature".

[ErickC]

I haven't had much time to work on it. When I graduated with my BSW last May, I decided "you know what would totally be great? If I went to grad school." And I've been stressing out over coursework ever since. :D

This is why most of my new releases of late have actually been old WIP and livery packs. I haven't had time to do much else. I was also considering that maybe it would be faster to just flesh out what hadn't been done for USTracks and rename everything to overwrite XTracks and the default track, but I don't know how that would work in terms of intellectual property, and the author, obviously, lacks the capacity to comment. It's certainly still doable to just suck it up and build a new system from scratch. I bought Mullan on sale a couple months ago, and I noticed that has new track, so obviously the scope of the project isn't beyond what we could accomplish. I will have to revisit the prototype track section and see what revisions I had wanted to make, since much of this thread was lost and I can't remember what I had in mind.

[Genma Saotome]

I get it: Life happens. A good thing it does. What is the subject of your grad program?

When you have occasion to need another breath of train-simming, please take a look at this thread and if you have any thoughts I'd like to hear them.

[ErickC]

I am in the last semester of a Master of Social Work program. With any luck, once I graduate, I'll be working primarily in public policy, community organizing, or organizational work (which is why my current field placement is teaching me management and grant writing duties). If I get really lucky, some kind of international work might be nice.

Anyway, I did have a little time to look at my test pieces today. Before I get to your specific concerns, I made some changes since the last test piece, and I wanted some feedback. First, I have drastically reduced the complexity to see if it made any real difference at most viewing angles:



The revisions force a few compromises, but reduces the complexity of the shapes by half, which will be important once we get to switches, because we're going to be doing a lot of boolean and cleanup work. The changes are:

• Simplified the rail cross-section to a simple rectangle with a flared-out bottom. The original profile was much more like Scalerail's.
  
• Flattened the top of the roadbed where it was slightly raised in the center before. Originally, it made sense to make the distance between the tie layer and roadbed layer smaller in the center to hide the visual trickery used to make the ties look 3D, but I've realized that the illusion breaks down at the ends of the ties from the angles where this would be a problem anyway, so it was adding complexity and not really solving the problem.
  
• The tie plate and spike layer has been flattened and raised slightly. It is now a flat polygon instead of having a raised center to follow the flare on the rail.

I have also created an alternate profile that eliminates the plate/spike layer entirely. For this profile, some careful texture work was used such that the plates end up on the tie layer instead, with the little nubs from the spikes added to the bottom of the rail to make it look more or less like it did when there was a separate spike layer.

This poses the problem of the roadbed layer. Kuju gave us this wonderful, flat roadbed profile. As the scope of this project is to create a direct replacement for the Kuju French fry rails, this limits the total vertical distance of the track profile. Obviously, as a direct replacement designed to overwrite the existing rails and instantly convert all routes to better rails, having a more accurate roadbed profile would cause conflicts. The flattened roadbed profile, however, looks kinda goofy in-sim:



It creates the overall impression that the roadbed has had one too many cheeseburgers. One potential solution is to have an accurate roadbed profile, and let it sink in the ground where it may. Future route builders could then just build like they would with Scalerail. For existing routes, we could just accept the more narrow appearance of the roadbed as the wider portions dip below the surface as an acceptable compromise to no longer being stuck with French fries for rails. The alpha channel could be adjusted to start the blend closer to the track.

Option two is to just deal with the fat roadbed on the grounds that most routes lack any texturing under the roadbed. In this case, it's preferable to have a roadbed that looks a little chubby but covers the width of the right-of-way. This stands in opposition to Scalerail, which has a great profile, but always looks like Unitrack when it's placed into existing routes without any layers placed underneath the roadbed to make a continuous gravel layer.

Option three is a hybrid approach. I sliced the accurate profile just above ground height, then brought the extreme edges up to ground height. This creates a two-step profile that starts out nice and steep, but flattens out to cover the correct roadbed width at ground level.

In any case, when I build the multi-track profiles, I am going to place gravel in between tracks to ensure a continuous roadbed.

At any rate, I have exported a couple of sample platters for everyone to look at. I have exported them not as a usable track shape, but as a base with several profiles on top so that people can compare them. The first shape has the plate layer, while the second shape lacks it. The best way to test these would probably be to make them a freight car, since Shape Viewer has never displayed alpha channels correctly, even when they were sorted.

 demo_assortment.zip (3.66MB)
Number of downloads: 236

I would like to hear some feedback on what option for the final profile seems best to those of you who build routes. I am not a route builder, I am a model builder, so I am considering those of you who are route builders to be the experts in what works best. In fact, I am going to say the same thing about the height of the rail above the origin as well. I was aware of the fact that the rail is 2 inches above zero, but I took it as a given to be worked with when making a direct replacement, not as something that might be changed. What sounds like the best option to you?

[ErickC]

Oh, yes, and there is also a much simpler option on the table that is actually similar to the default rails in TS20xx:







Using this profile leaves enough space on the map for a roadbed option that may be a best compromise: the track profile would be built with two roadbed profiles (all in one mesh, so one drawcall), but each will be mapped to a separate spot. Then you can just alpha out whichever one you don't want to use. The total triangle count for this profile is 18 per segment.

Obviously, as a public domain project, we could use one profile for the Kuju/XTracks project, and I could make the others available for anyone who wants to build a completely new system from it, so there will be options. The Scalerail-esque profile could be just the thing for a brand new system, while the option outlined in this post could be just the thing for the XTracks replacement.