I also just tried the "limit" thing in Morph Maker, setting it to 10,000. No changes here either. I was very hopeful of the "add as morph mesh to package" method but if even that doesn't work then I feel kinda hopeless. :/
If I understood correctly, LadySmoks' method ends with either converting to BGEO or GEOM morph mesh as well in MTK so I suppose it'll have the same problem.
Maaaybe we can find how this is calculated in the game code so that it can be overwritten?
Don't know what else to try now so just throwing ideas.
Other than Cmar, I think Bloom, cmomoney and WesHowe were knowledgeable about this stuff (maybe?) but don't think they are active either.

While I haven't taken the plunge from looking at the code to modifying it yet, the idea certainly crossed my mind- especially because of LazyDuchess' latest release. Previously, overwriting how the game handles one small thing would have been a bit of overkill to core mod. Mono Patcher at least makes the concept a bit more accessible from what I can see, if anyone looks into it and it's possible to adjust without breaking other things.


@LadySmoks unfortunately it was the morph mesh that didn't work when replaced, which has different data than a regular geom
But that did give me the idea to add it with MTK first and then replace it manually- which worked! But still has the same small flaws all of the methods result in- which at least means, unless SmugTomato implemented the same limitation in their morph exporter, it's the game itself that interprets morphs imperfectly.

I tried searching for morph related stuff with ILSpy but couldn't find anything useful yet. - And don't really count me on that cuz I'm not really an expert in this area :P
But yeah, if we ever find it, Mono Patcher will be extremely helpful.

OK, just throwing poop at the wall to see if any sticks! There is also the morph match tool. again I think I used it once, quite a while ago, don't remember if it worked, but...

Alright, after some more tests, I concluded that this is not related to vertex count. I figured this out by deleting most of the mesh to reduce the vertex count as low as around 400-600, leaving only the nose. Tried the nose slider morph again, and it was still messed up. This means even low poly mesh morphs can have this problem.

So I thought of trying smt else. Scaled up my whole high-poly face together with the morph by 800%. Voila, problem is gone. So, this can either mean: 1) Bgeo doesn't like vertices being too close and discards some, or 2) As CardinalSims speculated smt similar b4, when the morph values are too small, they get discarded.

If it's the second one, then this can be avoided by making the morphs more exaggerated.

I also tried searching the cores a bit more (for the possibility of overriding calculation scripts), however I think those stuff is handled by the Sims3Common.dll so not really possible I suppose.

Also thank you everyone who offered their help so far! Now I will try making morphs with bigger margins. Still, let me know if you have any useful info regarding this.

As I look into C# a little more for other work (knowledge that will be able to circle back to sims projects, excitingly), it seems like this could be related to the inherent precision loss in the type of number used to store and work with these coordinates (float).
Explained well here: https://floating-point-gui.de/basic/

The more precise the value, the more likely to see the inaccurate rounding. Especially once positions of multiple sliders and bones are being added together, I figure.
Whether the morph code could have float swapped out for decimal without becoming incompatible somewhere down the line, I wouldn't know.