PDA

View Full Version : LOD transitions occur closer in T:ANE



Dinorius_Redundicus
June 13th, 2015, 02:27 AM
It seems that yet another goal-post has been moved for content creators. The distance at which LOD transitions occur is less in T:ANE than it was in TS2010. I can't speak for TS12 as I don't have it.

I did some testing using a scenery asset with a 5-tier mesh-table LOD system on a clean, 1-board map in both TS2010 and T:ANE. Same settings for sky, draw distance (3000m), scenery, texture quality etc.

This table shows the LOD transition distances in metres from the object when moving away from it. The triangle counts include a temporary 12-tri marker cube to tell me which LOD is displaying.





LOD #

TS2010

T:ANE

Triangles



lod0

0.0

0.0

3668



lod1

93

65

2918



lod2

145

115

2053



lod3

292

265

1527



lod4

545

515

508







As you can see, transitions in T:ANE always kicked in about 30 metres closer to the object than they did in TS2010. This makes it even more difficult to make substantial reductions in poly-count while avoiding very visible transitions, especially in large objects like this one.

Not a welcome change N3V. Can we at least get it back to where it was with TS2010?


http://i570.photobucket.com/albums/ss147/deane_tunaley/Trainz/LOD20experiment20TS2010.jpg~original


http://i570.photobucket.com/albums/ss147/deane_tunaley/Trainz/LOD20experiment20TANE.jpg~original

Edit: **That should be build 75971**


.

pcas1986
June 13th, 2015, 03:33 AM
Is this using mesh-detail-level-count?

The LM lod version is definitely suspect in TANE and I reported it in the beta bug system some time ago. It stays at lod0 for some time, then quickly transitions through lod 1 and 2 with lod3 very close behind. Since my lod3 loco meshes are basically boxes it looks very crappy.

I think part of the problem with tall buildings is that lod0 is going to hard to see except close up.

Dinorius_Redundicus
June 13th, 2015, 04:38 AM
Yes, it uses mesh-detail-level-count. That's what I meant by "mesh-table LOD" (as opposed to LM.txt LOD).

Not sure what you mean by "lod0 is going to hard to see except close up". The building is visible out to at least 1 km, but lod0 only displays for the first 60 - 90 metres (depending on Trainz version) before lod1 comes in. It's proved very difficult to knock polys off without seeing it twitch or seeing parts suddenly disappear. Having transitions occur 30m closer in TANE than they did in TS2010 just makes it impossible to do a good job on such a building. I'm crying "foul" on this one. It's unfair on creators in its current state.

Reading all the forum posts about TANE lately, it's hard to believe there are any sub-systems in it that don't have problems! I reiterate that I was doing all this with build 75971, but I see there's a patch to build 76536 available, so I will re-test in that. Can we dare hope they have rectified the situation in that build?


.

pcas1986
June 13th, 2015, 05:39 AM
This is a shot of my Prospect Breaker coal breaker for the LWVRR route. It's a very large building. The visible mesh is a LOD1 which doesn't have the window cills. Getting close in Surveyor is hard but the cills only become visible when all I can see is three windows.


http://i1188.photobucket.com/albums/z410/casper131/Ashampoo_Snap_2015.06.13_20h26m33s_008__zpsuqbnovb g.jpg
The texture looks washed out as well so that's something else to fix.

I'm using both 76401 and 76536 and it looks the same in both.

andi06
June 13th, 2015, 05:41 AM
LOD distances are supposed to be guides which the software varies for performance reasons. So what you are seeing may be an indicator of general perfomance issues?


It's proved very difficult to knock polys off without seeing it twitch
I've found this with track and also, after working very hard to get invisible transitions on the assets when viewed from the train, I find that if I move up or down in the world and change my point of view then those 'invisible transitions' become glaringly obvious horrors.

VinnyBarb
June 13th, 2015, 05:43 AM
Is this using mesh-detail-level-count?

The LM lod version is definitely suspect in TANE and I reported it in the beta bug system some time ago. It stays at lod0 for some time, then quickly transitions through lod 1 and 2 with lod3 very close behind. Since my lod3 loco meshes are basically boxes it looks very crappy.

I think part of the problem with tall buildings is that lod0 is going to hard to see except close up.

