[jtr1962]

tooltroll, on 08 August 2018 - 04:51 PM, said:

Fair enough points, but there are ways to compensate, and I like your idea of having more than just width and height randomised, as you can in forests. I'm not quite sure if you mean just assigning more randomisable attributes to the whole tree, though. I see it kind of like this: Blender has a 'sapling' addon that breaks down the tree into a hierarchy (or 'tree', if you will ;) ) of trunk, big branches, little branches, and so on, that may prove instructive: What if a tree came in pieces? Each piece could have a random chance of existing for each tree, so the trunk would appear 100%, each of three or four (?) big branches could appear, say, 60%, and each big branch could have three or four (?) little branches that each appear 40% of the time. The leaves would be part of the final branches in the hierarchy. Some 'final' branches could come in a few variations, as well. So the tree designer would make the whole tree, positioning all the branches, sub-branches, etc., and assign them probabilities, and at editing time, the software could throw dice to see how much of each tree gets included in each instance. At runtime, you'd load several small objects and textures that could then be used to 'build' the trees. Is that along the lines you're thinking?

Yes, that's exactly what I'm thinking. There's only one tree shape for each species, but a large number of possible ways it can be rendered in the sim.

Quote

Regarding the computational power requirements, the computations will be done at editing, so this is only a concern for route builders. Personally, I'd trade an hour or two of the computer chewing on a tile for spending days doing it myself.

I had actually been thinking of doing the random rendering as the sim is running but doing while the route is being built makes a lot more sense. Here the amount of computations don't really matter to the end user. And once "randomized", each tree in each location will appear the same every time you run the route. Again, this makes more sense. My initial idea would have had the trees appearing differently each time you run the route. While this might make for variety, it's not realistic. So I like your modifications to my initial proposal.

[tooltroll]

Nice to think about, but of course, it's all pie-in-the-sky unless OR can be made to render them all efficiently. For now, I'd be content with a more basic routine that concentrates on the area immediately adjacent to the track, using existing shapes and textures. Further back from the roadbed, conventional forests can still handle the job, and they're not horribly time consuming to place. (I did see another thread where they were suggesting that forests should be improved to enable other-than-rectangular shapes, which I found interesting. They were suggesting a 'lasso' function that lets you draw the desired outline. It's a neat idea, and we DO need more flexible forests, but I think it would be easier to just fix the code to enable n-gons up to 12 or 16 vertices. Maybe after that, they could make the vertices movable so editors could deform it to any desired shape.)

Bob

[Raffaele]

Back to the 'procedural track' theme, I struggled a bit with that and here're my thoughts (as far as I've understood):
1) trprofile.stf (or .xml) does contain a front section 'drawing' of a track, which is extruded along the path wherever a curve (longer than the 'Minimum Distance' value set in OR Experimentals tab) is detected;
2) To do so, trprofile.stf must read paths data in the route.tdb (position, elevation, orientation) and other path data (radius, angle) in the tsection.dat;
3) trprofile.stf doesn't read any shape file, because the shape 'he' has to draw and the textures that must be applied to that shape are written in the file itself. Also, static track shapes (meant as 2 or 3D visual models) do not rely on .tdb for their placement but on the .w files, which aren't read by the trprofile.stf.

OR team states that - at least at the moment - OR cannot support multiple dynamic track profiles in the same route, neither - I think - would be possible to introduce in the trprofile.stf code some kind of conditional branching, and the reason seems clear to me: more than one track profile in the same route, or more than one profile drawn in the same .stf file, would need a variable to rely on, and this variable is not encoded in OR at the moment.
But I think that, if this would be possible, the unique - or at least the most important - variable that should be introduced is the capability for the trprofile.stf to read the content of the static shape files it's going to replace along the path, and to manage different profiles (alternative) according to the .s file name.
If this would be possible, would be a great improvement for future OR routes, since this would allow to place multiple visual models of tracks in the same route, and let them to act anyway as the dyn track actually drawn as an unique model (per route) by the trprofile.stf.

Is the OR team planning something like that?

[James Ross]

Raffaele, on 04 September 2018 - 02:40 PM, said:

But I think that, if this would be possible, the unique - or at least the most important - variable that should be introduced is the capability for the trprofile.stf to read the content of the static shape files it's going to replace along the path, and to manage different profiles (alternative) according to the .s file name.
If this would be possible, would be a great improvement for future OR routes, since this would allow to place multiple visual models of tracks in the same route, and let them to act anyway as the dyn track actually drawn as an unique model (per route) by the trprofile.stf.

