Editing Un.mii (section)

==== Unique traits of the library ====

[[File:Un mii charmodelimpl.jpg|thumb|left|The CharModelImpl class, where some methods are shared and some are new.]]

* un.mii does not read any existing [[Mii Resources|Mii resource file formats]], instead opting to store and retrieve shape and texture data from the data.unity3d file, where you can indeed find shapes and textures for Miis in Pikmin Bloom's data.unity3d. The assets are also in the "un.mii" namespace.
** Shapes are categorized as "middle" and "high", as well as having "low" and "middle" textures, once again suggesting the NintendoSDK/nn::mii lineage. The files are named with their internal part names (for example, "FaceT_line06") and may match up with internal tooling Nintendo uses to pack/unpack Mii resources.
** Textures are stored in ASTC6x6, and stretched to the proper shape (e.g. eyes are stored in square shape)
* There are "TextureRendererBehaviour" and "FacelineTextureRendererBehaviour" types, suggesting Mono behaviours. There's also Renderer classes for both, containing a "CreateGameObject" method that clearly refers to the Unity GameObject type. Likewise, CharModel and CharModelImpl have references to the RenderQueue type.
* The "Database" class from nn::mii is kept, albehit just has three methods: GetDefault, GetRandom, and GetRandomVer3StoreData. So it has nothing to do with the [[Mii Database]], but functions are categorized there just like nn::mii did.

[[File:Un mii charinfo.jpg|thumb|Some unique methods in the CharInfo class. This is notably the only time it's called "Ver4".]]



Overall, it's just a port of the nn::mii codebase to C# with a few tweaks made for Unity. It's interesting given that nn::mii can be considered a port of FFL, with many pieces of code copy-pasted from it.

Ironically, given that Unity compiles .NET code to C++ anyway, it may have made more sense to just use nn::mii as-is using [https://learn.microsoft.com/en-us/dotnet/standard/native-interop/pinvoke P/Invoke]<sup>, like [https://github.com/ariankordi/FFLSharp FFLSharp].</sup> However, the reasons they couldn't include that all versions of the [[Face Libraries|Face Library]] heavily depend on the system/SDK's graphics API (GX, GX2, nn::gfx) and rely on their respective resource binary format. Interop with C libraries is also inconvenient and avoided in most languages, so combined with the inflexibility mentioned, is why they made the choice they did.

Notably for Miitomo they did go the route of modifying [[Cafe Face Library|FFL]] to remove GX2 calls and made [[Arch Face Library|AFL]], but it accumulated tech debt over time by trying to merge it with libnn_mii_core. It's less likely they would've done this for [[nn::mii]], given that the way it manually manages graphics buffers and pipelines makes it even more dependent on nn::gfx than FFL is on GX2.