PDA

View Full Version : Rock and a Hard Place with LoD



RRSignal
September 17th, 2015, 07:17 PM
I understand that LM.TXT is an inefficient way of implementing LoD. Apparently, though, I have to use it - to LoD a 142-poly object. Are there any other options? The key mesh that I have to LoD has a child attachment point for corona.

I've built some signals with 4 levels of LoD. Those use LM.TXT, of course. Optional attachments - all controlled by script - include lenses, plates and signs. Evidently, T:ANE and the new DLS validator includes all possible attachments in evaluating polycount, whether they're actually used or not (one would think that autocreate 0 would indicate that they're not.) In any case, this throws an error in T:ANE.

So, I remedied this by using LM.TXT for the signal lenses too. That got rid of the error at TB 4.2, but now I get a warning about LoD being applied to a <300 poly object. Will this eventually become an error, too?

WindWalkr
September 17th, 2015, 08:05 PM
What warning are you getting? What type of asset is giving you the warning?

chris

RRSignal
September 17th, 2015, 10:24 PM
Let me amend this: It's now an ERROR now that I've implemented LoD with the lenses, albeit an inconsistent one. In any case, the asset is a mesh library. I'm not getting an and error/warning on a specific mesh or LM.TXT container, just this:

! The file 'lenses/amlens.lm' is provided in LM format, however the high-detail mesh is comprised of less than 300 polygons. This may have a negative impact on performance.
! The file 'lenses/grnlens.lm' is provided in LM format, however the high-detail mesh is comprised of less than 300 polygons. This may have a negative impact on performance.
! The file 'lenses/redlens.lm' is provided in LM format, however the high-detail mesh is comprised of less than 300 polygons. This may have a negative impact on performance.
! The file 'lenses/lunlens.lm' is provided in LM format, however the high-detail mesh is comprised of less than 300 polygons. This may have a negative impact on performance.
- The low-detail meshes total more than 500 polygons. This may have a negative impact on performance.

This is when versioned to 4.2. The worst offender has a lowest-detail mesh of 90 polys. That's a 3-head signal that would have at most 3 heads lit at one time and at most two plates/signs applied. However, there is nothing in the config.txt that would suggest that the lenses, signage, etc. have anything to do with the signals, so I cannot fathom why T:ANE would throw an error. The actual signal config.txt, which brings all the bits and pieces together, hasn't even been introduced into T:ANE yet. The lenses' LM.TXT (or any of the lens meshes themselves) are not even referenced in the mesh-table, but the lowest-detail mesh is 2 polys per lens.

The error reporting in T:ANE seems to be extremely erratic and unpredictable. For example, I've tried eliminating meshes from the mesh-table to see if there was a specific asset that was causing an issue. Sometimes this works, sometimes it doesn't. When I try to edit the original library without the possible offender (I'm building this in TS2010) and reimport it into T:ANE, it may or may not error out again, once the Trainz-build is set back to 4.2. Mind you, there's nothing wrong with any of the meshes of which I am aware. It also doesn't help that you can no longer View Errors and Warnings on an open asset, which saved an immense amount of time in the older versions.

FYI, there is a version of this library on the DLS as <kuid2:481384:11111110:1>. I just tried uploading a newer version, having failed three times previously for an unrelated reason, possibly a bug in the DLS validation routine, which is also an issue I'd like to discuss or file a bug report over at another time. If you'd like a copy, I can send one over to you.

WindWalkr
September 17th, 2015, 10:44 PM
! The file 'lenses/amlens.lm' is provided in LM format, however the high-detail mesh is comprised of less than 300 polygons. This may have a negative impact on performance.

This is suggest that you DO NOT use LM.txt format for these files, because they're low enough detail that you probably don't need it. This is a warning only, and will remain a warning only, but you should certainly consider what it has to say.



- The low-detail meshes total more than 500 polygons. This may have a negative impact on performance.

This is hopefully self-obvious. The asset has too many polygons at the lowest LOD level. I would assume that you're talking about a collection of meshes which add up to more than 500 polygons, rather than any single mesh. What you probably want to do here is eliminate any of the "attachment" or "child" meshes from the asset's lowest LOD, leaving only a singular "main" mesh which should be well below 500 polygons.



FYI, there is a version of this library on the DLS as <kuid2:481384:11111110:1>.

I'm not clear on whether you're talking about these errors being on the library or on an actual asset. If the library, just turn off auto-create on the meshes to signal that they won't be used directly. (We may add some more explicit tags here in the future, but this will work well enough for now.) If this is an actual placeable asset then there's very likely a real performance issue with your asset that you'll need to solve.



If you'd like a copy, I can send one over to you.

You're more than welcome to. trainzdev@auran.com, as always.

chris

andi06
September 18th, 2015, 01:24 AM
This is suggest that you DO NOT use LM.txt format for these files, because they're low enough detail that you probably don't need it. This is a warning only, and will remain a warning only, but you should certainly consider what it has to say.
You should also consider that changing the mesh from *.LM.txt to *.im will immediately add the polycount of the mesh in question to the total used to calculate the 500 poly error, regardless of whether or not the mesh is actually used at the lowest LOD.


This is hopefully self-obvious. The asset has too many polygons at the lowest LOD level. I would assume that you're talking about a collection of meshes which add up to more than 500 polygons, rather than any single mesh. What you probably want to do here is eliminate any of the "attachment" or "child" meshes from the asset's lowest LOD, leaving only a singular "main" mesh which should be well below 500 polygons.
Would you like to explain how this can be done in an asset, such as a traincar, which does not use mesh-table LOD, other than simply deleting the submesh entirely?


I'm not clear on whether you're talking about these errors being on the library or on an actual asset. If the library, just turn off auto-create on the meshes to signal that they won't be used directly. (We may add some more explicit tags here in the future, but this will work well enough for now.) If this is an actual placeable asset then there's very likely a real performance issue with your asset that you'll need to solve.
At present its not enough to just turn off auto-create - you need to actually delete the auto-create tag which runs the risk of fouling up any attached scripts.

This post, and your response, is just another example of the fact that NOBODY fully understands how these LOD errors are calculated and that, in the absence of that understanding, creators don't have a snowball's chance in hell of getting an asset into the game.

When finished the Preview window will be an excellent tool for finding and fixing these issues - assuming that you can fix the problems first in order to get them into the Preview.

WindWalkr
September 18th, 2015, 01:36 AM
You should also consider that changing the mesh from *.LM.txt to *.im will immediately add the polycount of the mesh in question to the total used to calculate the 500 poly error, regardless of whether or not the mesh is actually used at the lowest LOD.

Would you like to explain how this can be done in an asset, such as a traincar, which does not use mesh-table LOD, other than simply deleting the submesh entirely?

Don't know. If/when I see the asset in question, I'll be able to review this.



At present its not enough to just turn off auto-create - you need to actually delete the auto-create tag which runs the risk of fouling up any attached scripts.

1. Known bug, has been fixed.

2. If it causes a problem with the scripts, then that's a clear bug with the scripts.



NOBODY fully understands how these LOD errors are calculated and that, in the absence of that understanding, creators don't have a snowball's chance in hell of getting an asset into the game.

Which is why I'm perfectly happy for the asset to be sent to me, so I can give specific guidance.

cheers,

chris

RRSignal
September 18th, 2015, 01:52 AM
This is suggest that you DO NOT use LM.txt format for these files, because they're low enough detail that you probably don't need it. This is a warning only, and will remain a warning only, but you should certainly consider what it has to say.

I'd rather use just the 142-poly lens that I have been using thus far; I used LM.txt to try to fix the LoD errors at TB 4.2. I'll revert my mesh library.


This is hopefully self-obvious. The asset has too many polygons at the lowest LOD level. I would assume that you're talking about a collection of meshes which add up to more than 500 polygons, rather than any single mesh.

The lowest detail mesh of any of these are far, far below 500 polys. Even if you added in all of the furthest-LoD child attachments (which, again, T:ANE has no way of knowing about, since the actual signal asset that assembles them does not exist in T:ANE), the worst-case polycount is well below 500.


What you probably want to do here is eliminate any of the "attachment" or "child" meshes from the asset's lowest LOD, leaving only a singular "main" mesh which should be well below 500 polygons.

I'll give that a try, as that means adding in a 5th level of LoD which will comprise of a single triangle. The trick will be finding out where that will cut in, as these signals need to be visible from several miles away - and they are using the present configuration.


I'm not clear on whether you're talking about these errors being on the library or on an actual asset. If the library, just turn off auto-create on the meshes to signal that they won't be used directly. (We may add some more explicit tags here in the future, but this will work well enough for now.) If this is an actual placeable asset then there's very likely a real performance issue with your asset that you'll need to solve.

The errors are in the library. Again, the actual signal assets don't even exist yet, as far as T:ANE is concerned. However, I have have turned off autocreate now in the library itself.


You're more than welcome to. [removed], as always.

Thanks, Chris, I'll get that to you.

andi06
September 18th, 2015, 02:06 AM
1. Known bug, has been fixed.
Yes, but not in any build we currently have access to. I did say that this was the situation 'at present' and once auto-create has been deleted it is likely to stay deleted whether you have fixed the bug or not.


2. If it causes a problem with the scripts, then that's a clear bug with the scripts.
Yes, but a script is entitled to query an asset for known attributes and the deletion of this tag may change the behaviour if the script isn't bullet-proof. How many trainz scripts are bullet-proof? I'm simply observing that there is a potential for side effects.

I'm not going to apologise for continuously hounding you over this, it should all have been fully resolved before you introduced the changes to validation.

WindWalkr
September 18th, 2015, 06:14 AM
..e deletion of this tag may change the behaviour if the script isn't bullet-proof. How many trainz scripts are bullet-proof? I'm simply observing that there is a potential for side effects.

For sure. But if we use the "that change could expose existing bugs elsewhere" argument everywhere, then we'd never be able to change anything. If there's a bug, it needs to be fixed. That's true whether it's a bug in the game code, or in the scripts.

chris

WindWalkr
September 18th, 2015, 06:20 AM
Even if you added in all of the furthest-LoD child attachments .. the worst-case polycount is well below 500.

Assuming you're talking about total here, then T:ANE obviously disagrees with you. Whether it's correct or not isn't a call I can make until I've seen the asset, but I will state that we have no known bugs in this area currently. What we DO have are cases where different meshes add up on a "per level" basis but you're disabling them through some other means that validation is unaware of, but that sounds unlikely to be the case here.


The errors are in the library.

Oh, if you're just talking about the library then it's easily fixed by switching off the auto-create.

cheers,

chris

andi06
September 18th, 2015, 07:08 AM
For sure. But if we use the "that change could expose existing bugs elsewhere" argument everywhere, then we'd never be able to change anything. If there's a bug, it needs to be fixed. That's true whether it's a bug in the game code, or in the scripts.
I don't disagree in principle, but content creators won't be expecting LOD adjustments to have side effects.


What we DO have are cases where different meshes add up on a "per level" basis but you're disabling them through some other means that validation is unaware of, but that sounds unlikely to be the case here.
This is the issue that's causing all of the pain. No-one can understand why they are getting 500 poly errors when the lowest LOD of their main mesh is far below this. You may not consider it a bug but it is causing mayhem.

As an additional observation, it is bad enough to have to deal with this when creating a new asset, it is worse when updating an existing asset for which all of the source is available and it will be totally impossible to deal with if you don't have the source (as in future DLS cleanups). If validation can't check whether meshes or attachments are culled (or if it can't do so easily) then the 500 poly error should be retained as a warning only.

WindWalkr
September 18th, 2015, 07:14 AM
This is the issue that's causing all of the pain. No-one can understand why they are getting 500 poly errors when the lowest LOD of their main mesh is far below this. You may not consider it a bug but it is causing mayhem.

Perhaps. That doesn't appear to be the case here.

chris

andi06
September 18th, 2015, 07:43 AM
Probably because everybody but me has given up whingeing, I expect they've also given up trying to build anything in 4.2.

RRSignal
September 18th, 2015, 10:29 AM
I sent a link to the file in last night, but it was returned as spam by N3V's email provider, Google. Here's a link, below. Just a reminder that I'm still getting this error even with autocreate set to 0 in version 76536.

https://www.cubbyusercontent.com/pli/RRS-content-archive.cdp/_13461e6e6d204699a939316407b341cd

EDIT: The library has finally been successfully uploaded to the DLS as <kuid2:481384:11111110:2>, albeit at TB 3.5. Any other dependencies you may need are also on the DLS.

Mike10
September 18th, 2015, 12:23 PM
Probably because everybody but me has given up whingeing, I expect they've also given up trying to build anything in 4.2.


I know that I have (for now). Creating new stuff, and updating old stuff, I've started to lose track of what's caused by bugs in Content Manager, what's a problem with mesh libraries, how the limits are calculated and reported. What counts to the total and what doesn't, how are attachments treated in the total ... and so on.

My lowest LOD (all meshes included) is way less than 500 polys, the LM.txt says to cull the attachments as well (I've even done LOD on the attachments to get them down to single figures), I still get the error.
Is that because the cull isn't working? because of a bug in CM? because it doesn't calculate it in the way I think it does? because I cannot add up to 500? ..... who knows, not me.

For now I'm making stuff that I think is actually OK but CM is lying and putting it to one side for later.
Maybe when the Service pack and Hotfix are released and things have stabilised it will be worth trying again.

Unless in the meantime someone wants to put together a definitive guide on how to avoid the >500 poly error and outline what is working and what isn't.
Of course I believe that LOD for scenery just doesn't work at all at the moment (certianly not the testing I've been doing)... that doesn't help if its true.

It isn't like I'm just learning the content creation business either.

Mike.

clam1952
September 18th, 2015, 01:26 PM
Only things I've done as 4.2 is T:ANE versions of my billboard Trees and bushes due to them being too bright, no lod involved on 4 crossed planes. They are not needed now as plenty of SpeedTrees and shrubs etc however some seem to prefer them......
Everything else which is pretty basic stuff I made ages ago and never uploaded I'm doing in TS12 adding Lod where required and just testing in T:ANE that it's not going to throw up any errors, staying away from Loco's Rolling Stock and bogies until after the hot fix and we know where we are at.

WindWalkr
September 19th, 2015, 08:07 AM
I sent a link to the file in last night, but it was returned as spam by N3V's email provider, Google. Here's a link, below. Just a reminder that I'm still getting this error even with autocreate set to 0 in version 76536.

https://www.cubbyusercontent.com/pli/RRS-content-archive.cdp/_13461e6e6d204699a939316407b341cd

EDIT: The library has finally been successfully uploaded to the DLS as <kuid2:481384:11111110:2>, albeit at TB 3.5. Any other dependencies you may need are also on the DLS.

Thanks. Unfortunately I'm showing the following missing dependencies from the content at the above URL. These are not on the DLS.

<kuid:481384:11111113>
<kuid:481384:11111115>
<kuid:481384:11111118>

chris

WindWalkr
September 19th, 2015, 08:10 AM
For now I'm making stuff that I think is actually OK but CM is lying and putting it to one side for later.
Maybe when the Service pack and Hotfix are released and things have stabilised it will be worth trying again.

If you think that your content is showing off a bug, please make sure to send it in. This kind of thing will typically NOT be picked up by the beta testers, so if you don't push for a fix, nobody will.

chris

Mike10
September 19th, 2015, 05:09 PM
I've just sent you a bogie with a Trainz build of 4.2 in which the lowest mesh has 120 polys.
Content manager (build 76401) says it has more than 500.
There's no attachments, scripting, or any fancy stuff, its just a plain bogie.
If I've got something wrong and I am mistaken please enlighten me as to where I have slipped up.

WindWalkr
September 19th, 2015, 09:47 PM
I've just sent you a bogie with a Trainz build of 4.2 in which the lowest mesh has 120 polys.
Content manager (build 76401) says it has more than 500.

I'm not seeing anything reported on this asset relating to polygon count in the current build. It's feasible that you've hit some kind of bug which has already been fixed, although I'm not aware of any bugs relating to this kind of asset formation.

chris

RRSignal
September 20th, 2015, 12:31 AM
Thanks. Unfortunately I'm showing the following missing dependencies from the content at the above URL. These are not on the DLS.

<kuid:481384:11111113>
<kuid:481384:11111115>
<kuid:481384:11111118>

chris

Sorry, I show updated kuid2s on the DLS. However, I've emailed them to you and versioned them for 4.2 for you. If needed, I'll put them in my Cubby, but hasn't shown as bounced so I'll assume they went through for now.

WindWalkr
September 20th, 2015, 01:49 AM
Thanks! This is what I am seeing:

- The low-detail meshes total more than 500 polygons. This may have a negative impact on performance: 0: 2263, 1: 2263, 2: 869, 3: 869
- The meshes in LOD level 3 must total at least 20% fewer polygons than the next higher LOD: 0: 2263, 1: 2263, 2: 869, 3: 869
- The meshes in LOD level 1 must total at least 20% fewer polygons than the next higher LOD: 0: 2263, 1: 2263, 2: 869, 3: 869

So, if we take the message at face value, it seems pretty straightforward:

1. LOD#0 and LOD#1 have the same number of polygons. This is a performance bug, you should get rid of the duplicate.
2. LOD#2 and LOD#3 have the same number of polygons. This is a performance bug, you should get rid of the duplicate.
3. LOD#3 still has 869 polygons. This is a performance bug, you need to get the lowest LOD below 500.

Looking at the config.txt file for this asset, we can see that there is only one auto-create mesh, "tri300.lm", which is sourced from <kuid:481384:11111110>. Taking a look at this lm.txt file shows the following:


mesh("0.07")
{
name="tri-3-0-0-lod2.im";
}
mesh("0.15")
{
name="tri-3-0-0-lod2.im";
}
mesh("0.95")
{
name="tri-3-0-0-lod1.im";
}
mesh("1.0")
{
name="tri-3-0-0-lod1.im";
}

So, #1 and #2 above are definitely correct- you've added duplicate entries to no benefit. Get rid of them.

#3 tells us that "tri-3-0-0-lod2.im" has 869 polygons, so you should review this mesh in Max and find out where the extra polygons are coming from.

kind regards,

chris

RRSignal
September 20th, 2015, 02:49 AM
Ok, thanks. I've corrected that one LM.TXT but I'm still getting the exact same error. I've checked all the LM.TXTs in the mesh library and they are all ok as of this writing with all four levels of LoD properly represented. Again, none of the lowest-detail meshes is over 500; in fact, the worst offender is just 90 polys. The worst non-LoDed mesh in the entire library is 174 polys. For kicks and giggles, I tried even taking out the mesh-table entries in the library for the two Posts/Masts (they don't use LM.TXT, since they are trackside-scenery) and I'm still getting the error, although I've left them in the version that is in my Cubby folder.

I'm showing the following for that 3-0-0 signal:

LOD0: 4201
LOD1: 2263
LOD2: 869
LOD3: 50

I've re-uploaded a corrected set of assets at:

https://www.cubbyusercontent.com/pli/RRS-content-archive.cdp/_08e279acb77043bfaf940a1d5c0ce83d

Side note: T:ANE's CM shows no errors or warnings for any of this upon committing; it takes awhile to show. You probably already know this but I thought I'd mention it.

WindWalkr
September 20th, 2015, 03:34 AM
I'm not seeing any errors from this version of your content. I suspect you might be using a test build older than the most recent two? Try upgrading and let me know if you're still seeing problems.

chris

Mike10
September 20th, 2015, 03:44 AM
I'm not seeing anything reported on this asset relating to polygon count in the current build. It's feasible that you've hit some kind of bug which has already been fixed, although I'm not aware of any bugs relating to this kind of asset formation.

chris

OK, I'll download 78602 and try it in that.

RRSignal
September 20th, 2015, 09:16 AM
I'm using 76536, the most recent KS DRM-free version, not a test build. I don't have a network connection on my gaming machine, so I can't use the test builds.

WindWalkr
September 20th, 2015, 09:31 AM
I'm using 76536, the most recent KS DRM-free version, not a test build. I don't have a network connection on my gaming machine, so I can't use the test builds.

Okay, fair enough. You'll need to wait until you have access to the more recent changes before you're going to see any of the validation updates that we've been talking about here. Unfortunately it's not practical for us to create offline test builds at the current time.

chris

Mike10
September 20th, 2015, 12:56 PM
I downloaded 78602 and put the assets I was having issues with into it.
It threw up a few extra errors that I hadn't seen before, but the 500 poly error wasn't one of them.
That helps me as I can now put what I was seeing down to a bug in 76402 that has now been fixed.
Of course all those content creators who don't have access to a build higher than 76402 are still in the same position I was yesterday.