Is the OR team planning something like that?

I believe it is possible to go from the track database (vector data that the trains follow in .tdb file) to the shape file (in .w files) because the former has a world TileX, TileZ, UiD trio. It may even already be done in the code for superelevation, although it's not totally clear.

That said, I am not aware of any current plans to extend the existing dynamic track and track profile system. You are free to browse and add to our proposed features on the roadmap, though.

[SP 0-6-0]

Kinda long the same lines I guess. How hard would it be to make the dynamic track click and drag-able with the mouse? I guess this would be a form of procedural tracks.

Robert

[WaltN]

I think I can shed some light on this topic. However, I going to take it in two pieces -- the two paragraphs.

James Ross, on 05 September 2018 - 04:00 AM, said:

I believe it is possible to go from the track database (vector data that the trains follow in .tdb file) to the shape file (in .w files) because the former has a world TileX, TileZ, UiD trio. It may even already be done in the code for superelevation, although it's not totally clear.

I don't know what the first sentence of that paragraph has to do with dynamic track generation. Here's the way dynamic track is generated (taken from my "OR Design Overview"):

Quote

Dynamic track is processed with scenery objects (structures, vegetation, etc.) in a WorldFile constructor (in Scenery.cs). As of SVN163, dynamic track is constructed by helper method Decompose (in DynamicTrack.cs), which has the following objectives:

• It decomposes the subsections into individual, independent single-subsection dynamic track sections. The reason for this decomposition is to simplify downstream code.
  
• It tracks the positions of the roots of each independent section so that each section is aware of where it ends as well as begins. This is important because no order of dynamic track sections is guaranteed.
  
• It distributes elevation change throughout the sections according to a rule. Currently, the rule is the MSTS “plywood sheet” rule, which is explained below in Grade-Reckoning Methods. In the future, Open Rails will seek to correct anomalies in the MSTS method.
  
• It builds a mesh for each of the independent sections.

Each dynamic track object is represented by an instance of class DynTrackObj (in Orts.Formats.Msts.WFile in WFile.cs) and is accompanied by a WorldPosition object that relates the root position and orientation of the section. DyntrackAddAtomic decomposes a multi-subsection section into multiple single-section sections, each accompanied by its own WorldPosition object. A DynatrackDrawer object is created for each section and added to a dynamic track list.

Each DynatrackDrawer’s constructor creates a DynatrackMesh object, which defines the visual representation of the track section. All MSTS dynamic track curves are left-hand curves. That simplifies mesh generation a little bit, but in TDBTraveller you have to worry about both types of handedness.

When the PrepareFrame method is called for each DynatrackDrawer object, the mesh and accompanying transformation matrix are added to the impending frame.

(This description dates back to May 2011. Filenames in parenthesis may well have changed.)

To fully appreciate what is going on, the reader should refer to the OR source code.

JTang was responsible for the work on wire generation and superelevation. He told me at the time of the start of his work that he would be using dynamic track code that I wrote. I have never reviewed his work.

[Goku]

Quote

Back to the 'procedural track' theme, I struggled a bit with that and here're my thoughts (as far as I've understood):
1) trprofile.stf

This topic is for TSRE procedural shapes and it works in a totally different way than OR trprofile.stf.

1. In TSRE each shape can use DEFAULT template of custom template name can specified.
If DEFAULT is used for Tracks or Roads, TSRE will look in "globaldefinitions.dat" file for Hints what template to use. The goal is to completely get rid of GLOBAL directory and make software 100% independent from MSTS stuff.

For now the file looks like this:

ShapeDefinitions (
    Definition ( 
        Hint ( Default )
        Template ( DefaultTrack )
    )
)

So, this feature is basically not ready at all. In the future it will define hints for all kind of tracks and roads from tsection.dat file.

Template can be also set to DISABLED and the TSRE will use static shape file even if procedural tracks are enabled.

2. Templates are defined in "shapetemplates.dat" file.
There is no data structure specification yet, and everything was made only in a way that I could use it in my TSRE route. Some attributes are not in use at all.
Here is fragment of the file:

Templates (
    Version ( 0.1 )
    Template ( DefaultTrack
        Type ( TRACK )
        Ballast ( name1 DEFAULT 0-1500 1 ballast1.obj ballastv1.png 0.08 )
        Rail ( name2 DEFAULT 0-700 1 uic60s.obj rails1.png 0.325 0.72 )
        Rail ( name3 DEFAULT 0-700 1 uic60s.obj rails1.png 0.325 -0.72)
        Tie ( name6 DEFAULT 0-700 1 inbk3.obj rails1.png 0.05 )
    )
    Template ( NoBallast
        Type ( TRACK )
        Rail ( name2 DEFAULT 0-700 1 uic60s.obj rails1.png 0.325 0.72 )
        Rail ( name3 DEFAULT 0-700 1 uic60s.obj rails1.png 0.325 -0.72)
        Tie ( name6 DEFAULT 0-700 1 inbk3.obj rails1.png 0.05 )
    )    
    Template ( Siec0
        Type ( RULER )
        Stretch ( name2 DEFAULT 0-3000 2 siecp1.obj siecp2.obj siec.png 0.00 )
    )
    Template ( Electric30mh
        Type ( RULER )
        Stretch ( name2 DEFAULT 0-3000 1 ewire_30m.obj siec.png 0.00 )
        Point ( name3 NONE 0-3000 1 etower_30m.obj siec.png 0.00 )
    )    
    Template ( Electric50mh
        Type ( RULER )
        Stretch ( name2 DEFAULT 0-3000 1 ewire_50m.obj siec.png 0.00 )
        Point ( name3 NONE 0-3000 1 etower_50m.obj siec.png 0.00 )
    )

3D shape for a template is made from obj file. The obj file can be processed in many ways.
At the moment these types are working:
Ballast, Stretch, Rail, Tie, Point.

Here are results:

https://i.imgur.com/CBIGHEU.jpg
https://i.imgur.com/wvHqqDc.jpg

[Genma Saotome]

Jeez, this topic drives me wild w/ frustration.

Is anyone going to ask route builders -- in detail -- what they need... and try coding that?

Nope... never happens, does it?
=================================================

So listen up... one perspective (surely there are others):

(1) Track texturing: The UV mapping of rail, ballast, and roadbed should ALWAYS be determined by the art, not the programmer. That is to say if the ballast art needs to be scaled at 10m, the roadbed at 20m, and the rail at 5m, so be it. The code SHOULD NOT CARE where the UV values are sourced. It is just as easy for a program to pick up the UV mapping from the profile metadata file as it is to hardcode values in the source code -- AND it offers FAR GREATER flexibility to the route builder who often has to make his own textures. The ONLY matter that is truly an open question here is whether the art comes in a single texture file or multiple (the former being more efficient, the later may provide higher visual quality.

(2) The track (or road) path in 3d space is defined with only slight reference to where the terrain sits in that 3d space and so therefore the work-process to lay that path needs to scale accordingly. By this I mean if at point #1 the path occupies -5x, 500y, and 10Z and 5 miles away, on an angle of 278d relative to north, the track needs to be at 367x, 610y, and -456z the route builder needs a 5 mile long tangent between those two points without regard to where local variations in the terrain are. He does need to see where those those variations occur: are they representing cuts or fills? Does he want to "cut" the line at certain points and pull the grade up a bit, or push it down. What he does not want to do is start at Point A and lay down his line by guesswork as he goes (because he does not know the tangent between points A and B are 278d off north; what he knows is where he is and waaaay over there where he should be. Working by guesswork is fine over short distances (industrial spurs for instance) but for longer distances you want to jump from A to B and let the software tell you what direction you've chosen.

To implement this I'd be looking for the software to support a work process that lets me pick points A and B, no matter how far apart they are, and to display a vertical "curtain" that rises +/- a couple of meters above and below the terrain. Having found the X and Z locations is 3d space the route builder then uses that "curtain" piercing the terrain as the visual surface used to locate grade changes and to assign the elevation value at that point -- the Y values of the path.

Points A and B would normally be tangents. Laying out curves would be similar but more complex (assuming the introduction of spiral easements).

(3) Both procedural track and roads need drainage, which is to say both are lifted a bit above the immediate surface, even in cuts. This "subroadbed" should be procedurally generated as well, with it's own profile. This can get a bit sketchy on occasion -- a bridge or trestle for instance, or crossing a road. Running along a slope presents other issues with a longer descent is one on one side. All of that makes for a slightly different requirement when implementing the provided profile. I'm sure w/ good analysis this too can be implemented.

(4) I don't know if there is such a thing as procedural moving water... I don't see why there isn't. I will point out that such a thing may not be well suited to all bodies of water; It is probably great for oceans, still lakes and ponds, slow rivers w/ slight grades whereas specifying where white water rapids, waterfalls, and spillways at dams are located might be problematic.

(5) Others have expressed some concerns about procedural vegetation. I see that as largely variants of the forest areas we now use. That said, one must always be able to add individual vegetation shapes and have them illuminated consist ant with procedural vegetation.

[Goku]

Quote

Track texturing: The UV mapping of rail, ballast, and roadbed should ALWAYS be determined by the art, not the programmer.

That's the goal of TSRE procedural shapes. All shape attributes are defined by 3D designer in Blender. There is nothing hardcoded. Thanks to it, the solution can be used not only for tracks and roads, but also bridges, walls, electric towers etc.

The second point is reffering more to route building in general and not procedural shapes, so no answer here.

[ebnertra000]

Goku, on 06 September 2018 - 10:16 AM, said:

That's the goal of TSRE procedural shapes. All shape attributes are defined by 3D designer in Blender. There is nothing hardcoded. Thanks to it, the solution can be used not only for tracks and roads, but also bridges, walls, electric towers etc.

The second point is reffering more to route building in general and not procedural shapes, so no answer here.

Is this to say that such shapes can only be done in Blender? Or can other 3D-modeling programs be used as well?

[Genma Saotome]

Goku, on 06 September 2018 - 10:16 AM, said:

The second point is reffering more to route building in general and not procedural shapes, so no answer here.

Goku, there really is no separation of procedural track and the work process used to mark it's path. And that is really the whole issue. If the work process for setting down KUJU's track shapes was good then it would not matter that they were shapes instead of procedurally generated. And if the work process for procedural track is bad then it might make KUJU's approach look good by comparison. In fact, if you think about for a bit you'd realize that what I outlined WRT defining the path does not express any opinion whatsoever about whether the track/road so defined by the path is procedurally generated or the product of automatically placing track shapes for the user by figuring out which lengths were necessary to cover the distance and then setting them down based on the geometries already defined.

IOW, as a route builder, I do not care a bit by what means the track geometry is recorded as structured data -- by shape definition or by profile definitions, in SIMIS files or .json, it's all a don't care. I care about the work process to define its path. The means to record the definitions is important -- by all means work that problem, but if the work process to place paths in our 3d worlds is sub-optimal will people want to use it?

Here's another way to think about this matter. Let's assume you import a 2d map to use to create the path for track. By what work process will you allow the route builder to specify grades? To indicate where his tangents actually end and curves begin? Perhaps by some clever means you could figure out the 2d pathing per the image but what about the vertical? You could just let the track undulate with the terrain but as I'm sure you know, rail engineers normally don't do that on mainline paths; they add cuts and fills so any particular gradient is as long as possible. Second scenario: OSM path data is 3d; the data is not always accurate (bicycle paths over old rail ROW are not always well matched), so full xyz editing is required and sometimes the data is not even present, tho 2d maps are. The older the less likely you will find it.

So please be thinking of how the path is defined. Then apply how that path will be recorded and then how that recorded data is passed to be rendered.

All of us will have to deal with this pathing problem, including you, as something has to be in the code. In KUJU's code they simply allow you to tip the track shape up and down and leave it at that. If that's all you provide in TSRE then procedural track will not be much more efficient to path than KUJU's shapes as the processes will simply be congruent: go forward some distance, figure out the grade is wrong, back up and start over. That's not good enough.

Repeating myself for emphasis: the means the track geometry is recorded as structured data is almost irrelevant to us route builders. The work process to define the path that will be recorded by whatever means is everything. It musn't be push the path away from the existing railhead, erase and start over n times because the route builder's assumptions about direction and gradient are flawed. We have that now and it is no good.

[Goku]

Quote

Is this to say that such shapes can only be done in Blender? Or can other 3D-modeling programs be used as well?

Can be done in other software that can export to .obj and is able to adjust .obj file options.

[Goku]

Quote

Goku, there really is no separation of procedural track and the work process used to mark it's path. And that is really the whole issue. If the work process for setting down KUJU's track shapes was good then it would not matter that they were shapes instead of procedurally generated. And if the work process for procedural track is bad then it might make KUJU's approach look good by comparison.

No. Procedural shapes and track path making are completely different things. I think that 99% of the time people here are thinking "procedural tracks -> drawing path by mouse, or something" and then doesn't even know what about this topic is.
Procedural shapes are about making shapes. Nothing more!
It can be used with Kuju track placing, or with any other track placing system. These things are completely separate!

Quote

IOW, as a route builder, I do not care a bit by what means the track geometry is recorded as structured data -- by shape definition or by profile definitions, in SIMIS files or .json, it's all a don't care. I care about the work process to define its path. The means to record the definitions is important -- by all means work that problem, but if the work process to place paths in our 3d worlds is sub-optimal will people want to use it?

If you don't care about shape making or how they look, then ok - this topic isn't for you.

Quote

Here's another way to think about this matter. Let's assume you import a 2d map to use to create the path for track. By what work process will you allow the route builder to specify grades? To indicate where his tangents actually end and curves begin? Perhaps by some clever means you could figure out the 2d pathing per the image but what about the vertical? You could just let the track undulate with the terrain but as I'm sure you know, rail engineers normally don't do that on mainline paths; they add cuts and fills so any particular gradient is as long as possible. Second scenario: OSM path data is 3d; the data is not always accurate (bicycle paths over old rail ROW are not always well matched), so full xyz editing is required and sometimes the data is not even present, tho 2d maps are. The older the less likely you will find it.

My plan is to develop special attributes for JOSM https://josm.openstreetmap.de/ So that you can make perfect map of a railway (add elevation, superelevation etc.) and then import it into TSRE.
BUT IT HAS NOTHING TO DO WITH THIS TOPIC! It's for topic: procedural track laying, or osm tack data conversion.

Quote

All of us will have to deal with this pathing problem, including you, as something has to be in the code. In KUJU's code they simply allow you to tip the track shape up and down and leave it at that. If that's all you provide in TSRE then procedural track will not be much more efficient to path than KUJU's shapes as the processes will simply be congruent: go forward some distance, figure out the grade is wrong, back up and start over. That's not good enough.

How the data is stored has nothing to do how you can make it.

Quote

Repeating myself for emphasis: the means the track geometry is recorded as structured data is almost irrelevant to us route builders.

It has huge impact for route builder if he care about nice feel and look of his route.
If he wants to make his whole life MSTS shootty looking routes, then it's his choice.

[Stephen Hjellum]

So then you're not doing procedural track laying, which has zero relevance to me at this time. Don't get me wrong, I appreciate the work you are doing, but as a route builder, I have no interest in how the shape is made, I care about building the route itself; the track, the roads, etc. I'm trying to create real life, in a virtual setting, to represent routes that I know and love. KUJU's static track laying is at this time obsolete, wouldn't you agree? I agree that most of us who have been eying this thread may be a little confused about the scope of work, but maybe procedural track laying should be a focus too. Is there any reason to believe that procedural track laying may be in the near future? If not, then there's no point for me and several others to proceed with our work until that is introduced to OR. I've tried all three of the currently available modes of track laying (MSTS/ORTS, TRS, TS20XX) and am frustrated that as of 17 years after the debut of one of the best simulators out there, it still hasn't caught up with the other simulators, the best of which being TS20XX (in my humble opinion). I'm not saying you shouldn't go ahead with procedural shapes, I'm asking whether you've considered the desired implication of the track laying aspect. I'd like to hear what goals you have for implementing procedural shapes alongside procedural track laying if this is at all possible. I believe it should be possible, because other simulators have done so.
On another tangent, what would it take to accomplish procedural track laying implementation in tandem with procedural shapes?

This post has been edited by Stephen Hjellum: 06 September 2018 - 01:49 PM

[Goku]

Quote

I appreciate the work you are doing, but as a route builder, I have no interest in how the shape is made, I care about building the route itself; the track, the roads, etc. I'm trying to create real life, in a virtual setting, to represent routes that I know and love.

As a route builder I know that makings shapes is 90% of work time. So making it better and FASTER has highest priority for me.

Quote

KUJU's static track laying is at this time obsolete, wouldn't you agree?

It is obsolete and annoying but making 50 km of double tracks with geo accuracy and two very huge stations and eight smaller stations took me three days. With perfect automatic track laying how faster it would be? One day instead of three? No difference at all if then I need to spend several months to make 3d shapes ...

Quote

Is there any reason to believe that procedural track laying may be in the near future?

Of course it is in my plans. But procedural track laying can't work without procedural shapes. So, it has to be done first.