I’ve been playing a lot of Zenless Zone Zero lately (perhaps too much) since it has such fantastic anime tiddies story and universe building, and it made me realize something: Can you believe that the last time I made an impractically large anime weapon was basically ten years ago!? Have I really been doing nothing but fixing vans for this long? Well, we need to change that.
Zenless appealed to me a lot more than other live-service gacha games that many of my friends have played for a few years, such as Genshin Impact. I was never a wizards and superpowers guy; most fantasy and mythological settings have therefore never appealed to me. Yes, I read Harry Potter and Lord of the Rings in grade school for free pencils and stuff, why do you ask?

I was more about the robots. And not like Star Wars intelligent robots, but Real Robots. Yeah, I was a robot snob from the beginning. Therefore, I was quite excited when Zenless was announced since it combined my preference for carbide-hardness urban grunge with the simple fact that most of the game was just anime girls wielding caricatures of power tools. It’s pretty much just cosplaying in MITERS all over again.

Okay, to be fair, urban fantasy is still fantasy, and everything in the game is still powered by funky woo-woo energy you can summon, but at least the problem is the right shape for once. It was nice to be excited about an upcoming game again, especially one that promised a larger audience with a lot of buildables as I try to drift back into the cosplay world.
Many moons ago, the show we were all obsessed with was RWBY. In fact, if you squint just a little bit, the whole schtick with Team JACD came from thinking that making ourselves a RWBY faction reference was a good idea. The series had a lot of characters with diverse weaponry types (that all turned into guns of some sort) and operated solely on Rule of Cool physics.

I was a major party in making Ruby’s scythe (which we were obsessed about) happen. Its final iteration was brought to Dragon Con way back in 2015. This one had a telescoping body and an unfold mechanism that was intended to be powered, but we mostly ran out of time.
Believe me, the urge to revisit this one is real. Between then and now, there have been quite a few successful designs that replicated the unfolding motion and physical packaging to varying degrees of faithfulness, so I haven’t taken any action on it.
Getting into Zenless, though, definitely kicked my internal cosplayer in the ass; he who had been buried under many layers of machine grunge and van grease over the years, and had mostly been going to conventions solo and in plainclothes for a few years, might finally get a chance to shine again (Enjoy your friend groups while you have them, before they become Grill Dads and wonder why you haven’t grown up yet. I’m only mildly bitter, I swear). Corin’s pizza cutter/pole saw thing seemed to be the best place to start, since it really just had one degree of freedom and didn’t meaningfully change shape.
(She’s also my most built-up attacker and favorite character in general, I mean – maybe there was some bias)
It’s also way taller than she is, always a good sign of a well-designed anime weapon. And MiHoYo has generally made their game assets accessible for the fanbase to make …. content … from. A lot of 3D tchotchke databases, such as Cults3D, have either game asset rips or handmade files of her weapon:

The direct game asset conversions aren’t very helpful on their own, because they’re usually just the meshes straight out of the game files and so are just one-body or one-surface representations. I knew I was going to have to deconstruct then reconstruct these at any rate, because it’s not like the game has any actual mechanisms powering these things inside.

I nickname this process “inverse engineering” – an unholy union of reverse engineering, which is taking an existing and working thing and trying to figure out what they did, and regular engineering which is making a thing from scratch based on requirements and boring shit like the laws of physics.
Inverse engineering is taking a thing which definitely does not work and turning it into something that does, while also having to obey stupid rules like the laws of physics. This is part of the reason why I am a hard-edged sci-fi enjoyer; stuff instantiating out of thin air after some incomprehensible utterance is just ick… and is also why Ruby’s scythe was so hard to work with, since parts of it really do just shrink or expand and fly in and out of other parts. Just stick with really gussied-up nail guns, devs.
Have a look at the model above. I was very lucky to find someone who was crazy enough to make it from scratch, in SOLIDWORKS. Like, that takes immense time and energy to do, because Solidworks is not exactly a sculpting tool, but somehow this guy did it.
I’ll just say that it is very frustrating to deal with only common STL files from an engineering perspective. The basket of triangles that is STL doesn’t preserve any surface definition information. There’s no real flat faces/planes (definitely not when you try to import them into a solid modeler) and no concepts of higher order entities like holes or degrees of freedom. No brain, just triangle.

