[R H Steele]

 Genma Saotome, on 22 October 2014 - 03:59 PM, said:

James, I expect are a lot of laymen who'd like that translated from the original tech into English. Might you oblige?

Here's one! I thought, for an instant, you were talking about zombies . :lol2:

Also where on the Central does this occur, everywhere? I ask because I have the route and cannot remember observing this particular problem.

Just as an aside my Nvidia Control Panel shows all the OR executables when you browse to select the program you wish - I always choose the LAA.

Edit for screenshots: This is a random sample from the Scottish Central I just took, does not prove much, except that it is confined to certain areas, others appear okay. I was surprised to find fireman banging the locomotive with the shovels. Is this something the Scottish folk do for entertainment? Looks fun and dangerous. :lol2: Extreme Steaming I believe is the term. (textures set to High Quality - NVIDIA GeForce GTX 650 Ti)
[note: shovel exercise is only apparent in camera 2]

Attached thumbnail(s)

• 
• 
• 
• 

[James Ross]

 Genma Saotome, on 22 October 2014 - 03:59 PM, said:

James, I expect are a lot of laymen who'd like that translated from the original tech into English. Might you oblige?

Let's try...

Because of the way track is typically laid out, as you'd expect, any flat horizontal textures like the ballast are all on the same plane - which means that any time they overlap they are actually in exactly the same place. Graphics cards hate this because even if you think mathematically that one should always be on top (e.g. you're drawing it second and using the depth comparison function "<=") the reality inside the GPU is that you have minute floating point errors everywhere, all the time, which leads to seemingly random bits of one texture comparing "<=" and other bits being ">". This leads to speckles and other artefacts that change every time the camera moves.

That's the problem. The fix in Open Rails is to apply a tiny adjustment to the depth of a texture (called a z-bias) which varies over the texture but which is constant while the camera moves. The current way this is done is to use the texture coordinates as input, which means that (assuming a simple triangle with a texture covering it) one corner will be very slightly closer to you than the other two. It's equivalent to a few millimetres or so.

What's going on with the UK finescale track is that they have a ballast layer underneath and a sleeper layer just above it. I think you can see where this is going... the z-bias correction doesn't push the ballast up by very much, but it's just enough that where the sleepers are not also being pushed up you get the wrong order of things. The effect should only occur when you have two layers like this which are 1) very close together and 2) have different texture coordinates.

[copperpen]

The problem with the crew sitting on the boiler is the subject of a bug report, but has nobody assigned to it yet. I have looked at the S files in Shape File Viewer and have concluded that they are being displayed using the world coordinates that are fixed in the model when made, plus the vertical component from the eng file data line. To avoid them showing like that I have commented that line in the eng file.

Edit at 11:37am
I have experimented with removing ace files from the textures folder to see what the result is with these UKFS shapes. It matters not which texture is removed, track or ties, the result is exactly the same as my picture shows. Either texture on its own shows the same action as both textures in use. With these single textures, the texture disappears and the blank shape shows instead. That does not seem to me to be a z buffering problem as we are looking at a single texture. It might not be all shapes involves, but certainly a high percentage if not all track shapes used in the Glasgow Central area are affected by this. Try the SC1M Glasgow Central to Edinburgh activity, see if you get the same as me.

I can only assume therefore that we have a situation where MSTS handles the shapes with zero problems, but OR does not have the same capability in this particular case.

Edit at 12:34

It is no big deal to continue using MSTS for some routes, as I have to use it to run the VSC routes which are all run on the train order system which OR does not support. No signals.

[Genma Saotome]

 James Ross, on 23 October 2014 - 12:02 AM, said:

Let's try...


What's going on with the UK finescale track is that they have a ballast layer underneath and a sleeper layer just above it. I think you can see where this is going... the z-bias correction doesn't push the ballast up by very much, but it's just enough that where the sleepers are not also being pushed up you get the wrong order of things. The effect should only occur when you have two layers like this which are 1) very close together and 2) have different texture coordinates.

Ok... so this problem could have been avoided by either raising the higher texture a tiny bit or merging the two textures together, right?

How close together is too close?

[roeter]

 copperpen, on 23 October 2014 - 12:47 AM, said:

