431 uncovered a few problems with the current LOD setup.
KMFs are divided into multiple mesh groups, usually to be able to assign different materials but sometimes also for high-poly models like GemHolder to overcome group size limitations.
1 group
another
That leads to an unexpected distribution of triangle definitions over the groups and LODs, not the typical descending order.
KMFs define a global number of LODs and for a given level the corresponding mesh group levels are to be combined for the final mesh. If one is empty that group doesn't contribute to that level.
In JME otoh the LodControl determines the level to choose independently for each mesh group, leading to incorrect combinations.
One way to deal with this could be to merge mesh groups that use the same material. There's just this unknown variable mmFactor to consider (inverse factor in mipmap level decision (falloff?)?)
This hasn't surfaced yet cause the way LodControl works, together with the low polycounts, means we currently almost exclusively use LOD 0 anyway. One could try to tune the heuristic via
431 uncovered a few problems with the current LOD setup.
KMFs are divided into multiple mesh groups, usually to be able to assign different materials but sometimes also for high-poly models like GemHolder to overcome group size limitations.
That leads to an unexpected distribution of triangle definitions over the groups and LODs, not the typical descending order.
KMFs define a global number of LODs and for a given level the corresponding mesh group levels are to be combined for the final mesh. If one is empty that group doesn't contribute to that level. In JME otoh the LodControl determines the level to choose independently for each mesh group, leading to incorrect combinations. One way to deal with this could be to merge mesh groups that use the same material. There's just this unknown variable mmFactor to consider (inverse factor in mipmap level decision (falloff?)?)
This hasn't surfaced yet cause the way LodControl works, together with the low polycounts, means we currently almost exclusively use LOD 0 anyway. One could try to tune the heuristic via
But overall it's questionable if the complexity of dealing with all this is worth any potential runtime gains given the low polycounts.