Are you sure for TANE it is the LM text LOD version you mean? As my created TS12 locomotives and some of my TS12 scenery objects with animation and hence using a LM text file for LODs change LODs in TANE where they are meant to be and where these are referenced in the LM text file.

VinnyBarb

WindWalkr
June 13th, 2015, 07:01 AM
LOD distances are supposed to be guides which the software varies for performance reasons.

This is definitely true to an extent, which is why we encourage people not to fixate on the exact numbers involved, but it's also true that T:ANE should typically provide as good or better visuals as TS12 given the same inputs. If there's a regression in this case then it's probably not deliberate and is likely the result of the differences in how Jet and E2 calculate LOD transitions; ie. it's quite possibly a bug in our compatibility layer.



..after working very hard to get invisible transitions on the assets when viewed from the train, I find that if I move up or down in the world and change my point of view then those 'invisible transitions' become glaringly obvious horrors.

That is always a danger when focusing too hard on how things look from a specific angle. To some extent the "view along the track" is the most important, but that doesn't mean that we can completely dismiss other views. I'm not entirely sure what you've tried here, so it's hard to offer suitable suggestions. Perhaps you might want to start a thread on this. I should start off by saying that the normal map is incredibly important to preserving lighting during LOD transitions- if you flatten things out in the geometry then you must compensate for that in the normal map or there will be obvious variations in the intensity of the light on that surface, ie. one LOD will look darker than the neighbour even though the texture color is the same. Beyond that, silhouette is important, obviously..

chris

Pencil42
June 13th, 2015, 10:20 AM
I noticed, when playing with upgrading a boxcar, that the distances in the .lm.txt file may be igonored. I was trying to push out the far lod (which was just a textured box) by changing the numbers in the .lm.txt file without success. I added another lod before the lowest (going from 3 to 4 lods) without changing the transition distance for the lowest LOD, and all of a sudden, the low lod transition point was farther away.

Curtis

Dinorius_Redundicus
June 14th, 2015, 01:41 AM
....I see there's a patch to build 76536 available, so I will re-test in that. Can we dare hope they have rectified the situation in that build?

Tested build 76536 today. No change from previous build, the LODs still transition 30m closer to the object than they do in TS2010.

ZecMurphy
June 14th, 2015, 08:34 AM
Hi Deane
I have a funny feeling that this change actually occurred in TS12. Is the asset on the DLS? As I'd like to have a look here.

I do remember that the 'lm.txt' format LOD changed quite significantly between versions, as some content I made for TS2009 was having LOD transitions occur horribly quicker in the newer version. But I honestly can't remember when the change occurred...

Regards
Zec

Dinorius_Redundicus
June 14th, 2015, 09:36 AM
The version pictured is an update not yet on the DLS, but previous versions are (see Grain silos MFA, kuid2:68213:27083:X). In fact the impetus behind the update is primarily to undo the damage to its LOD system done by N3V when they modified kuid2:68213:27083:2 and made it a built-in asset in TS12. The N3V-modified version recently showed up on the DLS as kuid2:68213:27083:3.

But you shouldn't need this asset in particular - just find any Kind scenery asset from TS2010 with a non-LM.txt LOD setup and measure its transition points in TS2010, TS12 and TANE. I would expect any code changes to affect all LOD-enabled scenery in the same way.

.

whitepass
June 14th, 2015, 10:26 AM
The LOD lm.txt significantly changed from TRS4 to TRS6 and now from TS12 to TANE, I had this on my updated Alco PA1 that was done in TS12.

clam1952
June 14th, 2015, 10:28 AM
I'm not actually seeing any noticeable difference with scenery items between TS12 and TANE.
Practically I think a lot of the pain with scenery lod could be eased by either increasing the set distance? Or allowing creators to set the distance to something within reasonable set limits to something a bit more manageable?

TRam__
June 14th, 2015, 10:48 AM
Or allowing creators to set the distance to something within reasonable set limits to something a bit more manageable?For example "distance for ultra settings". And graduatly decrease that corresponding to scene load in "high" settings, and so on.

martinvk
June 16th, 2015, 06:31 AM
Is the LOD transition distance calculated from the object's origin or the nearest face? For physically small objects it wouldn't make much difference but for large objects, the first transition could even be inside the object or so close that it effectively is never used.

