DBTracks with superelevation

[pgroenbaek]

I have been learning Blender lately to create some gantries, signs, and so forth for a route I'm building.

And to get an idea of the placements and the size of the objects I'm making, I ended up putting the shape of a 10m DBTracks piece into Blender just to use as a reference.

Looking at that shape made me realize how brilliant Norbert was about building DBTracks.

There really are no 3d objects used as such. It's all merely multiple surfaces overlaid on top of one another with transparency to create the 3d effect of the sleepers, etc.


And for a while now it's been bugging me how superelevation does not work with the DBTracks system because there are no STF or XML track profiles for it.

So having seen how Norbert built the track shape I decided to experiment a bit yesterday.


What I did was to pluck out the necessary vertex positions of a cross section of the DBTracks piece. Then I used those positions to define the STF profile polylines.

Next I started mapping the DBTracks textures to those polylines manually by hand. That took some trial and error and I am not completely done with this part yet.

When plopping that STF profile into my route and enabling superelevation, this is the result so far:






The tracks in these images are all superelevated and created by Open Rails based on the STF profile I put together. Notice how the tracks sort of dig into the ground on one side, that's because they are superelevated and my embankments are placed too high.

There are some things I want to iron out before I share the STF profile. As mentioned I'm not fully done with the texture mapping yet, and I also want to make a version with overhead wires.

I need to adjust the distance between sleepers as well. It's very close, but does not fully correspond to the distance in the regular DBTracks pieces.

And sometimes there are weird gaps at one end of the generated tracks, like this:



I don't know what to do about those gaps yet. I have seen that happen for normal dynamic tracks too, so I don't know if it is something that can even be fixed.


What do you think? I'm quite happy with the result so far considering this was just an experiment I started yesterday.

[kapitaen]

DBTracks-Profile for OpenRails has been around for some time....



https://tssf.eu/forum/thread/11072-wichtige-dokumente-für-openrails/

DBTracks-Schienenprofile von Lutz_s

Klick on

DBTracks-Schienenprofile zum Zwecke der Gleisüberhöhung in OpenRails[August 2017]

Jan

[pschlik]

Superelevation got a near complete rewrite by yours truely over the last few months, with all changes currently in unstable and coming to the next testing version (and then subsequently 1.6 when that version releases). If you were working on 1.5.1, the upcoming testing version will have some additional capabilities (all in the documentation) and might fix some oddities like those gaps.

Also, you don't need to match texture coordinates by guessing. If you are willing to go a little crazy you can decompress the original shape file and use the plain text data within to determine the position, normal, and UV of each vertex in the cross section. This is not fun or intuitive, but it can produce an exact match, which is what I did with Scale Rail.

[pgroenbaek]

DBTracks-Profile for OpenRails has been around for some time....



https://tssf.eu/forum/thread/11072-wichtige-dokumente-für-openrails/

DBTracks-Schienenprofile von Lutz_s

Klick on

DBTracks-Schienenprofile zum Zwecke der Gleisüberhöhung in OpenRails[August 2017]

Jan

Thanks for linking this Jan.

I did not know someone over at TSSF.eu had worked on this many years ago. Language barrier thing I guess, that page did not come up for me while doing english searches in the search engines, which kinda makes sense when the page is in german.

I'm going to continue with this since I also need the 1fb, 22f and 22fb variants, which are not included in the package. Because pschlik has added the ability for us to use superelevation with multiple track profiles and restrict them to specific track shapes those additional variants have become really relevant for me.

Superelevation got a near complete rewrite by yours truely over the last few months, with all changes currently in unstable and coming to the next testing version (and then subsequently 1.6 when that version releases). If you were working on 1.5.1, the upcoming testing version will have some additional capabilities (all in the documentation) and might fix some oddities like those gaps.

Also, you don't need to match texture coordinates by guessing. If you are willing to go a little crazy you can decompress the original shape file and use the plain text data within to determine the position, normal, and UV of each vertex in the cross section. This is not fun or intuitive, but it can produce an exact match, which is what I did with Scale Rail.

Yes I saw, and that's actually part of what prompted me to do this. Thank you for implementing that.

