[Goku]

Finally I began working on procedural track shapes.

Why procedural shapes:
- get rid of Global directory
- easy create new track templates
- possibility to have hundreds of different tracks in one route
- possibility to have "dynamic" fences, walls, platforms, bridges, wires, etc.
- in the (far) future it will be possible to make compelety procedural railway, independent of Tsection.dat shapes (for example, from OSM maps railway lines)

How will it work:

1. New files in route directory:
- ShapeTemplates.dat: definition of templates used to create procedural shapes
- Global.dat: hints how to assign shape template to shapes from Tsection.dat
- directory with .obj template files

2. Automatic mode:
If enabled, Global and all other track .S file shapes are ignored. TSRE will create procedural track shapes based on info from Tsection.dat, shape names and hints from Global.dat.

3. Shape customization:
It will be possible to assign custom template to any world object. It will be stored in .W file.
Something like:
ShapeTemplate ( TemplateName )
or:
ShapeTemplate ( TemplateName, CustomTexture )

If automatic mode will be disabled, it will be possible to hide file shape using something like
HideShape ( )


Tracks (and other procedural objects) are made from .obj shape templates. So it is very easy and fast to make new shape template.

Example:

http://i.imgur.com/uBwBF5q.png

http://i.imgur.com/BBBeOSc.png

http://i.imgur.com/CzKPKZc.jpg

Looks nice, but now it can't do more than dynatrax. It is still 90% of work to do:
- procedural xowers, switches and other complex shapes
- distance levels
- global.dat definitions

Will it work in MSTS? No. It is supposed to make the shapes realtime. It will require implementing this in OR as well.

[Stephen Hjellum]

This is a godsend, Goku! I've been waiting for this for a while, and I plan to implement procedural track on my upcoming Northern California Route. Gives me more incentive to continue adding more .kml paths and files. Thank you so much for your contributions to this community, and am looking forward to seeing ORTS soar past RW/TSW and the other sims (with the exception of R8, maybe). As for what I've seen in the screenshots so far, I'm liking the smoother track profile you have there. A question I have right now is, with implementation of procedural track shapes, will these be potentially compatible with existing shapes via tsection.dat? If so, what could be the directory structure be like? I understand it's a little early on to be asking these questions, but it is necessary for those of us following your work to get a better idea of utilizing your editor better.

[Goku]

Stephen Hjellum, on 11 June 2017 - 06:38 PM, said:

A question I have right now is, with implementation of procedural track shapes, will these be potentially compatible with existing shapes via tsection.dat?

What you mean? You will still have to use tsection.dat shapes. Only no need for .S files. But if you want, the .S files still can be used like now.
Procedural railways without tsection.dat shape definitions is something to do in far future.

Stephen Hjellum, on 11 June 2017 - 06:38 PM, said:

If so, what could be the directory structure be like?

These shapes will be generated during gameplay. No shape files and no directory structure.

[Stephen Hjellum]

Goku, on 11 June 2017 - 06:55 PM, said:

But if you want, the .S files still can be used like now.

That answers my question, thank you. Very encouraging that there is a degree of backwards compatibility.

Goku, on 11 June 2017 - 06:55 PM, said:

Procedural railways without tsection.dat shape definitions is something to do in far future.

Take your time. What you have started with is great!

Goku, on 11 June 2017 - 06:55 PM, said:

These shapes will be generated during gameplay. No shape files and no directory structure.

Therefore, independent of the current file system?

[Goku]

Stephen Hjellum, on 11 June 2017 - 07:08 PM, said:

Therefore, independent of the current file system?

It will work like msts dynamic tracks, but for everything. Msts dynamic tracks don't have files and directories too.

[SP 0-6-0]

Why have the shapes be drawn during game play? That adds alot to the already huge workload on the computer? Why not have TSRE5 do all the work of generating tracks and then converting them into shape files that are written into the routes local Tsection.dat file and then written into the world files?

Why add more to the GPU/CPU workload by forcing real time generating of the track as the train goes?

Robert

[Goku]

Because modern CPUs are much more powerful than hard drives. Generating this realtime will be faster than loading thousands of custon track shapes. Shape generation function will be simple and it will be possible to run it in another CPU threads, so no slowing the game main thread.
Shape files needs some CPU during load too.

[Csantucci]

Goku, on 11 June 2017 - 07:49 PM, said:

Because modern CPUs are much more powerful than hard drives.

Also hard drives have become much faster with the SSD generation.

Some thoughts and questions.
I wonder if it wasn't possible to avoid or at least reduce double and independent code generation (TSRE5 and OR) for the same function. It's a waste of time, considering that there are few active developers.
There is already a way to define a track profile in OR. This works, is used and it is described in the document "How to provide track profiles for Open Rails dynamic tracks". If required I can provide some example. I think that TSRE5 should conform to such document to define track profiles.
If this procedural track uses the standard dynamic track functionality and grammar, extended to the whole route, could the basic procedural track functionality run on actual OR versions (which already use dynamic tracks for both standard MSTS dynamic tracks and also for superelevation)?

[WaltN]

Goku, on 11 June 2017 - 06:14 PM, said:

- in the (far) future it will be possible to make compelety procedural railway, independent of Tsection.dat shapes (for example, from OSM maps railway lines)

Goku:

Your vision is sound. It makes sense and is practical.

Notably missing from my reading of your description is a method for a designer to describe the generative function used to generate the path that the template follows. Perhaps I did not completely follow your description.

Sorely missing from MSTS (and OR) is a method of designing a totally realistic easement curve. In the U.S., the easement function universally used in civil engineering is the spiral easement. Other countries do use functions other than the clothoid spiral. My point here is that this realization means that, unless you want to get into the business of supporting a lot of easement functions, there must be a way of allowing designers to specify them (e.g., scripting).

Also, easement curves place requirements on the methodology incorporated in the route editor. Easement curves are designed, not just drawn. In general, an easement curve is tangent to two circular curves, the circular curve ahead (C_a) and the circular curve behind (C_b), where the radius of either C_a or C_b may be infinity. This statement requires that the editor must look ahead at the radius of the circular arc ahead. Today, this would be a foreign approach to many route developers. All of this is documented in my report on Spiral Easement Design.

I applaud your agressiveness and productivity.

[Garry]

I confess that I have no understanding at all about the computing ideas being expressed here, but I do have some worries about the problems that will arise for route builders.
If we take the multi track picture from Goku's first post, and try to lay a diagonal track, with a double slip where it crosses each track shown, then repeat this with another diagonal crossing the other way, and assuming that you can get the double slips to work, you will find all sorts of problems trying to get the 2 diagonals to cross each other. Problems like this are what caused me to give up with TS2017 and come back to MSTS with its ready made points.
If you want to incorporate easements, TS2017 has them available, and there are youtube videos showing how to lay them, but I have not seen the maths behind them.
Superelevation needs to be thought about carefully. There will be some places where 2 identical curves will have different superelevations, compare a high speed main line curve with an identical curve just outside a terminus. Perhaps the degree of superelevation can be specified by the route builder, or be dependent on speed limits. However they are defined it is essential that the superelevation is visible in TSRE5. I built a double track section along a lake shore with the MSTS track laid flat on top of a quayside wall. When I looked at it in OR with superelevation the inner track was below the level of the quayside. This problem needs to seen as the route is being built. It also means that the current method of setting superelevation in the options section of OR is wrong. It must be set in each route by the route builder.
Garry