PDA

View Full Version : LOD Techniques



andi06
July 12th, 2015, 12:42 PM
I've been playing around with automatic mesh reduction techniques in Max.

693

The white car is a finished model. As of this morning it had no LOD meshes but the four reduced meshes to the left were produced inside about an hour. The polycounts are 4480, 2184, 836 and 179 respectively. The reduced meshes (0 - 3) have been temporarily added to the main asset as attachments.

694

Presented like this it becomes easy to see when LOD changes can be made. Basically as you zoom out the point at which you can't see any difference between two neighbouring meshes is the point at which an LOD change can be made, in the second screen its just about time to change to LOD2.

In developer mode it would be very useful to have some sort of current view zoom factor to be able to relate these visual change points back to the asset, perhaps the distance from the compass point to the camera. Its the sort of thing you might put in the Title Bar, something like [Name of Current Route & Session | Layer | Zoom Factor | Frame Rate]

Any chance?

WindWalkr
July 13th, 2015, 06:53 PM
Can easily add this to the asset preview window.

chris

WindWalkr
July 13th, 2015, 06:55 PM
Also a note on your mesh. Nice work, so take this as a general comment rather than a criticism:

At your lower-detail LOD, it looks like you're building the wheel arches from polygons. This is a fairly expensive proposition, and results in moderately jagged geometry (admittedly probably pretty hard to notice at the intended distance.) You can typically achieve a visually superior result more cheaply by using alpha masking.

chris

Pencil42
July 13th, 2015, 11:37 PM
Can easily add this to the asset preview window.

chris

Maybe use the mouse wheel to zoom in and out, with text giving the distance from the camera?

Curtis

andi06
July 14th, 2015, 04:34 AM
At your lower-detail LOD, it looks like you're building the wheel arches from polygons. This is a fairly expensive proposition, and results in moderately jagged geometry (admittedly probably pretty hard to notice at the intended distance.) You can typically achieve a visually superior result more cheaply by using alpha masking.
Of course but the 'cost' depends on your point of view.

Producing LOD meshes is one of the most tedious activities known to man, and its extremely expensive of my time. Provided the lower LODs achieve the required reductions and work in game their aesthetic value (when viewed close) is unimportant. I'm trying to develop methods of producing these meshes automatically (or semi automatically) from an existing model.

Here is another attempt on a different model, mesh sizes 6270/3137/990/456.

698

I fully accept that LOD3 could be reduced to 30 or 40 polys by creating a fresh model from scratch, but that would be a few hours work. I produced all of these meshes in twenty minutes.

WindWalkr
July 14th, 2015, 07:31 AM
Yep. All good points. Also depends on how these things are being used in the route; if they're static scenery (mesh-table LOD) and they're expected to be reused then you're effectively throwing away up to 90% of your performance by going for 456 instead of 40. On the other hand, if they're moving vehicles or likely to be one-off items, then there's basically no difference in cost.

chris

andi06
July 16th, 2015, 05:00 AM
Bearing in mind that moving vehicles are highly likely to use static vehicles as a mesh-asset which LOD scheme should be used for spawned cars?

WindWalkr
July 16th, 2015, 06:10 AM
Bearing in mind that moving vehicles are highly likely to use static vehicles as a mesh-asset which LOD scheme should be used for spawned cars?

It probably doesn't make a huge amount of difference if they're just static meshes with no animations or attachments. LM.txt prevents stitching, but being used in Carz also prevents stitching, and you really really don't want stitching if you're moving anyway.

For static scenery, you definitely want mesh-table LOD with shared materials.

I'm not clear on whether using a single IM file from both mesh-table directly and via an LM file will work in T:ANE. I suspect that you might run into trouble. Since you're going to have to pick one to be safe, the logical answer is mesh-table LOD.

chris

andi06
July 16th, 2015, 06:23 AM
There is no provision for an LM.txt to reference a mesh-asset but there is no reason why the LM.txt file can't be located in the parent, I've done this before. I will try it and let you know.

andi06
July 16th, 2015, 08:27 AM
Piece of cake!

