[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

[Goku]

For this, there is simple solution. Use one track shapes, not 3,4. In the future TSRE will include tools that help you lay tracks this way.

[Lindsayts]

longiron, on 13 June 2017 - 12:24 PM, said:

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

This should not be an issue, the displayed track shape is generated a small length at a time (Note 1) from the centre line of the track as specfied in the track data base and from the file containing the tracks description (gauge, rail weight sleeper and ballast type etc), so everything should line up.

TDB issues SHOULD not crop up as I assume what Goku's is doing is to generate the required TDB data when one lays out the track in the route editor, so the ONLY thing changing is the way the track is displayed.

Note 1: I have done the track (and embankments) this way in my own train sim, although I do the switching using normal shape files, as this simplified the coding no end Note I do not know how its is done in other parts of the world but in Victoria (Australia) almost all new swiching (and all old switching) is done with standard components almost exaclty like a trainset, so using track shapes for switching is not a real issue

Lindsay

[Lindsayts]

An important (I think ) off topic comment...............

Earlier in this thread an OR developer said there were few active route developers, this does appear to be true. The reason's are..............

(Lindsay gets on soap box..................) :)

MSTS is seen is old hat

MSTS's editor and and tools do not run well on latte versions of Windows.

MSTS's editor and tools are diffciult to use as is.

OR itself does NOT at this stage have a route editor.

OR REALLY requires a route editor now, the justification that we will not work on a route editor as few are using it is SELF DEFEATING and is a sure way to destroy OR on the long run.

Lindsay

[Genma Saotome]

Goku, on 13 June 2017 - 11:15 AM, said:

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.

No, I don't see fast loading is TSRE. I wait 15-20+ seconds to see some scenes load.

As I said before, the OR loader thread is different from the game loop / rendering. The loader thread bears the burden of slow disk access, not the game loop. Your whole premise is based on the wrong idea.

Don't get me wrong tho, I support procedural track for route builders (tho not at all what you have in mind). But I strongly suspect the only way there can be a performance gain in-game is if it substantially reduces the draw calls relative to what one sees with instancing turned on. Logically speaking it should reduce the draw calls... but will it be enough to make a difference? Hopefully so. But the disk stuff is (IMO) a non-issue.

How do you intend to apply UV mapping to your procedural track?

[Goku]

Genma Saotome, on 14 June 2017 - 12:48 PM, said:

No, I don't see fast loading is TSRE. I wait 15-20+ seconds to see some scenes load.

Is it from HDD? If yes, then you have to change multithreading options, because TSRE is configured for SSD by default. But default options kills HDD :)

Genma Saotome, on 14 June 2017 - 12:48 PM, said:

As I said before, the OR loader thread is different from the game loop / rendering. The loader thread bears the burden of slow disk access, not the game loop. Your whole premise is based on the wrong idea.

Loader can't use many threads because of disk limitations. Procedural generator can use any number of threads. What is wrong with my idea?

Genma Saotome, on 14 June 2017 - 12:48 PM, said:

But the disk stuff is (IMO) a non-issue.

It is very big issue. All game engines use one blob file by default. But many engines support "unpacked" files (for content developers) like MSTS/OR and in this case there is massive performance drop when loading assets. SSD is not a perfect solution, because SSDs have bad performance with small files (like msts .s, .sd files).

Genma Saotome, on 14 June 2017 - 12:48 PM, said:

How do you intend to apply UV mapping to your procedural track?

My procedural objects are based on 3d shapes. You configure UV in blender or 3dsmax like for other 3d objects. "Stretchable shapes" like rails or ballast should be made 1 m length. Next UV coords are calculated based on actual length and coords from 3d shape.

[vince]

Genma Saotome, on 14 June 2017 - 12:48 PM, said:

No, I don't see fast loading is TSRE. I wait 15-20+ seconds to see some scenes load.
..........................................SNIP...........................................

Hi Dave,

It's 4.5 seconds to load the PRR-East route from my systems SSHD (E drive)

