View Full Version : Question of Mesh Library efficiency

January 5th, 2016, 10:23 PM
I'm building a set of PRR signals and am curious how to configure them. I saw Windwalkr's reply in Rumour3's thread, but this is likely a larger project. If I assemble each as a single unit, there likely will be at least 100 or so configurations of the signals. With 4 levels of LoD, that's about 400 meshes, which will take up 100mb uncompressed. Obviously, they will use LM.txt.

Alternatively, I can construct them with the mast, faceplates, and attachment points for lights, and place the lamp arrangements (both lit and unlit) using mesh-table LoD or attached meshes, essentially making them scenery to the functional parts of the signal. Built this way, I can probably reduce the number of required meshes to a couple dozen. I may also be able to game the LoD settings a little better. This would also allow me to reuse the library to build two other, nearly-identical signal systems.

So, what's better? Also, are all meshes loaded at one time, or only the ones as needed by an asset? My RDG signal mesh library ended up being rather large, so I'm hoping to avoid creating an even larger one.

January 6th, 2016, 05:28 AM
Single meshes beats multiple meshes easily, all else being equal. You should be able to demonstrate this in game easily enough. Your ideal scenario is likely to use components at the high LODs, and fall back to single meshes as quickly as possible (losing some individuality as you reduce detail, and falling back a library of small unified pieces for the more distant so that only one mesh is required.) Since most of your disk space requirements will be in the high LODs, this should hopefully solve your disk space problems.

When it comes to memory usage, the real question is how many different types of objects are in the scene simultaneously. It doesn't matter to the runtime usage if there are one thousand possible meshes, if you're only going to have 50 signals comprised of 20 meshes.



January 6th, 2016, 09:23 AM
Thanks. The plan was to use a few common, unitary meshes for LOD3 (the furthest LoDs). Maybe for the LOD2 as well. LOD0 and 1 are where the problem lies, and, you're right, they take up the most space.

However, I'm less worried about disk usage than memory usage. Runtime performance and memory usage is key. I'd guess in a worst-case scenario, and if I had made each signal as a single unit with a few common furthest-LOD meshes, there would be 20 different variants of signal and, thus, with maybe 40 different meshes on scene at a time, accounting for varying levels of detail.

January 6th, 2016, 03:06 PM
Seems reasonable. Don't forget to account for other attachments such as coronas, text effects, and so on. Just because these are provided based on config entries rather than hand-modelled doesn't make them free. Obviously if a given effect is needed, it's needed- but definitely try to drop things out in the lower LODs where you can afford to. Text is typically an easy one to drop out. Coronas less so, because they can be noticeable when quite distant, but depending on how many you start with you may be able to reduce the number.

Again, your best bet is to try them out in actual test scenarios to find out how much performance impact they're having in practice. The asset preview tool can help with this to some degree, or you may be able to set up a more realistic test scenario in Surveyor. Obviously you're going to have to overdo things because one or even twenty objects is unlikely to hurt performance by itself- maybe consider throwing twenty different configurations of signal into Surveyor and then duplicating that a thousand times over. Once you've got enough signals to cause a visible drop in frame rate, you can then make adjustments ("what happens if i cut out one mesh?", "what happens if i remove the coronas?") and see what approaches are worth chasing up.