It is no big deal to continue using MSTS for some routes, as I have to use it to run the VSC routes which are all run on the train order system which OR does not support. No signals.

??????????
There is no reason why routes without signals can't be used in OR.
Deadlock control and train regulation work just as well with or without signals.
Even timetables can be used on unsignalled routes, setting wait and follow commands just as for signalled routes.
I've run various tests, including reversals of AI trains etc., which all went well.

As for the UKFS textures : it appears to me that this affects straight track pieces only. Curved sections do not seem to suffer this problem.

Regards,
Rob Roeterdink

[Genma Saotome]

 roeter, on 23 October 2014 - 09:32 AM, said:

??????????
There is no reason why routes without signals can't be used in OR.
Deadlock control and train regulation work just as well with or without signals.
Even timetables can be used on unsignaled routes, setting wait and follow commands just as for signaled routes.

IIRC the software does not handle rights by class or rights by direction, correct?

Both deadlock control and train regulation in "dark" territory should be preventing inferior trains from entering a section of track between sidings if they cannot fully transit that distance and clear on the far siding by 5-10 minutes of any superior train. The same would normally apply in signaled territory as the dispatcher would tend to follow the same rules... but then the DS may have his own reasons for occasionally doing it differently. I suppose a default in signaled territory of rights by class, rights by direction would still be reasonable.

[roeter]

 Genma Saotome, on 23 October 2014 - 10:15 AM, said:

IIRC the software does not handle rights by class or rights by direction, correct?

Both deadlock control and train regulation in "dark" territory should be preventing inferior trains from entering a section of track between sidings if they cannot fully transit that distance and clear on the far siding by 5-10 minutes of any superior train. The same would normally apply in signaled territory as the dispatcher would tend to follow the same rules... but then the DS may have his own reasons for occasionally doing it differently. I suppose a default in signaled territory of rights by class, rights by direction would still be reasonable.

No, that's not (yet) supported - but neither is that supported by MSTS, so that can be no reason to keep using MSTS for such routes.
As for priority by class - in activities that will not be possible as there is no way to 'classify' trains.
In timetables, if the trains are timed throughout, you could use 'wait' commands to force priorities.
Also in timetables, using 'waitany' could be used for direction controlled priorities, allthough it would not be possible to use this in combination with alternative passing paths.
Use of 'wait' or 'waitany' does, ofcourse, require 'platforms' to be defined at relevant locations.

Regards,
Rob Roeterdink

[copperpen]

The AI traffic in the VSC routes is triggered by action points, no time interval. I will give the StL&NA a shot then, Turn of the last century railroading with nary a signal on the route.

[copperpen]

 roeter, on 23 October 2014 - 09:32 AM, said:

As for the UKFS textures : it appears to me that this affects straight track pieces only. Curved sections do not seem to suffer this problem.

Regards,
Rob Roeterdink

I have curves that show the same behaviour.

[Genma Saotome]

 roeter, on 23 October 2014 - 10:55 AM, said:

No, that's not (yet) supported - but neither is that supported by MSTS, so that can be no reason to keep using MSTS for such routes.
As for priority by class - in activities that will not be possible as there is no way to 'classify' trains.
In timetables, if the trains are timed throughout, you could use 'wait' commands to force priorities.
Also in timetables, using 'waitany' could be used for direction controlled priorities, allthough it would not be possible to use this in combination with alternative passing paths.
Use of 'wait' or 'waitany' does, of course, require 'platforms' to be defined at relevant locations.

Regards,
Rob Roeterdink

Right by Class could be recorded by adding a new parameter to the service file to hold a digit -- 1 to 5 is sufficient with 1 being superior to 2 and so on with 5 indicating an Extra. Right by direction would be considerably more difficult to record because it might be path specific; By path... or recorded elsewhere, its value would also need to be applied to the service.

Having the two values would properly and programmatically resolve all situations where two trains, absent any other adjustment, are found to be occupying the same stretch of track and to do so in a reasonably realistic manner.


What makes platforms a necessary precondition for using wait?


p.s. Rob, this is thread drift by a considerable degree... should these posts be pulled out and set up as their own thread?