[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?