clam1952
June 16th, 2015, 06:43 AM
I've been assuming and basing it on the origin, not that I have ever made any assets big enough for lod levels to actually merge, good point though.

Currently the actual distance seem to vary depending on settings, an actual value of the distance used for each scenery level would probably be helpful to creators, maybe?

WindWalkr
June 16th, 2015, 10:58 AM
Is the LOD transition distance calculated from the object's origin or the nearest face?

Always from the origin.

chris

martinvk
June 16th, 2015, 12:26 PM
Always from the origin.

chrisAh, so without a bounding box, the program has no idea where the object's edges are. Thus for vary large objects, the first LOD transition would happen too soon or even inside in extreme cases.

For these kinds of situations, the creators need a way to specify where the transitions occur. Perhaps a special tag for large-object=1 and then a table of transition distances. Without the tag or if it has a value=0, the built-in transitions would apply.

WindWalkr
June 16th, 2015, 06:08 PM
Depends on what you mean by 'large objects', but my short answer would be that you should avoid making 'large objects'. We've been guilty of this in the past, but there's typically no point to make a single oversized object when several smaller objects are both better-performing and more flexible for the user.

chris

andi06
June 16th, 2015, 06:15 PM
but my short answer would be that you should avoid making 'large objects'.
Forth Railway Bridge (Part 1 of 365) :-)

There will inevitably be some objects which simply have to be made in one piece and will extend beyond the limitations of your ideal LOD distances. Your LOD schemes need to be sufficiently flexible to deal with these.

martinvk
June 16th, 2015, 07:07 PM
One example: If I ever bring my Olympic stadium into T:ANE, it's 245m x 284m without the tower and will be a problem for LOD that isn't flexible. There are many other objects like ships (Queen Mary 2, 345m long) that don't easily lend themselves to be split into smaller pieces. If T:ANE wants to simulate the world where trains exist, then it has to include large objects like these.

WindWalkr
June 16th, 2015, 07:16 PM
There will inevitably be some objects which simply have to be made in one piece and will extend beyond the limitations of your ideal LOD distances. Your LOD schemes need to be sufficiently flexible to deal with these.

Yes and no. I think the simple answer here is that whole-object LOD will never deal well with an object of this kind of magnitude, and that we don't care enough about objects of this scale to make fine adjustments to something that we know isn't ever going to give good results.

That said, I see that I've lost track of this discussion. We're actually talking about mesh-table LOD and not LM as I was thinking. This changes my answer slightly:

* Yes, the origin is the key point of interest.
* However, the mesh-table LOD distances are adjusted by the code to take into account the radius of the bounding box.
* You don't have direct control over the bounding box calculation, so the more complex your object, the more likely that something unexpected will result. (By complexity, I'm talking about attachment points, scripts, animation- not geometry.)

chris

Dinorius_Redundicus
June 16th, 2015, 08:51 PM
OK Chris, I'm glad you're back on track realising the thread was about mesh-table LOD, not LM.txt. The other important half of the topic was that somewhere between TS2010 and TANE, there has been a change resulting in shorter distances for the LOD transitions - a highly retrograde development in my view as a content creator.

Do you accept that this is the case, or are you looking for more/better data to establish it?

If you do agree that something has changed, do you then agree that TANE needs to be adjusted such that we at least get back to where we were in TS2010?

Could that be done without re-designing the whole methodology by which transition distances are calculated? I'm asking that because I know the more complex the re-write, the less chance we have of getting it. Personally, I'd be happy enough just to re-establish TS2010-type behaviour and leave further development of the LOD system (e.g. to take object size into account etc) to future editions of Trainz.


.

WindWalkr
June 16th, 2015, 09:32 PM
.. there has been a change resulting in shorter distances for the LOD transitions - a highly retrograde development in my view as a content creator.

Do you accept that this is the case, or are you looking for more/better data to establish it?

I have not looked into this issue personally, so cannot comment on whether or not the above is accurate. I am not looking for more data at the current time; this is something that we will investigate internally and I'll get back to you once that's been done.



If you do agree that something has changed, do you then agree that TANE needs to be adjusted such that we at least get back to where we were in TS2010?

As above, "If there's a regression in this case then it's probably not deliberate and is likely the result of the differences in how Jet and E2 calculate LOD transitions; ie. it's quite possibly a bug in our compatibility layer."

chris