PDA

View Full Version : 70337:70059 track



martinvk
June 2nd, 2015, 09:32 PM
Issue: LOD reduction is not enough to prevent triggering a faulty error in build 3.9.
I added extra polys to LOD0 and added LOD-level tags which suppressed the error that was triggered when using build 3.9. Build 3.7 did not produce the error.

kuid <kuid2:70337:70067:1>
username "TANE Trk Con3 Mesh7"
kind "mesh"
trainz-build 3.9
category-era "2010s"
category-class "HM"
category-region "00"
mesh-detail-level-count 4
mesh-table
{
sleepers-lod0
{
mesh "sleepers_lod0.im"
auto-create 1
lod-level 0
}
sleepers-lod1
{
mesh "sleepers_lod1.im"
lod-level 1
}
sleepers-lod2
{
mesh "sleepers_lod2.im"
lod-level 2
}
sleepers-lod3
{
mesh "sleepers_lod3.im"
lod-level 3
}
sleeper_single-lod0
{
mesh "sleeper_single_lod0.im"
lod-level 0
}
sleeper_single-lod1
{
mesh "sleeper_single_lod1.im"
lod-level 1
}
}
The sleeper single LOD0 mesh 58 polys
http://doei.ca/images-trainz/TANE 76536 sleeper single LOD0.JPG
The sleeper single LOD1 mesh 22 polys
http://doei.ca/images-trainz/TANE 76536 sleeper single LOD1.JPG
The sleepers LOD0 mesh 700 polys
http://doei.ca/images-trainz/TANE 76536 sleepers LOD0.JPG
The sleepers LOD1 mesh 540 polys
http://doei.ca/images-trainz/TANE 76536 sleepers LOD1.JPG
In game, the transition from high to low detail happens at 10m. If you look very carefully, you can just see it by looking at the chairs, which have the same LOD-distance value
http://doei.ca/images-trainz/TANE 76536 LOD test 1.JPG
and
http://doei.ca/images-trainz/TANE 76536 LOD test 2.JPG


high-detail
{
lod-distance 10
subdivisions 1
high-detail
{
mesh "sleepers-lod0"
}
low-detail
{
mesh "sleepers-lod1"
}
}

martinvk
June 2nd, 2015, 09:44 PM
http://doei.ca/images-trainz/TANE 76536 LOD0.JPG
http://doei.ca/images-trainz/TANE 76536 LOD1.JPG
http://doei.ca/images-trainz/TANE 76536 LOD2.JPG
http://doei.ca/images-trainz/TANE 76536 LOD3.JPG

WindWalkr
June 3rd, 2015, 12:00 AM
Okay, a couple of quick notes on this one:


* I think you're talking about the mesh-table LOD warnings/errors, but you're talking about a spline object. As noted elsewhere, splines don't use mesh-table LOD, and the warning/error is misleading. This will be addressed without you needing to do anything.

* You say that the LOD0-LOD1 sleeper drops from 58 to 22 polygons. Then you say that the LOD0-LOD1 overall drops from 700-540. The first number (38%) sounds reasonable; the second number (77%) sounds a lot less worthwhile. Can you explain where this difference is coming from?

* A lot of the LOD benefit in a modern track spline comes from lengthening the mesh, dropping out the sleepers and finally dropping basically all detail at extreme range. As you can see from the numbers above, if you don't do that then the numbers (although small per repeat) add up very quickly. Parts of the mesh which disappear should be moved into the texture and normal map to avoid an obvious visual change.

chris

andi06
June 3rd, 2015, 02:05 AM
Chris, I don't disagree with anything you say but LOD on procedural track is a nightmare.

You have a collection of half a dozen splines acting as one, all of them have their own independent lod schemes with different cut-in distances and mesh-lengths. As a result almost every change of viewpoint or zoom is creating a visual pop somewhere or other. This is compounded by the point at which shadows cut in and out which creates a strong change of density.

I spent half an hour last night refining the rendering of meshes to almost hide the LOD changes. Problem is that this will only work for one angle of view - if you raise or lower the observer the whole thing changes.

Not only does this give an asset which is changing meshes much more frequently, it also happens to be probably the second most visually prominent item in a train simulator!

