PDA

View Full Version : LOD Accounting



andi06
August 17th, 2015, 04:31 AM
The 500 Poly error has now been made more useful by your appending a list of polycounts per LOD to the message. However there still isn't enough information to be useful. Here is a specific case:



I'm looking at updating an existing traincar asset which has three LODs at 13008,5556,2378. This is a fairly complex model with submeshes and effects.
As a first step I have changed trainz-build to 4.2 and added a fourth LOD at 150 polys. This mesh has no attachment points.
I have installed the updated asset and cleared all of the other errors.
I am now left with the 500 poly error which lists the LODs as 16296,7546,3340,1106.


I understand that the LODs include polycounts for various submeshes and attachments. Looking at the last LOD, the error report shows 1106 polys of which I can account for only 150. In order to deal with the 956 stray polys I need to know what they are so that I can get the asset working in game and in Asset / Preview.

You have said in another thread that this information is '.... complicated ....' That may be so but dealing with this error by trial and error is equally complicated and frustrating and it isn't going to happen. How can we get a complete listing of the submeshes, effects etc which are being included in the validation calculations so that they can be culled or suppressed at the lower LODs?

Suppressing errors for work in progress (long discussed and still awaited) will help but it still won't tell the whole story.

pcas1986
August 17th, 2015, 04:57 AM
I'll toss my own dilemma into this debate since I think the questions are the same. Here are two screenshots of Preview Asset showing my current project at its lowest LOD. Unless I've screwed up somewhere there should be no attachments or even a bogie. (Edit) The model has four LOD levels and the lowest level LOD model shown here is a five sided orange box with 10 tris.

This shot shows the best result I can get:
http://i1188.photobucket.com/albums/z410/casper131/Ashampoo_Snap_2015.08.17_19h40m19s_001_Trainz-%20A%20New%20Era_zpsqthpde9x.jpg


But if I let the model rotate a little I get these numbers:

http://i1188.photobucket.com/albums/z410/casper131/Ashampoo_Snap_2015.08.17_19h42m30s_002_Trainz-%20A%20New%20Era_zpsaeosxrnj.jpg

I had to stretch the window marginally because the numbers kept changing but there is some odd going on. The tri count, draw count and bone count have increased significantly but the same box is visible.

Over the last couple of weeks I've substantially modified this model to try and get the numbers down but it's not working.

andi06
August 17th, 2015, 05:12 AM
I'll toss my own dilemma into this debate since I think the questions are the same.
They are certainly related.

In your case we need to be able to expand on the Statistics - maybe by right clicking on Attachments Visible and getting a list.

In my case I can't get the asset into Preview at all, so we need either:

a) The same information by some other route.
b) The ability to get assets with errors into Preview in order to get details of the errors.

WindWalkr
August 17th, 2015, 05:58 AM
You're confusing two unrelated topics here:

* The asset preview gathers its statistics by rendering the actual mesh and then reporting back what happened. You can dig into this further by (1) checking out the meshes in Max, (2) using a third-party tool to view the contents of the mesh files, (3) decomposing the asset, or (4) using the log scene button to log exactly what was rendered.

* Validation works by adding up the details specified in the mesh files of the asset. Attachments aren't included, just the mesh-table entries. LM.txt and mesh-table LOD are both considered, but are considered to vary in simple levels (which obviously isn't necessarily true when it comes to actual rendering.)

chris

andi06
August 17th, 2015, 06:42 AM
You're confusing two unrelated topics here:
No I'm not, I fully understand the difference but I can't work out where your validation error-message figures are coming from.
Without an asset-in-development tag I need to clear my error message before I can get the asset into Preview at all.


* Validation works by adding up the details specified in the mesh files of the asset. Attachments aren't included, just the mesh-table entries. LM.txt and mesh-table LOD are both considered, but are considered to vary in simple levels (which obviously isn't necessarily true when it comes to actual rendering.)

Assuming that:



Attachment and corona effects are ignored.
Meshes with auto-create 0 are ignored. (likely to be script controlled)
Meshes with specified attachment points are ignored where that attachment point is not present in the LOD mesh in question. (likely to be deliberately culled)
Meshes which are retrieved from a mesh-library are included at the correct distance based LOD level. (may have their own LOD schemes with different cut-offs)


Then the error message should be reporting 808 for the last LOD, its actually reporting 1134. This is a mismatch of 326 which doesn't correspond to anything obvious.


(4) using the log scene button to log exactly what was rendered.
Is this working in the current build? Does this write out a file? What is it called and where is it?

chris[/QUOTE]

WindWalkr
August 17th, 2015, 08:43 AM
Attachment and corona effects are ignored.

Correct, they're not part of the asset and not relevant for this count.



Meshes with auto-create 0 are ignored. (likely to be script controlled)

Correct.



Meshes with specified attachment points are ignored where that attachment point is not present in the LOD mesh in question. (likely to be deliberately culled)

Not correct. The count looks at the meshes only, not the structure of the asset. It doesn't care about your attachment points.



Meshes which are retrieved from a mesh-library are included at the correct distance based LOD level. (may have their own LOD schemes with different cut-offs)

As above, the count is based on LOD level only. No attempt is made to attempt to control for differences in the meaning of LOD level between separate meshes.



Is this working in the current build? Does this write out a file? What is it called and where is it?

Not 100% sure if it's working in that build. It probably is, but I can't be sure at what point it was completed. It writes to the TANE log.

chris

