• ❔At the moment I don't have the Switch and Miitomo body models..
• ❔Poses from the Wii U Mii Maker are planned as soon as skeletal animations work.
  • Every pose is just a single-frame animation from MiiAnim.bfres, same source as everything else.
  • I'm pretty sure the camera positions are in JpgPoseCam.bfres, but Switch Toolbox cannot open it, so... not sure what I'm going to do about that.
  • Either way, I'm continuing to delay and hold off on this until getting body scaling perfect. Sigh.
  ❔Need to reverse the Tomodachi Life and Miitopia QR code formats. Miitomo codes are planned as soon as Kaerutomo properly implements them.

  • To be clear, this is not referring to being able to merely scan their codes, but rather make use of the extra game-specific data within.
  • ... For example, applying the custom colors (hair color, etc.) within, displaying their voice or personality traits...
    • In the case of Miitomo, this means extracting the "nx_mii_core_data" Switch data that QR codes are supposed to give you, for the wider colors.
  • I actually did find the AES key and was able to make an encoder/decoder for the extra data within these codes for all of those games, check it out: https://jsfiddle.net/arian_/ckya346z/8/
  • For Tomodachi Life and Miitopia, all of the data is within the code and just needs to be reversed. For Miitomo, it's more complicated, and sadly existing codes won't work, because:
  • It looks like the only thing Miitomo stores in the QR code is some sort of ID ("token_for_json_data") - it expects the server to store the extra data with this ID and will use it to retrieve that data back from the server.
  • Problem is, Kaerutomo does not store or retrieve this data for you. At all. And since it's not open source, nobody can add it except for them, and they aren't interested. 😐
  • (If you are a Kaeru dev reading this, PLEEEASEEEE get in touch!!! 😭)
• ❔Extremely minor: the mask texture is transformed slightly differently between the FFL decomp and real FFL/AFL/nn::mii.
  • This is probably one of the last things left to achieve pixel-per-pixel perfection.
  • This is the Mii I usually use for testing this: Mii Studio version, my render
  • It's not obvious what is wrong here, as many functions look identical in Ghidra.
  • Note that this is only with the mask texture (not shape), and FFL 1.3.10/AFL/nn::mii do this correctly, all have symbols.
  ❔Replicating 3DS and Wii renders has been considered but isn't easy or a priority.

  • This requires extracting the meshes (and textures? but those can be downscaled from the new ones) from CFL_Res.dat, but its header hasn't been reversed.
  • As of October 2024, the Kadokawa leak includes debug versions of niconico with DWARF information for CFL - Contains all of the structures needed to extract the resource. Cool, right?
  • I think it would be nice to have an extractor for CFL and RFL resources (since they are so similar), especially since the one RFL_Res.dat editor everyone uses both isn't open source and I have also heard that the creator lost the source code.
  • This is not something I have gotten around to doing, though if you contact me, I would love to elaborate on all of this and give details.
  • Aside from that obstacle is shaders, neither of the Wii or 3DS use GLSL-compatible shaders. This can probably be worked around (or remade since it's very basic) but is still annoying and just one more reason not to do it.
• ❔Miitomo/Tomodachi Life clothing/headgear/wigs may be planned.
  • Don't expect any of these any time soon, especially clothing.
  • Do keep in mind that these body models are different from the Wii U/Switch models and therefore the clothing may not work on those.
  ❔Fully rendering Miis in the browser is a longterm goal of mine. I can't promise anything, but I am steadily working towards it.

  • As of October 2024, the FFL-Testing master branch fully builds with Emscripten and works on WebGL 2.0, and I even have a Mii rendering sample in C and raylib that works on WebGL 1.0 (contact me if you want this)
  • So what else is left? For starters, the assets need a more efficient compression method instead of zlib. I'm thinking of using Draco for meshes, and then ASTC for textures. As of writing, neither are implemented yet.
  • An interface will need to be made to bridge the C exports of FFL to be callable from JS, and then make a shader callback implementation in JS using WebGL or three.js.
  • So I haven't gone that far with this, and have not yet connected FFL in WASM to JS. But...
  • As of October 2024, I have a little jsfiddle here that will read a Mii exported to glTF from my site, and render it with the Wii U shader! Isn't that nice?
  • Now, once this is properly implemented and working, I can't even begin to think about the possibilities. At the minimum, this site could go serverless, and services using Miis may not even need to render and store icons on their side. Woo.
  • As usual, if you want to help or put pressure on me to work on this with more haste, ping me.
• ❔I've thought about making a Mii Maker-like app with the FFL decomp, but... don't get your hopes up too far about this.
• However, if you like the sound of this...
• ... and you're either working on something like this right now and it just needs Mii heads, OR you'd want to design the UI for this and let me add the rendering logic, do get in touch!
• (This is assuming, yaknow. it's not a Scratch or Roblox game or something)

Unplanned:

• Custom hairstyles or frankly custom anything
• Miitopia makeup, or custom expressions (sorry)
  • Miitomo expressions are the only exception, since they're built into AFL (its version of FFL). See?
• BoTW/TOTK models, or "semi-Miis"
• Xbox Miis, Apple Miis, Samsung Miis, any other stupid bootleg Miis
  • Never ask me for these 🤬