When PRPL was engaged to work on an interactive minifigure builder for LEGO, I was naturally excited to jump into the project. However, we first had to figure out how to make the pieces from different sources fit together and work for the React and WebGL application. The goal was to have a three-dimensional minifigure that had swappable textures, think skin tones, torsos, legs, and hair color. The figure could also wear varying accessories like hats, helmets, and wigs that could then be posed in various positions to be printed in a unique take away comic.
When we received the initial assets, we faced some challenges in formatting and exporting the files. The rigged model files came as FBX files, owned by Autodesk. Luckily, these were able to open in Cinema4D (Maxon) for processing the model with minimal issues. We also received separate animation sequences in the form of a skeletal rig — more on this later. Most textures came as Targa files, as one might expect, but were not mapped to the model yet.
We carefully planned how we layered textures in order to avoid high memory loads that could crash the platform.
Getting the model ready for use wasn’t exactly plug-and-play; the materials had to be reworked because glTF takes the PBR approach to describing materials. We were provided detailed normals, but the original file sizes were crashing the iPads we used for testing. We also had to incrementally change and test the rig’s structure to ensure a proper export out to the builder.
Hats, Helmets and Wigs
Each piece of headgear had to be processed just as the model, and we needed to ensure that each piece’s “zero position” was properly set. This was necessary so the piece would stay in position on the head while the minifigure was being posed or animated.
Some torsos had necklines that would show skin, so we had to devise a performance-friendly strategy to hotswap the base skin tone materials behind the “shirts.” In this case, one can’t stack textures like one might in a 3D application, a limitation inherent with glTF PBR materials, as mentioned earlier.
Generally, information and documentation in relation to working with C4D, glTF, WebGL and THREE.js altogether was hard to come by. This was mostly due to some of this technology being new and coming across uncommon issues due to the specific architecture of this product.
Breaking Down the Pieces
ThreeJS manages the model data as a JSON object, so for example, placing a hat was only a matter of inserting the new object at the proper hierarchical point of the glTF map and of course, removing the old one if it exists.
Busting a Move
Remember those animations I mentioned earlier? Throughout the project, we were running into some issues getting ThreeJS AnimationMixer to play nice with our application configuration. This was one of the cases of little to no documentation for our very specific use case. It wasn’t looking good for animation cycles in the final release, but the day before we shipped the product, we finally had a breakthrough on the management system for triggering animation cycles. In the nick of time, the entire app came to life. Suddenly, your very own minifigure is reacting to changes you’re making in real-time, checking out their legs when you change the pants, admiring their new hairdos, and finally, dancing when you completed the build.
Before we had reactive animations working, we did have a basic idle animation of the minifigure breathing, but the builder felt flat. Solving the issues we came across was worth the trouble at the end of the day. Interactive elements that give a product personality are crucial for experience design, as long as the interactions remain unobtrusive, and in this case, we didn’t add time to the overall builder experience, just elevated it.