[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

[Lindsayts]

A comment on the concerns of Genma Saotome and nyc01.........

Now I am not saying this should be mandiatory, that is essential the way it would be by editing the LOD distance values. Calculating the distance values on the fly when the shape is loaded allows control over the whole procedure allowing the loading distance to be set to suit the route being run. Systems running OR will vary all over the place a fixed loading distance really does not go with the modern advances in hardware.

Now if one has a look back on my past posts I am __NOT__ and never will be a supporter of "eye candy" but the increased loading distance avaibile seriously improves the realism and this __IS__ something the interests me.

This current work is just an experiment to see what and to show what is possible I am NOT holding a gun to anyones head here.

As already mentioned some routes go quite well without increases in loading distance others such as most of the routes in country Australia where population is relatively low will benefit from it thats why I would like it to be user setable.

One hopes in the end OR will be flexible enough to allow everyone to chose the type of realism they wish after all I believe OR is intended to be the best train sim.

Note, I am biased here I am not a fan of routes crammed with detail and has had accuracy compromised because of it.

Lindsay

[Genma Saotome]

 Lindsayts, on 11 April 2013 - 05:37 PM, said:

A comment on the concerns of Genma Saotome and nyc01.........

Now I am not saying this should be mandatory, that is essential the way it would be by editing the LOD distance values. Calculating the distance values on the fly when the shape is loaded allows control over the whole procedure allowing the loading distance to be set to suit the route being run. Systems running OR will vary all over the place a fixed loading distance really does not go with the modern advances in hardware.

I do agree that the modeler should not have the only voice in setting up a LOD... in fact, he probably is good only for the judgement call of selecting those polys that are (1) going to have a lot of pixels culled anyway and/or (2) is at some odd angle of presentation that means it'll be visible only close up. IOW, situations where poly size is not the determining factor.

When poly size is the determining factor there's no reason not to use some programmatic means to evaluate the poly size and assign it a LOD... preferably taken from a limited set of values rather one of an infinite number of values based purely on size. Whether this happens at shape load time or at some time between CAD and game can be left to others to decide. Ideally the LOD distance value be determined by the screen resolution.



Which reminds me... so long as we're discussing an aspect of the mesh definition and performance, a very significant boost to performance could be obtained by figuring out what placed objects in view are identical and to "persuade" the GPU to render them as-if they were just one instance (i.e., one set of draw calls instead of one set per placed object). Another may well be replacing individual track shapes with a procedurally generated shape, something that again would require far fewer draw calls. Last, converting identical individually placed trees into shapes of many identical trees would also require fewer draw calls.

IOW, using LOD's isn't the only way to improve performance en-route to getting longer view distances.

[ChrisD]

Friends, No need to worry so much. :jumpy:

What we are dealing with here, is a quick and dirty way of "enhancing" 5+ Years Old MSTS Routes.

What we are doing is blasting medium res shapes with textures to be shown at 2+ Kms.

After loading the shapes, Your Graphics Card goes to work and reduces the shapes to simple or very low res shapes with no Textures.

At 2 Kms most objects is in black and white only.

This approach is taxing the Graphics Card hundreds of times more than necessary, and still it does not seem to degrade performance very much.

A Route made in 2013 for Open Rails will have trees with 3 or 4 LODS where the low res LOD will be only a very few triangles and no textures.

Existing trees may be "enhanced" by adding a third very low res LOD and keeping the 2 existing LODS at their initial settings.

Normally a quater of Your screen displays distances between 1 and 4 Kms. At Full HD this is approx 480 x 1280.

In order to see anything we need one pixel on and one off, and then we end up with 153 KiloPixels.

Even a low end Graphics Card will deal with this amount of detail without a sweat.

This "overkill" use of Graphics Power is only temporary, so I think we do not need to worry. :thumbup3:

Now we need someone that can "enhance" the existing Trees with a 3rd LOD or a series of replacement trees.

I am sorry to say that I can be of no help here.

Good luck with Your "enhancements", let us in on them here.

ChrisD