Date/time  = 6/14/2017 2:43:41 PM (2017-06-14 21:43:41Z)
BIOS   	= V1.11 (American Megatrends Inc.)
Processor  = Intel(R) Core(TM) i5-4430 CPU @ 3.00GHz 
(4 threads, 4 cores, 3.0 GHz) (CPU Internal L2 1024 KB) 
(CPU Internal L1 256 KB) (CPU Internal L3 6144 KB)
Memory 	= 7.9 GB
Video  	= NVIDIA GeForce GTX 650 (1.0 GB RAM) (nvlddmkm 21.21.13.7653)
Display	= \\.\DISPLAY1 (1920 x 1080, 32-bit, primary, 0 x 0)
Display	= \\.\DISPLAY2 (2400 x 1350, 32-bit, 2400 x 0)
Sound  	= Realtek High Definition Audio (rtkvhd64 6.0.1.7111)
Sound  	= NVIDIA High Definition Audio (nvhda64v 1.3.34.17)
Disk   	= C: (Local Fixed Disk, NTFS, 118.6 GB, 23.6 GB free)
Disk   	= D: (CD-ROM Disc, UDF, 4.4 GB, 2.7 GB free)
Disk   	= E: (Local Fixed Disk, NTFS, 238.5 GB, 59.6 GB free)
Disk   	= F: (Local Fixed Disk, NTFS, 931.5 GB, 618.7 GB free)
Disk   	= G: (Local Fixed Disk, NTFS, 1862.4 GB, 935.4 GB free)
OS 		= Microsoft Windows 10 Pro 64-bit (10.0.10586)
Runtimes   = 2.0.50727 SP2  3.0 SP2  3.5 SP1  4 Client  4 Full  4.0 Client 
Runtime	= 2.0.50727.8689 (32bit) 

regards,
vince
 PHILLY NORTH PORTAL (Custom).jpg (211K)
Number of downloads: 5
re PRR=East: First through track NB NEC Main Philly to North Philly completed this afternoon.
v

[James Ross]

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

This is currently not even an OR project - it is just TSRE5 doing its own thing. Chris, myself and Goku tried to have a private conversation back in December 2016, to get a feel for procedural generation in OR/TSRE5, where I shared a lot of details on how I'd been thinking we should describe lofted paths (the route through 3D space), but it didn't turn into a useful discussion in the end.

What I can do now is start a new thread covering all of what I said in private, and we can go from there in public instead.

[Genma Saotome]

Goku, on 14 June 2017 - 01:28 PM, said:

"Stretchable shapes" like rails or ballast should be made 1 m length. Next UV coords are calculated based on actual length and coords from 3d shape.

So here is a great example of what drives me nuts: Programmer, w/o input from any content creator, decides something important, usually choosing the option that is is easier to do.

Please DO NOT make such decisions w/o running past the people who will be affected.

Goku, rail can probably be done very well with a UV scaling of 1m. Unfortunately ballast and roadbed are highly unlikely to come out as well. 1m of something as visually obvious as ballast will very likely descend into obvious tiling patterns, if for no other reason that the art is hard to do in the first place. Ditto dirt and green stuff on the subroadbed. For myself, I would love to see ballast and subroadbed merge multiple textures upon the polys (e.g., one rock rock, scaled at X and a different one scaled at, oh, 5X, that is semi-transparent dirt.

Further, things like what's between multiple tracks might be another issue -- is ballasted or not, if it is ballasted is it flat or is there a depression? That too must be addressed.

What's needed is for the profile data to define all of the UV scaling. In the ideal the template should actually be a finished .s shape. The .s file itself no doubt contains a bunch of stuff that could be considered unnecessary, but I'm not going to assert that is so but it seems plausibly the case. At any rate, if the actual .s file contents are part of the performance problem then perhaps the application should take the .s file template and convert what is wanted to the desired format (not when the game is running but beforehand). When converted the rest of the processing is whatever the programmers can agree upon.

WRT James Ross' reply, I would tend to support the official OR position on all such matters... except that's really hard to do as so far there has been no effort whatsoever to produce an editor.

[Stephen Hjellum]

So if there is an issue with tiling, how does Train Simulator (RW) get around that? Why can't we have something similar in Open Rails? Since no one else is willing to work on an editor, I'd fully back Goku as he progresses on this project, and hopefully he and James Ross/OR Devs can merge it into the OR application. We've known for years that an editor is very much desired in the community, and since this is a freely developed, I'm comfortable with what is being provided. At least this is much more stabler than the older editors, which choke on large poly counts, correct? Or has someone found a way around that issue (I know, I'm straying off topic)? In a similar vein, would a stretchable shape have a problem with poly's?

[SP 0-6-0]

Hmm, I would say nay for poly issues if done right. Procedural generation of track has been done in Railroad Tycoon 3, in Rail Simulator/RS, in Railworks 1 & 2, in Train Simulator 20XX as examples. While each implementation has had it's own flaws or issues, The idea worked to varying degrees of success depending on how it was implemented.

Robert