703

If the scenery vehicle is set up like this and the spawned client references the LM mesh then everything works correctly using the same meshes. Default is the groundplane shadow. Perhaps surprisingly the LM scheme is considerably more aggressive than the mesh-table LOD.

There is a script (which just does a random texture-replacement) but I don't think that will be a problem either.

andi06
July 16th, 2015, 01:34 PM
Of course I can't actually implement the child asset using mesh-table LOD because:

704

These meshes are in a mesh-asset which means, I believe, that validation doesn't actually know how big they are.

Looks like another validation cock-up, the asset is trainz-build 3.7.

WindWalkr
July 16th, 2015, 06:34 PM
Piece of cake!

Looks like you just went ahead and did what I said may not work reliably? :)

chris

WindWalkr
July 16th, 2015, 06:35 PM
These meshes are in a mesh-asset which means, I believe, that validation doesn't actually know how big they are.

I don't see that this follows.

chris

andi06
July 16th, 2015, 06:44 PM
Looks like you just went ahead and did what I said may not work reliably?
Yes, I don't always believe what you say :-)

I'm curious as to why mesh-table LOD in the scenery asset is swapping the meshes at a far greater distance than lm.txt. You have stated many times that lm.txt is more expensive than mesh-table LOD. Is this still the case if lm.txt is specifying a more aggressive scheme?


I don't see that this follows.
I mean that if validation doesn't know the size of the meshes in a mesh-asset then it has no basis on which to decide that they don't achieve the required reduction. If this is the case it will always be unsafe for validation routines to comment when a mesh-asset tag is present.

WindWalkr
July 16th, 2015, 06:49 PM
Yes, I don't always believe what you say :-)

You don't have to, but I wasn't kidding, so if you spend ages on this and then later on find a case where it doesn't work properly, don't complain to me ;-)



I'm curious as to why mesh-table LOD in the scenery asset is swapping the meshes at a far greater distance than lm.txt.

I'm not really sure what you're saying here. In one case, you have no control over the transition distances. In the other case, you have complete control. How is it surprising that the numbers you are using are different from the numbers that the game is using?



I mean that if validation doesn't know the size of the meshes in a mesh-asset then it has no basis on which to decide that they don't achieve the required reduction.

What gives you the idea that validation can't read mesh-asset tags? I'm pretty sure it can.

chris

andi06
July 16th, 2015, 07:06 PM
You don't have to, but I wasn't kidding, so if you spend ages on this and then later on find a case where it doesn't work properly, don't complain to me ;-)
I wouldn't dream of complaining. However at present the 'unreliable' way works and your preferred method doesn't.


I'm not really sure what you're saying here. In one case, you have no control over the transition distances. In the other case, you have complete control. How is it surprising that the numbers you are using are different from the numbers that the game is using?
What I'm getting at is that lack of control over transitions cuts both ways. In this particular case the game (using mesh-table LOD) could switch out much earlier but I have no way of telling it this. Overall LM.txt would use fewer resources because it would switch the meshes earlier. Wouldn't this offset the additional cost of using LM.txt (whatever that might be)?


What gives you the idea that validation can't read mesh-asset tags? I'm pretty sure it can.
It is issuing '20% fewer polygon' warnings incorrectly so if it can retrieve the mesh polycounts there is some other bug going on.

WindWalkr
July 16th, 2015, 07:23 PM
I wouldn't dream of complaining. However at present the 'unreliable' way works and your preferred method doesn't.

Sure :)

My 'preferred' method was to use mesh-table LOD. What doesn't work about that?




What I'm getting at is that lack of control over transitions cuts both ways. In this particular case the game (using mesh-table LOD) could switch out much earlier but I have no way of telling it this. Overall LM.txt would use fewer resources because it would switch the meshes earlier. Wouldn't this offset the additional cost of using LM.txt (whatever that might be)?

This is situational, but the short answer is no. The small gains you might receive from having a few less polygons up-close will be more than offset by having huge numbers of additional instances in the background.