andi06
August 17th, 2015, 09:46 AM
Thank you for this - you have a couple of problems.

Bug 1: Meshes with auto-create 0 are NOT being ignored.

Bug 2: The object of the 500 poly error is to trap assets which use excessive resources at the lowest LOD. If it is trapping meshes which are culled at that LOD then it isn't working correctly. If you have for instance a 500 poly animated fan listed in the mesh-table and this fan is culled at all lower LOD levels then it will be impossible for the asset to pass the 500 poly test, this will apply no matter how efficient the asset is when viewed as a whole.

I've every sympathy with the aims of this error but if it isn't bulletproof it will just cause chaos - and it certainly isn't bulletproof.

Quite apart from the above I still don't think that it is working correctly, even ignoring the bugs above it simply isn't giving the correct answers.

The log isn't working in the current build.

andi06
August 18th, 2015, 03:56 AM
What you are actually doing is something like this:

You are starting off with the polycount of the lowest LOD of the default mesh and then stepping through the mesh table and applying these rules to each submesh:

1. If the submesh is LM.txt you are ignoring it - The LM.txt doesn't need to be valid and the size of the actual meshes is not taken into account, the mere existence of an LM.txt file takes the submesh out of the reckoning.

2. If the submesh is an IM file you are adding it to the total - it doesn't matter if 'auto-create 0' is present (indicating a script-controlled mesh) or if the submesh will be culled at the lowest LOD (indicating that LOD issues have already been considered and dealt with), the mere existence of an IM file in the mesh-table will increment the validation polycount total.

Do you want an asset example and spreadsheet that proves the above?

Whilst this algorithm will no doubt find inefficient assets it will also find assets which, despite exhibiting exemplary efficiency, have scripted submeshes or submeshes which are present only at the highest LODs.

Like so many other aspects of validation this will serve to provide even more hoops for us to jump through and give rise to even more hacks and workarounds which will come back to haunt you in the future. Do you want to keep going through this self defeating process or do you want to get it right now? I seem to remember that this sort of cockup was instrumental in your starting off TrainzDev in the first place.

[Edit: I've just found another asset which will have serious problems here. This is a placeable traincar asset which has a secondary function as a mesh library - the actual LOD3 load is 250 polys, the error message is reporting 10,000]

pcas1986
August 19th, 2015, 05:49 AM
What you are actually doing is something like this:

...

Hmm, I just tried this with my loco project. The lowest loco body mesh is 10 polys. All the attachments are LM.TXT except two that are cab roof animated sliding covers. There are two of these both with 36 polys. 10+36+36=82 which is the number shown in my first image in post #2. Since there are three items to draw I guess that accounts for the draw call count of 3.

So then I wondered why the two cab covers were still being rendered and discovered that I had omitted the cull on the attachment labels for these covers. On fixing that and resubmitting I now get 10 polys and a draw count of 1. Whoo, hoo! But Preview Asset still talks about 40 attachment points, 12 animation counts, 6 attachments visible, etc at the lowest level LOD. That I don't understand.


On the positive side I think Andi's observations have been instrumental in "debugging" my problem so I strongly suggest that publishing how the (edit) poly counting works can actually help creators determine where a problem lies.

There is obviously more work I need to do to improve efficiencies at the 2nd and 3rd level LOD of my model but until we get more information on how these numbers are calculated, we are in the dark.

andi06
August 19th, 2015, 06:45 AM
In the current build Preview Asset is including draw calls and polys which are attributable to the Preview environment and have nothing to do with your traincar. Chris is aware of this and will no doubt sort it out in due course.

Some guidance on if, how and when the other statistics (attachments, animations etc) are significant would be welcome (and if they don't really matter perhaps they shouldn't be displayed at all)

Intermediate LOD statistics are, as Chris says ... complicated ... Unless your traincar is a single set of meshes with no effects or attachments, all of the bells and whistles will be cutting in and out at different distances depending on when they are culled and what each of the LM.txt files is specifying.

Remember that the LM.txt entries:
- mesh("0.5") { name="traincar.im" }
- mesh("0.5") { name="attachment.im" }
will cut in and out at radically different distances and that both might apply.

I don't see this as much of an issue. You have LOD-0 which is the most detailed view of the model and you have LOD-n which is the minimum possible polycount. In between these points you have several methods of control to achieve a progressive reduction in resources. All you have to do is to achieve a satisfactory compromise between appearance and performance.

I'm pleased that someone else is now able to make sense of LOD-# polycounts. Chris needs to pop in, acknowledge that there are still problems with the 500 poly error and confirm that these will be fixed.

Otherwise I might need to publish details of how to side-step it entirely, together with an AssetX script to 'fix' the error automatically.:)

pcas1986
August 19th, 2015, 07:37 AM
In the current build Preview Asset is including draw calls and polys which are attributable to the Preview environment and have nothing to do with your traincar. Chris is aware of this and will no doubt sort it out in due course.

OK. If that was acknowledged then I must have missed it. I had assumed the environment attributes were excluded.




Some guidance on if, how and when the other statistics (attachments, animations etc) are significant would be welcome (and if they don't really matter perhaps they shouldn't be displayed at all)

Especially if they confuse people like me.


...
Otherwise I might need to publish details of how to side-step it entirely, together with an AssetX script to 'fix' the error automatically.:)

That sounds like blackmail. :) And I recall you accusing me of cheating when I "fixed" a procedural track mesh asset. That, if you hadn't noticed, now works correctly without the "fix".