Open ZakJudges opened 2 years ago
@ZakJudges I think we can look at this Post-EA as an optional extra for the model importer. Heading off high poly models before they get to the object library is a great idea, and having different schema to try allows different models to get the best looking/performing optimization. Once we have some examples under our belt, we might also find a single optimization works well as a default option for models imported after March :)
Question - won't something like this potentially mess up a model's UV map, causing the textures/materials to not be applied correctly to the model? Any time you change the polygonal structure of a model, you run the risk of messing up the UV map, especially with these auto-mesh optimization options.
@ArgentArts I haven't looked at MeshOptimizer in too much detail, but it seems like most of the methods used would not change the appearance of the mesh, they simply reorganise the data within the mesh based on how it will be accessed throughout the various stages of the graphics pipeline, to make it more cache-friendly. Though if we were to use the library to generate LODs then you are indeed correct, the appearance of the object would be altered, so it should definitely be optional :)
From the site:
this library provides algorithms to help optimize meshes for these stages, _as well as algorithms to reduce the mesh complexity_ and storage overhead.
Reducing "mesh complexity" means that it removes polygonal faces in order to reduce the overall poly count of the model (i.e. making it less complex). Even if this does not change the actual shape of the model, it can mess up a UV map depending on how the artist has created any UV islands for the model.
Once you read further down on that page, you get to a section called Simplification:
All algorithms presented so far don't affect visual appearance at all, with the exception of quantization that has minimal controlled impact. However, **_fundamentally the most effective way at reducing the rendering or transmission cost of a mesh is to make the mesh simpler_**.
So, according to the developer, the previous stuff (the stuff that does not affect the visual appearance of the model) is not the most effective way to reduce rendering cost. The most effective way is to make the mesh, itself, simpler. And this tool does that, too.
This is where I wonder what would happen to a model's UVs after any simplification. However, having said that, I know that other modern engines, like Unreal, auto-generate LODs and the UVs still work ... mostly. There have been times when these auto-generated LODs have messed with UVs. Often it's not seen because, well, the model is further away (LODs, after all). But if we start using something for the purpose of optimizing a model on import, I suspect these type of UV errors would show more frequently since this will affect the model that's front-and-center.
Add optional functionality to the importer to optimise meshes before they reach the object library. MeshOptimizer, found here: https://github.com/zeux/meshoptimizer can change mesh data layout to make it more gpu friendly. It could also potentially be used to generate different LODs for imported models automatically