There were still some downsides, though. The design came as three giant solid bodies containing only superficial details. A “cut” version was also provided which was intended for you to be able to 3D print everything on a smaller machine and glue the result together. I didn’t find that these cuts were in particular useful spots, though. And plus, I needed the mechanisms.
None of this is something I pin on the skill of the designer: This thing is a master class example in using direct body editing moves that I almost never dare touch. It was actually refreshing to click through the feature tree history (something STL and most mesh exports DON’T have!) to see how certain geometries were made simpler by decomposing them into a series of boolean options, surface offsets, etc. Stuff I don’t touch as much since I mostly focus on making easily manufacturable machined parts day to day.
But let me re-iterate just how happy I was to have a SOLIDWORKS! file of this thing. It meant I could get to work immediately, without having to fire up Blender to start cutting up the game asset mesh files myself and extract chunks of them to then design around in Solidworks or Inventor.

So let’s get started!
Step one? Change the big center handle pipe size from 40mm to 1.5″. This is America, we love feet (and this game loves… uhh, feet) and I can more readily obtain a 1.5″ thin-walled aluminum tube than a 40mm one. I made several derived parts from the “master” one piece file that contained elements I thought could be made individually.
If i had to do it with the “from scratch” process, I’d probably have similarly cut off the tail in Blender and boolean cut a 1.5″ cylinder out of it. But, I’d have to keep track of part evolution in two different software and have to re-save and re-export, then re-import the modified part file every time I needed to make a design change. Basically, if I haven’t hammered home how happy I am that this is a Solidworks model…

I’m doing the same thing now to the main body. Make a derived part from the master file, then start slicing everything off with surfaces and cut-sketches until I have the element I want. Then start drilling holes in it!

This neck bottom portion now has the basic geometry I wanted in it: A 1.5″ (really 1.53″, as a bit of built-in real world material tolerances slop) really deep hole with two places to add crossing bolts. The whole time, I was thinking of where to place future fasteners and what shape they might take.

Not bad for a beginning session. I had four parts completed here:
- The spike tail
- The pole
- The P-shaped neck base piece
- and the two outer neck pieces
After these trials, I had a pretty solid understanding of the workflow that was needed for the rest, so a lot of things came together quickly:

The colors are my attempt to keep everything visually separate so I know what is an individual part. That they are largely Miku-adjacent colors is a complete coincidence.
I had to think ahead a lot about what kind of structural elements need to live inside to support the sheer weight and girth of this thing. I decided that 3D printed elements alone weren’t going to hold it together, and designed ahead with the intention of backing up all of these visual elements with cut carbon fiber or fiberglass/garolite plates which were going to take most of the loads.
So, the outside visuals were going to be very hollow decorative prints, whereas I was going to previously enhance them with structural ribbing and gridding.

Those bike forks were a real pain to deal with. First of all, they were not flat bottomed (bottom here defined as the inside face, where I’d stick them on a 3D printer build tray) and needed a slight trim with an angled cutting plane to make them flat.
This would allow them to sit flush against a backing plate, such as the plate skeleton I wanted to design in. The geometry here was also very complex, and I had to make a bunch of multi-element cutting lines to extrude into cutting surfaces.

The first real “Engineering™” exercise of this build was going to be the saw portion itself. First of all, it’s a RIM SAW. Like one of those hubless motorcycles, it’s hollow in the middle and you can see through it.
So what the hell is that disk brake looking element actually grabbing? What the hell are you cutting with a 2 inch DOC? Who the hell knows, anime girls are all made of TPU anyway.
I started by making a chain of derived parts:

