Mii unsecure website added support for blinn (3DS like) shading, miitomo expressions and full body rendering!
(Here are some miis i rendered with the new options)
Site isnt mine, i was just spreading the word for people to play with it, and maybe implement it on their own applications, since the site gets your FFLStoreData (Mii data) by QR, NNID/PNID and even amiibo data, cool stuff!
Finally, our Miis can have proper pants!
i wanted to mention this amazing Mii Editor that works with Mii Unsecure’s API and has all the features to edit/make Mii, and It renders it live!
its the craziest thing ever, shockingly web based, It literally renders the Mii in 3D real time!
It would be nuts if Pretendo redesigned their Mii Editor to something like this, just saying!
Site was updated with custom hat features to use in renders, and a new theme resembling Wii U Mii Maker designed by me.
Try it out! i guess… lol
This is pretty fire I know we got off on the wrong foot a while ago but good work
This uses Arian’s renderer to do the rendering, no? At least it says it uses “a version” of it (I assume there’s some fork powering this under the hood?)
While it is true that the work done by Arian is impressive and the results do look fantastic, there is a number of reasons as to why we likely won’t be adopting this for our own purposes. At least not anytime soon
Let me preface this by saying that we have nothing against Arian and we do acknowledge the work that they’ve done here. This is not a diss or anything personal
While we have nothing against Arian at this time, there was a time where there was some bad blood. I fully acknowledge that a large reason for that was my fault and my fault alone, as I had a misconception on some issues regarding Arian from a few years ago (which I will not get into, as it’s old news and irrelevant and there’s no reason bringing up old, incorrect, bullshit). These tensions resulted in Arian licensing their work under a license that said “anyone can use this for anything so long as you aren’t Jon Barrow or affiliated with Pretendo”. Later on my misconception was corrected and I apologized to Arian for the trouble, and the Mii renderer was then relicensed again to a regular license. However the commit message seems to imply we would “fuck up” the renderer in some way, which tells me that there may (understandably) be tensions from Arian’s side and we would have to be cautious about potential future issues with things like licensing
While we ARE looking to change our Mii renderer (everyone on the team agrees that the current Mii’s don’t look the best, and it’s an official goal on our task tracker), part of that goal is to move AWAY from relying on a 3rd party rendering API. Using Arian’s would defeat the purpose since now we’d just be at the mercy of their renderer now rather than Nintendo’s. It would still have the inherent issues that come with relying on a 3rd party renderer, such as downtime we can’t control
I don’t really want to “abuse” someone else in the scene this way. Regardless of tensions in the past, Arian is someone doing work in the scene and I respect that. We have an incredible amount of traffic from hundreds of thousands of users, I would feel very guilty suddenly slamming Arian’s servers with that sort of traffic. There’s a real chance we rack them up a very high bill or harm their servers’ performance doing that. Which means the only way we’d be able to use this is to self host it
As for self hosting, I’ve looked at the project in the past and while it does work I honestly have my concerns about its structure (some of which cannot be trivially solved and I do not blame Arian for the design decisions). It’s split into multiple servers, the first being a standard HTTP web server. This server takes in HTTP requests, and then forwards the request data to another server for the actual processing/rendering (in older versions this was done with websockets but now it looks like this is done with a standard, basic, TCP socket?). This 2nd server is what does the actual rendering. It runs a Rio “game” in full, where the “game” just renders the Mii and then sends back the rendered data to the 1st server and back to the requesting client. Having a multi-server setup is not the end of the world (it’s technically what we do already, forwarding the requests to Mii Studio and using the result it gives us), the fact that the 2nd server basically runs a whole game under the hood is a pretty big drawback. This is not something that would scale well, and is pretty hacky to set up. Arian even acknowledges these issues in the README of the project:
There seems to be plans to improve this, as noted by the
TBD at the bottom, but it’s not there now
All of these reasons contribute to why we likely won’t be using Arian’s renderer, despite how good the renders are. Again, these are not personal reasons and we have nothing against Arian, the concerns are purely technical/logistical. Any solution we deploy ourselves would need to not have potential licensing issues and also scale well (which means not running essentially an entire game engine just to render images), and also neatly integrate into our existing infrastructure
However we are interested in changing our renderer, as mentioned before. It’s something that gets brought up quite a bit internally
https://mii.nxw.pw/ is just the 3D WebGL based Mii Maker client, but it also actually rehosts the instance of ffl-testing (https://mii-renderer.nxw.pw/miis/image.glb?) in another domain that serves the actual Mii head models/2D renders, which in fact, shows that ffl-testing (Arian´s actual mii renderer) can be rehosted in a VPS
This still doesnt mean its in a currently ideal state, that is true, but
maybe Arian will respond more clearly about this eventually…
The issue was never if it could be rehosted. This was already clear. The issue is, as I said, doing so at scale, which is a totally different issue. As well as integrating it into our existing infrastructure
It being hosted on a small toy site is vastly different than it being used as a full scale renderer for hundreds of thousands of people. Which is an issue even Arian acknowledges
Hi yes I’ve been meaning to respond for a while so here I am.
I’ll start by saying I genuinely appreciate your criticism, I don’t get enough of it. I’d like to set the record straight and give my perspective on these.
1 . My apologies for the license thing. If one of my reasons was that someone would mess it up, that would be my fault for the documentation not being good enough. It was mostly the serial number thing and a childish way to avoid reaching out to any staff specifically. That is all on me and going forward I’ll be reasonable with the license (even if all factors combined make the license questionable at best…)
2 and 3. Sorry if this was unclear - I never pictured Pretendo using my site specifically, it does in fact go down frequently.
I think objectively the account creation process shouldn’t straight up fail if it can’t get a Mii render, it’s inevitable and somewhat your fault when that happened to Mii Studio in May. But that’s besides the point.
I have no problem with anyone using Mii Studio, if for no other reason, because it’s free.
I don’t have a serious grudge with Pretendo, as you can tell I’ve been willing to help by submitting PRs.
Going to address the renderer itself now. Probably going to use this forum thread as a pseudo “blog post”, hopefully OP won’t mind.
I could talk for a while about why my renderer server is written the way it is, but one of the big reasons is: The combination of OpenGL and RIO is limiting. As grateful as we all are to Abood for the FFL decomp/port, well, in order to use it I kind of need to work in RIO’s event loop, and even then it relies on OpenGL which is notoriously inflexible when it comes to stuff like multithreading.
(You have the same problem with AFL by the way, even though it has the AFLPlatformGX “”““abstraction””“” it’s still over OpenGL concepts. Nintendo had to write Switch nn::mii from scratch in order to comply with NVN/Vulkan concepts)
Though… I have a feeling you’re overestimating how bad it currently is. The CPU usage of the server process is very low at under 4% when rendering, and I have seen requests for 256px images be as fast as 7-15ms from the server, excluding PNG encoding.
(With an Intel mobile iGPU - Will you be running purely on software acceleration? If without, perhaps it’s worth looking into Mii Studio-esque 2D composition…???)
Here’s a screenshot of me slamming the server with requests so you can see the latency for each one, although I know this should be graphed:
It also has no CPU usage when idle (in SERVER_ONLY mode…), blocking on accept(), and on my machine it uses <30MB of memory which is why I can justify running 10-20 processes - leagues more efficient than the old Cemu method.
So the real problem is the lack of multithreading, being tied to RIO/OpenGL, and then code quality. Yeah, all of the logic is in RootTask.cpp 
But! I have been making strides in trying to make FFL more flexible.
Here’s a screenshot of a sample I made in C to call FFL from raylib (another engine), without RIO or C++. Repo: GitHub - ariankordi/ffl-raylib-samples: Samples for rendering Miis using FFL, the Wii U Mii renderer, and raylib.
And as you can see, the sample also works on Emscripten and GLES2 (WebGL 1), an OpenGL version not supported by RIO.
You could imagine this being used for that Mii Creator site eventually, or, maybe even imagine: if Juxt did all Mii rendering in the browser… could potentially be an opportunity to reduce quality of renders served to 3DS/Wii U? Make them non-transparent JPEGs? Just spitballing here.
One of the reasons I’ve held off on making a nice JS interface to use FFL on the web is that I want to make the resource files reeeally small - using Draco for meshes and ASTC for textures. But I mean, there is nothing stopping anyone else. Currently it’s 2 MB total for the middle resource and WASM code.
More interestingly, I have this sample written in C#, calling FFL through P/Invoke, and drawing a Mii using Veldrid through Vulkan, D3D11 or OpenGL.
The screenshot shows RenderDoc saying it’s really Vulkan. Neat, huh? Repo: GitHub - ariankordi/FFLSharp: C# bindings and Veldrid implementation for FFL, the Wii U Mii renderer.
No FFL shader on this one, I still have to do some code cleanup in order to get there aanndddd if I’m being honest I lost interest with working in .NET after learning the debugging experience is terrible on Linux 
so I doubt I’ll do anything serious with FFLSharp - except if I decide to make a Unity plugin out of it.
So with all of this, of course I am not done with Miis, not by a long shot.
As the “prototype” label suggests I always intended to rewrite the server outside of its current form, thoouuughhh…
I told myself to do this when I mentally considered it “finished” which means perfect matching with Wii U renders. The #1 blocker to this has always been getting the body scaling accurate. For instance, look at this shot of an official Nintendo render alongside mine on the left:
I’ve banged my head at this problem maaaaaaany times and neither I nor anyone else has had any success, exxxxceeeeepttttt until a few days ago where I was able to make a sample that does in fact do this correctly, wooooooooooooo…
So hopefully it won’t be too long until I get this PoC into something more usable and integrate it with the server. And all of this combined is a great opportunity to begin that rewrite I’ve been looking for.
Now, on that note…
It would benefit both of us to actually discuss things like this directly. I feel like I’ve only seen Jon’s messages through proxy. I was always curious about the AFL thing to see how much you’d found out about it that I hadn’t yet.
(There is also some Kaerutomo stuff I want to ask Shutter about that I already told a dev about and they never replied. I want to add a feature you’ve been missing for years for freeeeeeeeeee and I literally reversed the Miitomo obfuscation that they never documented, on my own, just to get to iiiitttttttt ) …
And also that there’s just barely anything about Mii rendering internals on the internet, it’s niche and we should all be working together.
If you need it, my Discord is .arian. and email is on my GitHub profile.
The fact that every Pretendo dev in this thread is liking your posts seeems to imply they agree and have complaints of their own. That kind of feedback would be extremely valuable if I begin my rewrite, or maayybeee eeveeen to collaborate? Since I’m still completely solo, and actually knew pretty much nothing about 3D until this year. I learned because of Mii. Even if you wouldn’t want to work with me I can still share my findings with you.
Finally, I will say this: even if I had nothing nice to say about Pretendo as a whole, it’s clear that the standards on this are high. For something like this, the replacement for Mii Studio can’t just be a little better, it has to be a lot better. A new solution for Miis can help a lot: it can be magnitudes faster, save space, look better, be easier to use, and more reliable than any third party server. I too see the current implementation of everything as just a substitute for Mii Studio right now, which is one of the reasons I haven’t been confident enough to shill my work on the forums at all.
Can you report all future bugs/issues to kat21 on Discord, thanks.
Pretty sure it was a bug. The site works now.
