[Lindsayts]

Below is a screen shot taken for an experiment in editing LOD distance values for the trees.
I apologise for the size of the screen shot as scaling it down lost to much detail.

Note the trees in the distance on the ridge line.



The route used is the latest version of TA_VR_NE_1950s, (The main NE line to Sydney NSW from Melbourne in Vic, it appears to be no longer avaible). What was done I edited the LOD distance values of the almost all the trees. Most had two LODs, there default distance values being 2000 and 500 these were changed to 4000 and 1500. Trees below 10 metres in height were left at the default. Four trees were not done as zipper would not uncompress them. The total number done was 36 trees out of a possible 45 to 50 ( 4 not done as above the others below 10 metres in height).

The display distance was set to 4000 metres, the route has no distant mountains. The screen shot as taken just before the line cross's over the Goulburn river just south of Seymour. Normally one can see the trees being drawn on the rising ground in the distance. There was almost no sign of trees appearing out of thin aire (good!!!!!). I unfortunately did not take a note of the frame rate but it appears to have __VERY__ little effect though. Note the frame rate, 165 fps, this around what one would expect at this point before the experiment.

My initial judgement is this is a significant improvement.

I wonder if it would be worthwhile for OR to ignore the LOD distance values in the shape file and calculate there own based on the objects height from its SD file. On my system (monitor 2560x1600, viewing angle set to 26 degrees) a loading distance based on between 250 to 300 (Note 1) of the objects height has to be looked for to be seen. This value could be user set in the options menu to control the loading distance.

Note 1: Say 1800 metres for a 6 metre high telegraph pole along side the line, I found one can see these being drawn but one does have to LOOK for the effect.

Lindsay

Mass editing LOD values is __REAL__ pain I may say.............

[dennisat]

Lindsayts, on 10 April 2013 - 02:20 PM, said:

....I wonder if it would be worthwhile for OR to ignore the LOD distance values in the shape file and calculate there own based on the objects height from its SD file....

This sounds like an interesting subject for an "Experimental" option. The multitude of LOD values used in shapes often leads to some rather weird effects - for example a tower block which should really be visible on the horizon suddenly appears in the middle of other smaller, already visible, buildings when you're 500m away.

Dennis

[eric from trainsim]

Lindsay, that looks good... where did you tweak the 4000m in the source code?

As for mass-updating of LOD's... it might be a good use for GrepWin...

Select the files you want to alter, and do a search on "dlevel_selection ( 2000 )" and replace with "dlevel_selection ( 4000 )"

[ChrisD]

eolesen, on 11 April 2013 - 01:51 AM, said:

As for mass-updating of LOD's... it might be a good use for GrepWin...

Select the files you want to alter, and do a search on "dlevel_selection ( 2000 )" and replace with "dlevel_selection ( 4000 )"

This means that the shapes must be decompressed, but this also takes care of the shapes that reports ILLEGAL DATA when inspected by Archibald.

I have left the altered shapes uncompressed, and apart from a few extra MegaBytes, OR seems not to mind. :)

Are You proficient with GrewWin?

Maybe a script can be made to convert the built-in global/shapes after all. A script does not violate any copyright, so this may be the way forward.


Maybe one from the OR Team reads this, I have an idea.

The routine that calculates DM should scan the tile layers from 4 - 20 Kms for shapes with LODS higher than 4000 and include the objects in the DM scenery.
This way a high rise building could be visible from say 10 or 15 Kms just like in real life.

If OR has this feature added, I am sure shapes with increased LODs will start to appear in new Routes.

ChrisD

[eric from trainsim]

Now that I think about it, it wouldn't event take modifying the shapes.

You could do it directly in the code --- ignore LOD's > 1999, and just apply the max available.


I'll admit I'm dangerous with GrepWin, but won't consider myself highly proficient... :) I've had to back out several "whoops" moments.

[ChrisD]

eolesen, on 11 April 2013 - 08:02 AM, said:

Now that I think about it, it wouldn't event take modifying the shapes.

You could do it directly in the code --- ignore LOD's > 1999, and just apply the max available.


I'll admit I'm dangerous with GrepWin, but won't consider myself highly proficient... :) I've had to back out several "whoops" moments.

Better Yet, Buddy. Notepad++ is much better and does not fail. Here is how:

Backup Your SHAPES to a new SHAPES-BU folder to keep originals safe.

Use TSUtil to decompress all shape-files in the route You want to enhance.

TSUtil creates a new Folder called newRoute where a new SHAPES Folder is filled with the decompressed shape-files.

Now load the first file into Notepad++ and select Search, Replace, Find in Files.

Find what: "dlevel_select ( 4000 )"
Replace with "dlevel_select ( 10000 )"
Filter: "*.s"

Directory: point to the dir with the uncompressed shape-files.

Search mode: Normal.

Now click Replace in Files and ack when asked to process without backups.

When Notepad++ returns it tells You how many files it did process. (This first run may be empty if no large objects is in Your route, but just go on).

Replace the 4000 with 2000, and the 10000 with 4096 and do it again.

Here are the corresponding values, be sure to process them in this order if You do not want to mix things up.

Initial value, replace with:

4000 - 10000
2000 - 4096
1500 - 4000
1000 - 3500
800 - 2750
500 - 750
400 - 600
375 - 675
350 - 550
300 - 500
250 - 360
200 - 300
100 - 225

Not all values entered will find shapes to alter, it all depends on the Route which shapes You are processing.

When You are done, You can check for shapes that You missed by checking the datestamps. All files processed by Notepad has their Datestamps altered.

There may be a few shapes with odd LOD levels left over to You to process by hand using Archibald, but I am 99% sure we got them all.

Now copy the new shape-files on top of the old ones in the Route/Shapes folder.

Open Rails do not mind that the shape-files are uncompressed. You just need about 500 Mb of extra Disk-space per Route. (Who cares these days) :oldstry:

Now fire up OR and enjoy a whole different train ride. :yahoo:

Good Luck. :bad: Thank You OR for making this possible. ;)

ChrisD

[Genma Saotome]