First, isolating the saw body from the master model.
Next, I blasted the saw body apart into distinct profiles, since it has multiple visual elements at different thicknesses and diameters, but it was all in the same file. This was made easier by commandeering the sketches the author made when crafting the saw geometry. I called this the secondary master file.
Then, I made individual parts from this file, so each profile became something I could edit to make manufacturable. The secondary master file handled upstream changes like giving every piece the same center diameter, number of teeth, and so on. This was not easy and was a lot to keep track of!
We take a quick detour here into the REAL WORLD: How on earth do I make an 18 inch diameter spinning, hubless rim?
I went through a lineup of the usual suspects. Do I make a sweet custom skate bearing setup like making a rimless bike, with the ring driven like clockwork? Do I go try and find a jet turbine main bearing on the surplus market? Maybe, if I want it to weigh 20 tons. Do I just throw some PTFE tape around the hub and grease it real well and call it a day?
Nah, the answer is a Chinese restaurant turntable bearing apparently.
I went shopping on the usual places (Amazon and eBay) for big ring bearings, and after sorting by price to get the $37,000 excavator main slewing rings out of my search, found these in various sizes.
I went ahead and bought a 16 inch OD one, the closest diameter that lined up well with the inside features of the saw. These will be found as “aluminum alloy turntable” or similar phrases, and are very bare bones: Just greased steel balls running cageless in aluminum races. Don’t expect very long life out of these in jet turbine power stage bearing service.
Going back to the design of the cut pieces, I had to bridge a roughly 1″ gap in radius between the bearing and where the saw’s visual tooth features end. I was trying to keep the weight of this thing down because, after all, anime girls are made of TPU.

I hollowed out as much of the material as I could – practically all of it inside the radius of the decorative screws will be hidden by the conical lid of the saw (again… what the hell are you cutting with a conical, rimless saw)
I made “fingers” that extended from the ring to the OD of the bearing. The idea was to split the rings into fractions, each containing three fingers to define their curvature and how they sit. The splitting would keep the cost of manufacturing down (they charge you for waste material too), and I could fine-tune the fit of each piece by gently filing the fingers if need be.
The actual attachment to the outer ring of the bearing would be taken care of by a small bridge plate with both hole patterns (hence why the fingers have holes at the ends)

To attach the whole thing to the motorcycle forks, the ring bearing needed a support structure inside it. Luckily, this could pretty much be only one shape.
- It has to have a six hole pattern to bolt to the bearing
- Part of it has to be missing to support the fake brake rotor geometry
The center bolt pattern could be whatever I pleased, so I just picked a bolt circle diameter that pushed up against the maximum of what the decorative endcap piece on the forks could provide. This could always be mushed around later.
With this geometry at least conceptually in place, I moved onto making the conical lid, what I called the “UFO”. This part I’m documenting in full, step by step, because I did something similar a long time ago and then forgot it, so I had to scour the modern Internet for information (challenge: impossible) to re-learn it.

The problem is that to make a cone in real life, you usually have to cut a Pac-Man shape and then roll/curl it to close the edges together. To model that sheet from dimensions of a known cone, you have to be able to flatten it.
CAD tools have facilities for making sheet metal parts using industry-standard practices. I found that Solidworks didn’t want to take a solid modeled (profile-revolved) one and flatten it, since that implies stretching and distorting the material in real life (like one would stamp a bottlecap or something from metal). I might have been able to use the Rip feature to accomplish it, but I don’t actually work in Sheet Metal world often.
To get around this, I had to revolve the profile only 359.9 degrees, or some other tiny fraction short of a circle, so there is always an open edge. The gap can be so tiny that it doesn’t matter in real life, but it has to be there.

Therefore, I used the Extrude Thin feature on a line that I drew according to roughly how it looked in the original model, and accommodating the center hub features I would come to need. I made a rotated sketch plane to start this off upon, such that the future seam is fully hidden by the motorcycle forks.

Next, I revolved the profile 359.9 degrees as promised.

After the body was created, I made the cutout window for the brake rotor feature.

Two things then happened. For one, I changed how the saw teeth attach to the ring. Instead of a 3rd bridging plate/ring unit, I decided to just extend the fingers on one side to meet the bolt pattern of the ring bearing! This will save yet another part being made. This does mean, however, that the saw is no longer centered on the bearing axially (it’s not symmetrical if flipped front to back) but I can mush around the axial placement using the center hub design.
The second thing is that now with the UFO body in position, I could use it as a reference to extrude walls around the brake rotor and add mounting ears. If I change the cutout dimensions, the walls would change with it. This did occur a few times as I worked out the final dimensions for everything.

