I miss making giant anime weapons! Making Corin’s saw from Zenless Zone Zero actually work!

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.

I just refer to the in-universe Harbor Freight manager NPC as “my wife” at this point

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.

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!

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!

Stance Stance Revolution 2 at Motorama 2024: Yes, It Did Happen!

Quick note: I re-organized how the individual project threads were categorized on the left sidebar. Yeah, “Done!” and “Not Done!” stopped being useful some time in 2009… But hey, the best time to make a change was 15 years ago and the second best time is now. Everyone’s grouped by type of build, whether it be van or robot or silly scooter. My next insurmountable multi-year sit down for an hour challenge is to update the static pages and make new ones.

Many moons ago, I finished a Stance Stance Revolution. I did in fact go to Motorama right after the fact, even if I’m years late with the event update! In fact, another entire Motorama is happening right this moment, but I’m sitting this one out due to having focused too much on Real Life and the Robot Trap House, not getting around to putting either SSR or Susquehanna Boxcar back together yet.

So, after Vantruck’s “redemption trip” in 2022, and doing a clean in-and-out with Coronavan in 2023 due to surrounding life and work obligations, it was obviously time to debut Operation IDIoc….

Nope, guess who hasn’t been above the Mason Dixon line since 2019? I decided it was Mikuvan’s turn to make the run back up to my weird culturally adopted second home (as my friends joke all the time that I’m a closeted central Pennsylvanian).

At this point in time, I hadn’t yet trusted Vantruck enough to make the long trip to Harrisburg. In retrospect? It would have been just fine. But I decided risking it at the time wasn’t worth the cascading costs – see, at least the Tail of the Dragon was within one AAA tow radius, and with Mikuvan they don’t have to send out a different truck after finding out the first one was too small despite me telling them exactly what it is.

Somewhere north of Roanoke, stopping both for lunch and to peruse the hardware store for stuff I forgot to bring, such as….

… a weapon lock for Stance Stance. I grew fond of using these big D-style hitch pins after doing it for Sadbot for Comicpalooza. I just got one big enough to thread through both discs at once. Bringing it into the store and test fitting pins one by one definitely drew a lot of conversation, and there were even some BB watchers!

The rest of the trip was completely uneventful, which is an abnormality given Mikuvan’s history of enjoying the Shenandoah Valley scenery just a bit too much. I cruised into Harrisburg around dinner time and got my usual hotel room at “whoever still has vacancy and not bugs”.

Here we go! It’s Saturday morning and everything’s passed inspection. I got to drive it in the real arena surface it’ll be on, and I confirmed that the worm drive was a surprisingly good idea. Weapon spinup was rapid, a consequence of me designing more for torque than raw speed because I’ll likely be using these things as reaction wheels often.

The only issue was the roughly 3mm of ground clearance. That was not something I could make better on the fly here, but I figured I’d use the weapons as said reaction wheels if it got hung up briefly.

The first fight was against a two-part multibot, two little TPU bricks working together named BDT. Not to be confused with Jamison’s legendary DDT. The fight is at 1:54:40 in the day 1 beetle stream.

This was an endurance fight, and SSR didn’t endure that well. It spent much of the time (as designed) bouncing around the arena on the blades, but either that or one of the hits caused a weapon motor shaft to break off.

If I had to guess, something bent just enough that the gear’s hub got caught on the disc. This was something I had thought may happen because the gear hub sits outside of the swept circle of the blade’s hub, so it could in principle hit the spokes. A lot of gear-driven weapons make sure the blade hub is a little larger than the center axis of the pinion for this reason, but I didn’t have the weight this time around to make the blade hub larger in diameter. Something else will have to give here.

The other weapon broke down because one of the motor wires got loose and was minced by the gear drive or blade. That’s just first-fight debugging finding all the ways you didn’t zip tie everything like you thought you did.

Knocking down the weapon drive system was quick, allowing me to assess the roots of the damage. I think the two-piece motor and weapon shaft mount (that bracket) might still be just a little too flexible, so maybe I can redesign it with the carbon fiber plate also covering part of the area to increase rigidity and unify things more too.

Because I didn’t want to sacrifice a spare weapon motor yet, I simply retrieved the shaft from one of the spare drive motors (of which I had more) and smashed it together again and sent it.

And send it did. SSR died a valiant warrior’s death against Mulsanne, a P1 beetle with a scorpion’s tail style spinning disc. This video is at 4:36:32 in the stream capture. This was a fight full of knocking chunks off each other until Mulsanne lined up the best possible killshot and cut through the 1mm carbon fiber baseplate and 3 out of 4 cells of the battery!

I honestly think I hit him more off-kilter and upside-down than driving on all 4 wheels. One of the weapons died about midway through, leaving me to actually take myself seriously and use the remaining disc as a reaction wheel to turn and drive for the last 30 something seconds.

Oof. What a way to go through. SSR skating around identifying as an undercutter or gyro walker for much of the time somehow made the whole affair worth it. I have enough spares to put this thing back together as-is, but am going to make some mods to the weapon designs as I mentioned earlier.

Not too sure what as of yet, since the thing is so packed full of gear that there is scant little to just remove weight from. Plus, I’m not sure how much thicker of a baseplate could have stopped that weapon anyway. It might be better to just trim some beef from the weapon hubs and go for reliability changes. Just don’t get hit, duh.

On my way back down, I decided to detour after staying a night near Roanoke again. This time, I went back through a different portion of western North Carolina to explore some roads that I wanted to visit, but because the east-of-Asheville area is a little long for a day trip, haven’t gotten to.

I do need to just spend a week wandering the whole place. I keep saying that, but am very bad at actually putting things down and doing it. Hence my recurring mention of day trips here and there.

It turns out the ass end of Route 197 isn’t paved, but no big deal. With excellent sightlines down the mountain, I just played some Rally Van Simulator.

A friend somewhere at the bottom of the mountain before I found my way back to US 74.

The ship landed some time after midnight Monday into Tuesday, upon which I neglected to unload any of the robots or gear for a solid week. No issues at all out of Mikuvan this time (which I again emphasize how unnatural this is and may indicate a credit line building for a future epic road trip explosion), except maybe the new radiator I installed the year before was too effective. I may have to check the thermostat and see if it’s stuck open some.

These events transpired right before I turned my attention to Vantruck to finish “Patch 1.1” and hit the Tail of the Dragon in April. So I spent a bunch of time after that in post project hangover mode, not touching a robot again until August in preparation for Dragon Con.