The second implication of six assets is that it will be really easy to wreck performance by adjusting lod parameters. Presumably procedural-track has a performance penalty which is higher than the older tracks but we have no way of knowing how well the assets we are making are working. Can you provide any way of benchmarking them?

martinvk
June 3rd, 2015, 06:57 PM
Okay, a couple of quick notes on this one:


* I think you're talking about the mesh-table LOD warnings/errors, but you're talking about a spline object. As noted elsewhere, splines don't use mesh-table LOD, and the warning/error is misleading. This will be addressed without you needing to do anything.I used the build-in procedural track config as a basis for my config, The mesh table LOD was only added to suppress the warnings that prevent me from using build 3.9. Once it is addressed at the code level, I can remove it.


* You say that the LOD0-LOD1 sleeper drops from 58 to 22 polygons. Then you say that the LOD0-LOD1 overall drops from 700-540. The first number (38%) sounds reasonable; the second number (77%) sounds a lot less worthwhile. Can you explain where this difference is coming from?The 58 to 22 poly drop is for sleeper-single LOD0 to LOD1 whereas the 700 to 540 poly drop is for sleepers LOD0 to LOD1. Two different mesh sets.


* A lot of the LOD benefit in a modern track spline comes from lengthening the mesh, dropping out the sleepers and finally dropping basically all detail at extreme range. As you can see from the numbers above, if you don't do that then the numbers (although small per repeat) add up very quickly. Parts of the mesh which disappear should be moved into the texture and normal map to avoid an obvious visual change.I had originally done just that, simply lengthening the mesh but the longer ones have the same number of polys, just stretched, and the trigger mechanism doesn't seem to notice or care that the polys per meter have dropped by more than 50%.

You statement implies that the various LOD levels communicate with each other so if the sleepers are dropped at a certain point and the track poly count stays the same, then overall poly count is reduced. The error /warning process notices and doesn't trigger. Right?

One thing I also did was to synchronize the LOD-distance values between all the meshes. Would it be better to have the various meshes transition at different distances and so spread out the load on the system?

pcas1986
June 3rd, 2015, 08:25 PM
I've never made track before so, like MartinVK, I've also been copying the N3V structure and mesh sizes for guidance. One of my test tracks only uses plain colours so I can see where LOD changes. The picture below has some interesting combinations and, as Andi pointed out, there is a lot of "popping" going on even when rotating a view.

The colours in my track meshes are:

LOD0 - red (note this includes the one LOD level components such as blades)
LOD1 - yellow
LOD2 - blue
LOD3 - green

At LOD3 the track is barely visible so the mesh should really contain painted rails and sleepers. The Auran Oak Track mesh library and sleeper asset has a LOD3 sleeper mesh which seems redundant.
The LOD0 single sleepers can be seen at some distance so implementation of LOD1 should be a matter of priority. I did read it was on the list. Ditto for single chairs.
If you are not doing it already I'd suggest automatic culling of blades, single chairs, single sleepers and stretchers at LOD3.

In the shot below I couldn't get my LOD0 track (ballast, rails and chairs) in view but it is there.



http://i1188.photobucket.com/albums/z410/casper131/Ashampoo_Snap_2015.06.04_10h45m47s_001__zpsvxipock q.jpg

Finally, I noticed this at some spline points. The insertion of a spline point adds a LOD0 sleepers mesh. If I move the spline point around the number of red sleepers varies and sometimes will disappear altogether. But if it remains, as shown below, the same LOD0 sleepers show at any distance including LOD 3. I know my meshes are not correct yet (see the odd gaps) but I wonder if this is a bug.

http://i1188.photobucket.com/albums/z410/casper131/Ashampoo_Snap_2015.06.04_11h13m58s_003__zpsaskpfwh x.jpg

martinvk
June 3rd, 2015, 09:20 PM
The insertion of a spline point adds a LOD0 sleepers mesh. I think that is a function of the LOD-length tag and whether or not there is space to use the single sleeper.

pcas1986
June 3rd, 2015, 11:31 PM
I think that is a function of the LOD-length tag and whether or not there is space to use the single sleeper.

I just realised this version of track has not been updated for the new(ish) tags so I'll fix those and see what happens.