[eric from trainsim]

As long as procedural track is in addition to shape defined track, I don't see a problem.

Little things like guard rails, frogs, animated points, switchstands, etc. matter. If that can't be done procedurally, then this has to play nice with the existing track systems.

Superelevation should be defined as part of the track section in question, and not done globally or at the route level.

[Goku]

Csantucci, on 11 June 2017 - 10:57 PM, said:

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.

I will prepare c# functions for OR. Someone will have to just implement it.

Csantucci, on 11 June 2017 - 10:57 PM, said:

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.

This track profiles works only for simple tracks. My code will work for everything and not only tracks.
OR track profile is limited to 2d shapes only. My profiles will use 3d .obj files. It is much more powerful solution.

Quote

Superelevation should be defined as part of the track section in question, and not done globally or at the route level.

Thos will be done in TSRE too. Also, superelevation is another reason why track shape files are stupid, because you need to gereate procedural tracks anyway.

Quote

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

It is not possible, because you need better solution to create:

Quote

Little things like guard rails, frogs, animated points, switchstands, etc.

[longiron]

WaltN, on 12 June 2017 - 04:51 AM, said:

Goku:

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

I applaud your agressiveness and productivity.

Walt,
As a route builder, I, too, am excited about the possibilities. More that 1 track type, among others. From my limited understanding, I'm assuming Goku's approach does nothing to address the "curve on a grade" challenge with MSTS track shapes. We are still stuck with flat plywood - correct?

[WaltN]

longiron, on 12 June 2017 - 09:20 AM, said:

Walt,
As a route builder, I, too, am excited about the possibilities. More that 1 track type, among others. From my limited understanding, I'm assuming Goku's approach does nothing to address the "curve on a grade" challenge with MSTS track shapes. We are still stuck with flat plywood - correct?

His method CAN account the proper helical shape of an arc on a grade. What I don't know is whether he's aware of the MSTS problem.

[Genma Saotome]

I have no problem with the concept of procedural track (and roads) when the shape is determined by a template we can edit (as described above). It's a data driven process and I strongly endorse such methods.

What I am concerned about is (again) this is not coming out of a discussion with the core OR management team. There is no evidence of cooperative design and no evidence the implications are understood well enough to have some grasp of the consequences, both the code and performance. On the contrary, there is plenty here to indicate nothing of the sort has occurred. IOW it is a typical OR project loose cannon careening across a pitching deck. Is anyone at home to pick up the phone???

[roeter]

Genma Saotome, on 12 June 2017 - 07:50 PM, said:

What I am concerned about is (again) this is not coming out of a discussion with the core OR management team. There is no evidence of cooperative design and no evidence the implications are understood well enough to have some grasp of the consequences, both the code and performance. On the contrary, there is plenty here to indicate nothing of the sort has occurred. IOW it is a typical OR project loose cannon careening across a pitching deck. Is anyone at home to pick up the phone???

I very much agree with what's said above.
I'm greatly worried by the impact of any changes to the .tdb data structure as a result of the switch to procedural track. The .tdb is not just about displaying tracks - it is the core of everything which has to do with placing or moving anything which has any relation to tracks (and .rdb to roads).
A simple check in the compiler for references to the 'TrackNode' variable shows 173 references in over 20 modules.
When it is stated that "all required C# code will be provided", does that mean the required update to all these 20+ modules? And, ofcourse, the present structure will have to be maintained in parallel to the new structure, as existing routes will clearly not be converted.
And worse - that update to those 20+ modules will have to be in place and up and running before even a single millimeter of procedural track can be laid. For without it, OR cannot run using such a route, as nothing can be placed and no train can move, because all placement and movement is based on the 'traveller' module, and that is based on the present .tdb structure.
That 'traveller' module is a very complex piece of code, and I don't think that anyone with knowledge of that bit of code is overjoyed by the prospect of changes to it. Similar for the derivation of TrackCircuitSections - the core of everything which has to do with signals and train control. That too is based on the present .tdb structure, and that too is quite complex.
Ofcourse, it could be that the .tdb structure need not be changed - but there is no statement to this. But given how things are described, and based on previous discussions, I would be greatly surprised if that could all be done using the present .tdb structure.
Clarification on this, and proposals on both the new structure and the way the required changes are to be implemented, would be very welcome before work is started on the editor.

Regards,
Rob Roeterdink

[Goku]

roeter, on 13 June 2017 - 07:44 AM, said:

I'm greatly worried by the impact of any changes to the .tdb data structure as a result of the switch to procedural track. The .tdb is not just about displaying tracks - it is the core of everything which has to do with placing or moving anything which has any relation to tracks (and .rdb to roads).

There will be no changes in TDB files at all. It's just different way of creating shapes.

Except, if we will want to address this issue:
Superelevation should be defined as part of the track section in question, and not done globally or at the route level.

[Goku]

Quote

What I am concerned about is (again) this is not coming out of a discussion with the core OR management team.

Discussions, planning, etc. can take years.
When it will be done, you'll gonna like it, or not. I spend most of the summer with family, so I think september is good estimate when it will be done in TSRE.
Sepntember - December: suggestions/fixes and implementation in OR.

[Goku]

Csantucci, on 11 June 2017 - 10:57 PM, said:

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

In TSRE, creating this crazy 35000 poly 500m track takes 2ms for generation + 2ms opengl initializaion = 4ms.
http://imgur.com/CzKPKZc
Loading similar complex .S shape file from SSD is > 20 ms. And TSRE loading time is fast - you see how fast routes are loaded into TSRE.

I think it is because files on disk are compressed and ZLIB decompression takes some time. Also .S files have lots of unnecessary things for simple shapes you need to load.

[longiron]

Goku,

If you move forward on procedural track shape generation, can you fix the problem with MSTS curve shapes laid on a gradient. The result is misalignment between successive curved track sections (especially 3/4 track sections) for the inner or outer rail. The net result is very uneven and jumpy track. If you need to understand the problem in more detail, WaltN can explain the issue and resolution. I can certainly illustrate the problem on a route.

Thanks in advance

chris