While thinking about how I wanted to mount the UFO to the center hub and the whole assembly to the motorcycle forks, I cleaned up some more “rote” tasks like making wire access holes and channels, as well as clearance points for the nuts and bolts to hold things together.

I’ve modeled the carbon fiber plates here as well. They are just wholesale profile-derived from the visual geometry, with added mounting ears in some innocuous places to hold the outside pieces on with tiny innocuous screws.

About this time was when I decided the motorcycle forks really needed to be two pieces. For one… it was larger than my biggest printers’ diagonal. The Ender 5 Plus has a 350mm square build area, but yeah this thing was closing in on half a meter. The rounded ends meant I couldn’t fit it at all on the 45 degree line.
Besides that, the circular endcap on the left and the main body are different colors. So it would make the paintjob easier if I could just do them separately.

Some of the parts, such as the fork outer pieces, got tiny holes in them for thread-cutting screws that will drive from the inside of the carbon fiber plates to hold them in place.
Honestly, most of the thing is done at this point. I just had to clean up some of the geometry to ready the outer pieces for 3D printing, and the plates for exporting and Sending-Cutting-Sending.
But all this time I was also debating how to execute the Important Part of the project: making the ring spin.
I didn’t spend a bunch of time pre-gaming this design because the interior of the saw assembly was just wide open. I sampled a bunch of motors from my Male Emotional Support Treasure Trove of Mechanical Parts to see which one might be a good candidate. The system had to be dead simple and lightweight, so no encoders and controllers here. Just one button on or off!
It also couldn’t actually spin fast or anything, because this is still going to an anime con. Believe me when I say it took a lot of restraint to not put 10 horsepower into the thing.
The ideal motor here was one which was mild-wound or wound for torque, like a servomotor or small appliance appendage wiggler. My choices were also informed by the fact that I found I had a little bin of roller wheels from an ATM or other paper goods handling contraption. The rollers were a moderately hard rubber and felt like they’d be a good match for the slightly textured finish of the aluminum ring.
That Mabuchi 555 motor up there was my first grab from the bin, but it’s really too big. I ended up deciding to use a smaller size 395 “long-can” motor – monikers that only really old and crusty robot builders are going to recognize at this point. The rollers fit directly on the 395 motor with its 2.3mm shaft instead of needing me to machine the hole out, so that was a plus!
(Yes, I was making parts before this last bit ever got designed – very typical Gantt-Chart-less behavior from me)

Let’s start off with a bracket. I positioned the motor roughly where I needed it to be and just made a big bridging piece over two of the spider arms.
The mount for this motor had to hold it against the ring with a little bit of pressure. Enough to have traction with the roller, but I didn’t want it to take a ton of power to run. I was looking at making a spring-loaded drive so I could try different stiffnesses of springs to see which one gave just the right amount of pressure.

With the motor and Bracket™ position known, I started growing some features.
The total thickness/height offset is adjustable with manipulating the height of the two ends of the bracket. The thick portion near its center is the future hinge point for the motor mount, and that is fixed at a diametrical plane of the whole assembly. I could also shift the radius of the bracket to move it closer to the ring or further, but the edges and mounting holes always followed the spider piece.

The motor mount itself is a simple clamping design. Start with a tube, add a way to squeeze the motor, and then add the ears to attach to the previously designed bracket’s pivot tab.
I then added a rear “platform” to seat a little coil spring and knocked off a bunch of geometry to conserve weight and material.

And here’s what that assembly looks like. The design called for a small coil spring with a starting length of 3/4″ (or 19mm) which gets compressed down only about 1/16″ in operation. Enough to keep a thumb on the motor.

And… here we are. The completed, inverse-engineered saw assembly. What started as a monobloc body has been knocked down into an assembly of individual parts and the mechanisms needed to make it move. I didn’t bother modelling in components like the battery holders or on-off switch. That was just going to be entirely freehanded after it was made, wherever things decide to fit.
I already revealed before that I was basically making the back end of this thing while still finishing the front, but… on the next episode, building it up and testing!