I did some experimenting with editing the .s file to push visibility out to 4000m. It works (good) but IMO the model better be very few polys (or greatly LOD'd) because at such a distance even structures hundreds of feet tall are not going to be much more than a silhouette on the horizon. That said, they do make the scene look much more realistic.

[Lindsayts]

eolesen, on 11 April 2013 - 01:51 AM, said:

Lindsay, that looks good... where did you tweak the 4000m in the source code?

It was not done in the source, the shape files were edited directly. Items taller than 10m were set to 4000, items less than that were set to 1500.

Quote

As for mass-updating of LOD's... it might be a good use for GrepWin...

Select the files you want to alter, and do a search on "dlevel_selection ( 2000 )" and replace with "dlevel_selection ( 4000 )"

I will look into this (Note 2), once I figure out how to use the standard unix tools on 2 byte character sets altering large quantity's of files will be little effort.

Note 1, my main OS is Linux and has been for 20 years now, Windows is only used for MSTS and Openrails.

Note 2, "grep" is a standard unix command line tool for "pattern match" searching in a text file. One can then use "cut" and "cat" to replace text using a script, thats just one way as usual in unix there would be half a dozen other ways to do the same thing, one could use "awk" for instance. Makes repetitive alterations a breeze.

Lindsay

[Lindsayts]

eolesen, on 11 April 2013 - 08:02 AM, said:

Now that I think about it, it wouldn't event take modifying the shapes.

You could do it directly in the code --- ignore LOD's > 1999, and just apply the max available.


I'll admit I'm dangerous with GrepWin, but won't consider myself highly proficient... :) I've had to back out several "whoops" moments.

A comment on this then a question and another comment

Thats why one _____ALWAYS______ does this sort of thing on backed up files, I copied the entire SHAPE directory to a couple temporary directories, then copied the results back.

The question, I have had trouble decompressing everything "Zipper" was used from the "TKutils" package it only decompressed 209 of 520 objects, is there another program I can use or how can I get around this issue.

ChrisD.......

Sounds like the way to go.
I had a look at the TSutils package I did not think it contained a decompression program, may need to take a longer look. I will give Notepad++ a go.

Lindsay

[Lindsayts]

Genma Saotome, on 11 April 2013 - 11:09 AM, said:

I did some experimenting with editing the .s file to push visibility out to 4000m. It works (good) but IMO the model better be very few polys (or greatly LOD'd) because at such a distance even structures hundreds of feet tall are not going to be much more than a silhouette on the horizon. That said, they do make the scene look much more realistic.

From what I have done this does not appear to be a serious issue, the increased realism far out ways any disadvantages.

It all depends on the scene, one can clearly see the fence alongside the line being drawn at 1500 metres distance but with the trees set to 4000 metres one almost __never__ sees them being drawn.

The GPU processing power __SO__FAR__ does not appear to be an issue. I added 20 more items, 18 more trees and a couple of fences the frame rate of OR did NOT vary at all and in quite a bit of driving one only sees a __VERY__ occasional tree being drawn, MUCH better.

(total number of items edited being 56, this being over 10 percent of the routes SHAPES directory)

I hope some consideration that something like this can be included in an experimental feature, as there is a considerable problem in the editing all those shape files for every route. I have not been able to get all files to decompress :) :oldstry:.

Lindsay

[Lindsayts]

Hmmmmmmmmmmmmm...........

A search shows there,s at least 3 tools to uncompress files, I will need to give some others a try.

I will let you know of progress, it would be nice to find a relatively straight forward way to edit the LOD values, ChrisD's method certainly looks interesting.

Lindsay

[Genma Saotome]

Lindsayts, on 11 April 2013 - 12:07 PM, said:

The GPU processing power __SO__FAR__ does not appear to be an issue.

Same here. My concern is about what the CPU has to do in order to pass data to the GPU. Extending the view distance of static objects beyond 2000m is adding work to the system. If the system is already CPU bound AND frame rates are under 60 more CPU work will simply further reduce the visible fps. As the CPU work includes processing shape data it's simply better to LOD away as much of that data as possible. That's all. If, OTOH, fps are always over 60 then it is a don't care situation: go for it.

[Genma Saotome]

Lindsayts, on 11 April 2013 - 12:07 PM, said:

The GPU processing power __SO__FAR__ does not appear to be an issue.

Same here. My concern is about what the CPU has to do in order to pass data to the GPU. Extending the view distance of static objects beyond 2000m is adding work to the system. If the system is already CPU bound AND frame rates are under 60 more CPU work will simply further reduce the visible fps. As the CPU work includes processing shape data it's simply better to LOD away as much of that data as possible. That's all. If, OTOH, fps are always over 60 then it is a don't care situation: go for it because whatever the extra cost is you won't actually see it.

[Genma Saotome]

Lindsayts, on 11 April 2013 - 12:07 PM, said:

The GPU processing power __SO__FAR__ does not appear to be an issue.

Same here. My concern is about what the CPU has to do in order to pass data to the GPU. Extending the view distance of static objects beyond 2000m is adding work to the system. If the system is already CPU bound AND frame rates are under 60 more CPU work will simply further reduce the visible fps. As the CPU work includes processing shape data it's simply better to LOD away as much of that data as possible. That's all. If, OTOH, fps are always over 60 then it is a don't care situation: go for it because whatever the extra cost is you won't actually see it.

[Lindsayts]

Genma Saotome, on 11 April 2013 - 12:38 PM, said:

Same here. My concern is about what the CPU has to do in order to pass data to the GPU. Extending the view distance of static objects beyond 2000m is adding work to the system. If the system is already CPU bound AND frame rates are under 60 more CPU work will simply further reduce the visible fps. As the CPU work includes processing shape data it's simply better to LOD away as much of that data as possible. That's all. If, OTOH, fps are always over 60 then it is a don't care situation: go for it.

Need to do some more experimenting, for this need an easy way to convert a lot of shapes. Thankfully I have just found out how to convert UTF-16 to and from an 8 bit character set, this makes the job a trivial exersize on unix.

At the moment the 52 shapes chosen appears to have effected the frame rate not at all, which is a bit of a surprise. Mind you the shapes have all been selected for use in a rural setting where routes traditionally do not have a high object density and one can usually see a long way. Another point to consider is the system is a fast system put together specficly for 3D animated work.

Visibilty of objects in high density areas (in city's and mountain routes) is not really an issue as usually viewing distance is not far or far objects are obstructed by closer items. A case in point here would be the Bernina Bahn route. A viewing distance of 4000m made a lot of diffence but one rarely sees an object being drawn.

System is..

MB ASUS P6X58D Premium, 3 channel memory bus
CPU i7 950
GPU Radeon HD 5870 (there is a 7870 waiting in the wings to replace it).

Lindsay