It is issuing '20% fewer polygon' warnings incorrectly so if it can retrieve the mesh polycounts there is some other bug going on.

Can't comment on that since I haven't seen the asset. If you think it demonstrates a bug and want to send it through for investigation, be my guest. trainzdev@auran.com

chris

andi06
July 17th, 2015, 06:52 AM
The small gains you might receive from having a few less polygons up-close will be more than offset by having huge numbers of additional instances in the background.
Sorry but this doesn't make sense to me. Can you please explain the difference in performance between mesh-table LOD and LM.txt given that in this case we are talking about moving objects where stitching is not involved.


Can't comment on that since I haven't seen the asset. If you think it demonstrates a bug and want to send it through for investigation, be my guest. trainzdev@auran.com
I can do that but the problem is deeper than a bug with a single asset or with a single technique.

Validation is getting it fundamentally wrong whenever it has to deal with mesh libraries - it clearly doesn't know how big they are and if it thinks it does then its mistaken.

WindWalkr
July 17th, 2015, 07:52 AM
Sorry but this doesn't make sense to me. Can you please explain the difference in performance between mesh-table LOD and LM.txt given that in this case we are talking about moving objects where stitching is not involved.

Sorry, I took your comment as applying to the object as general scenery, not just in use by the Carz system. You're right- there's little difference between the two approaches if it's used only for Carz and never as scenery.



I can do that

Cheers. I'll take a look and get back to you.

chris

andi06
July 27th, 2015, 06:31 AM
I'm not clear on whether using a single IM file from both mesh-table directly and via an LM file will work in T:ANE. I suspect that you might run into trouble. Since you're going to have to pick one to be safe, the logical answer is mesh-table LOD.
Going back to this for a moment.

Superscript is a script library which contains a bunch of meshes which are used by client traincars (either as attachments or mesh-asset referenced submeshes, sometimes animated) Some of these are a little on the large size and might benefit from an LOD implementation but at the same time I have to be careful not to break existing assets.

For instance Superscript has screwlink.im and screwlink.kin which are widely used to implement an ACS controlled screwlink coupler.

The only mechanism I can see which would allow me to add LOD without breaking existing objects is to make screwlink-lo.im as a reduced mesh and to create screwlink.lm.txt (including both screwlink.im and screwlink-lo.im) to provide an alternative mesh reference with LOD.

Newly created clients would then use screwlink.lm whilst existing clients would continue with the less efficient screwlink.im.

This does work without any problems that I can see but it also cuts across your quoted statement above. Since you only 'suspect' that this might give trouble could I ask you to check it out. The mesh library is the only place that a shared lm.txt file can go since the lm.txt format doesn't allow referencing meshes which are external to the asset.

WindWalkr
July 27th, 2015, 07:00 AM
At the current time, I *think* that you will avoid trouble here, however the code is fragile about this kind of thing so I can't guarantee that it won't break in the future. If it breaks, you can let me know and I'll schedule some time towards it, but obviously you'll have to deal with the fact that it's broken in the meantime.

The underlying issue is that there are two completely different paths with completely different data requirements here. Keeping both sets of data around is memory-expensive, so typically the unnecessary data is discarded after loading is complete. Since there are no other hints telling the game what data is required, it takes an educated guess based on how the asset is loaded and acts appropriately. If it gets it wrong, it will reload the asset.

Where we're likely to run into issues with what you're proposing is that the game will adapt itself to one usage, which will work. Then it will adapt to the other usage, and the objects relying on the data from the first usage may stop working. I'm happy to agree that this is our problem and treat it as a bug when it happens but I can't guarantee you that it's not going to happen.

A safer idea would probably be to introduce new mesh files (or even a new asset) for the LM format and leave the obsolete files alone.

chris

andi06
July 27th, 2015, 07:11 AM
Thanks.


A safer idea would probably be to introduce new mesh files (or even a new asset) for the LM format and leave the obsolete files alone.

I agree in principle but in this case the whole concept is that Superscript is a one-stop shop for common UK couplings and I really don't want to drop that.