I'm definitely going to look into that. After a while of fiddling around with those numbers you start to see though the matrix and you can get really close. But if that can help ease things a bit then I'll take it, haha.

[kapitaen]

I did not know someone over at TSSF.eu had worked on this many years ago.

This forum was Norbert's home. Like me, he lived in Baden Württemberg. Here is his developer blog, but in German.

https://tssf.eu/forum/thread/1931-msts-tiefbau/

Jan

[pgroenbaek]

This forum was Norbert's home. Like me, he lived in Baden Württemberg. Here is his developer blog, but in German.

https://tssf.eu/forum/thread/1931-msts-tiefbau/

Jan

Yeah I really appreciate Norbert and everything he built over time. His work is what got me into routebuilding for Open Rails in the first place.

It's very nice for central & northern European routes in general.

My German fluency is only at the level of "broken school German". So I can understand a little but it can be a big challenge without something like Google Translate, particularly when writing or speaking it.

I'll definitely keep that thread in mind and have a look at it.

[pgroenbaek]

pschlik I have been testing Open Rails T1.5.1-1390-g6936c76b8 now with multiple track profiles since I have profiles for the base variants of DBTracks done (I will share those later). And it works great with the new Include parameters.

The super-elevation transitions are much more natural and it just feels right. So great job on that.


I have had some interesting effects for 1000r curves leading into 1000r tunnels. Since tunnels are not super-elevated there were very sudden transitions.

But that largely comes down to me not having set the speed limits appropriately. Things are fine in that regard if I set the speed limits to what they should be.


There are no gaps in the tracks now, but there are other wonky things going on with misaligned track at those exact same points. Example:



It has got something to do with my Dynatrax generated track shapes that have replaced normal dyntrack sections. But it does not always happen.

I'm currently looking into what is going on and under what circumstances. I'll keep you posted.

[pschlik]

Yes dynatrax shapes do something weird that isn't supported at the moment. For OR-only routes, I'd recommend replacing any dynatrax shapes with "regular" dynamic track, but at some point I'll have to figure out either getting superelevation to show up on dynatrax or forcing it to be smoothly disabled, instead of being so abrupt.

[eric]

As a developer, it pains me to say this, but perhaps doing a shape substitution on anything with a ShapeIdx that indicates dynamic track is what's needed?

Specifically, override the Dynatrax shape and use the TrProfile.stf whenever you encounter shapeIdx's that are in the local TSection.

[pgroenbaek]

After some testing I think I have figured out exactly what is going on.

I tried replacing the Dynatrax generated TrackObjs with regular dynamic track and that works.

Then I tried defining the Dynatrax generated track as a new track piece in the global tsection.dat and adjusting the sectionIdx in the world file accordingly. That works too.

If I define the new track piece in the global tsection.dat with the same id's that are used in the local tsection.dat it also works without any changes to the world file.


So what happens is that it is assumed that for TrackObj entries the section is always defined in the global tsection.dat. And that is never the case for Dynatrax generated track pieces that have replaced normal Dyntrack entries. Those SectionIdxs are always defined in the local tsection.dat.

So things are working as they should except that there needs to be an additional check. If the sectionIdx is not found in the global tsection for a TrackObj then also try to looking in the local tsection to see if it is defined there. I doubt anything else would need to change to fix this.

[pschlik]

That's plausible, I don't have many routes with dynatrax so I never did confirm that it could find route-specific track sections. And if it can't, then it doesn't know what shape of track to make so you just end up with no superelevation.

[eric]

That's why I'm suggesting shape substitution for anything found in the local TSection. No need to look for the shapes.

Sent from my SM-S911U using Tapatalk

[pgroenbaek]

Eric my point is just that it would still be really useful to be able to control which stf profile gets used based on the shape name. So the TrackObj entries should not be completely ignored.

For example my Dynatrax generated shapes use four different DBTracks profiles.

Ideally, I'd be able to rename each of them to something like "DB2f_Dynatrax-42803.s" or just add the shape names directly in the IncludeShape/ExcludeShape parameter.

[eric]

Ah... yeah, that complicates things.



Sent from my SM-S911U using Tapatalk