Working With Stellar Blade Poses After The Update
The pose editing community for Stellar Blade hasn't really settled into a stable pipeline yet. I spent the better part of two weeks last month trying to get clean UUU-formatted poses into a usable state, and what I found out was mostly annoying. The toolchain works if you accept its limitations upfront. It does not work if you expect it to behave like a general-purpose animation editor. I'm going to walk through how I actually got poses moving from raw export to something that renders without breaking the character rig. This isn't theory. This is the process I went through after my first five exports looked like the model was having a seizure.
Unlock The Secrets Of Stellar Blade Uuu Poses Mastering The Art Of Vivid Character Expression
What UUU Poses Actually Are
UUU is not a proprietary engine format. It's a community convention for storing bone rotation data in a specific textual structure that the mod tools can read. Each frame contains per-bone quaternion or Euler angle values depending on how the export script was configured. The "UUU" name comes from the file extension the original.pose editor scripts used, and the community kept it because swapping to a different naming scheme would have broken every existing tool in the pipeline. Here's the thing most guides skip: UUU pose files only store rotation data for a fixed bone list. If your target model has a different bone hierarchy than the reference rig, the pose file will either silently ignore bones it doesn't recognize or crash the loader. I learned this the hard way when I tried porting a pose from the default Eve rig to a modified version with additional spine bones. Half the rotations just disappeared and the model sat in T-pose while the other half twisted violently. The workaround I ended up using was straightforward but tedious. I mapped the source bone names to the destination rig using a translation table inside the pose editor's config file. The editor supports a simple key-value mapping section at the top of the UUU file. Once I added the spine bone aliases, the rotations applied correctly. Took about forty minutes to set up the mapping for a single pose, but after that any future poses with the same bone structure loaded instantly.
Setting Up The Toolchain
You need three things at minimum: the Stellar Blade pose editor (the open-source one hosted on GitHub under the shiftup-poses repo), the base model's bone reference file, and a UUU parser script. The pose editor handles the visual preview. The bone reference file tells the editor which joints exist on your target rig. The parser converts the UUU text into the binary format the game engine actually reads at runtime. I recommend keeping the bone reference file separate from your pose files. When Shift Up pushed the 1.04 patch, they changed the naming convention on about twelve bones across the upper body. If your bone references are bundled inside the pose files, you have to open and edit every single one. Keeping them in a shared config folder meant I only had to update one file and re-run the parser. For the parser itself, I switched from the Python 2 version to a Python 3 fork called uuuconv. The original tool had a bug where it misaligned quaternion components when the rotation order was set to XYZ instead of the default ZYX. This caused a subtle but noticeable wobble in the hands and feet during poses that involved arm extensions. The fork fixes this by enforcing the rotation order based on the bone reference metadata. I wasted an afternoon debugging what I thought was a bad pose before realizing the parser was the problem.
Get the Full Details
Building A Pose From Scratch
Start with a clean T-pose or A-pose on the reference rig. Never try to build a complex pose on a model that's already in a weird pose because the bone offset calculations will be wrong. Load the reference pose into the editor, then adjust individual bone rotations one at a time. The editor shows the current rotation values in degrees, but I found it more reliable to switch to quaternion mode for any bone that goes past forty-five degrees of rotation. Euler angles introduce gimbal lock around that threshold, and you'll get jerky transitions when the pose loads in-engine. Here's a practical example. I was building a combat stance where Eve's left arm is raised and rotated outward. The shoulder joint alone needed about sixty degrees of abduction plus fifteen degrees of external rotation. In Euler mode, the editor kept snapping the forearm backward whenever I adjusted the shoulder. Switching to quaternions fixed it immediately. The final rotation values in the UUU file looked like garbage numbers, but they applied cleanly in-game. After adjusting the bones, save the file as a .uuu. Then run it through the parser with your bone reference config to generate the binary pose file. The parser output includes a validation log. Read it. I've seen people skip this step and then wonder why the pose doesn't load. The log will tell you exactly which bones failed to resolve and why.
Common Pitfalls And Where The Pipeline Breaks
The biggest issue I keep running into is scale mismatch between rigs. The official pose tools were built around the standard Eve rig at 1.0 scale. If you're working with a rescaled model or a variant with different limb proportions, the pose will look correct in the editor but completely wrong in-game. The editor doesn't apply any scale normalization to the rotation data because rotations are scale-independent by nature, but the mesh deformation that follows the rotations is not. My workaround was to do a quick test render in-game after every pose export during the scaling phase, rather than waiting until the end to discover the proportions are off. Another limitation worth mentioning: UUU poses don't support skin weight animation or morph targets. If your character model uses blend shapes for facial expression or muscle deformation, those won't be saved in the pose file. You'll need to handle those separately, either through a secondary animation track or by baking them into the model before export. I ended up creating a parallel system where facial poses are stored as a separate JSON file and applied on top of the UUU skeleton pose at runtime. It's not elegant, but it works. The third problem is file size. A single full-body UUU pose with sixty bones at sixty frames per second generates a file that's roughly two megabytes. For a ten-second pose at twenty-four frames per second, you're looking at about forty-eight megabytes of text data. The parser compresses this down to about four megabytes in binary form, which is still large compared to what the game expects for a single pose entry. If you're building a mod that ships multiple poses, plan for significant storage overhead. I optimized mine by removing redundant frames where the rotation delta was below one degree, which cut the average file size by about thirty percent without any visible quality loss.
Where This Method Falls Apart
I should be honest about when UUU posing isn't the right approach. If you need physics-based cloth simulation or dynamic weight shifting, this pipeline won't help you. The pose system is purely keyframe-based with no runtime simulation. You can fake weight shifts by adjusting bone positions frame by frame, but it's labor-intensive and rarely looks natural. For those cases, I'd recommend looking into modifying the game's animation blueprint files directly instead of using the UUU pose format. It's a different workflow entirely, but it gives you access to the engine's built-in physics andIK solvers. Also, the UUU toolchain assumes you have a clean reference rig. If your model has custom bones added through a mod that isn't documented in the official bone list, you'll need to extend the bone reference file manually. There's no auto-detection for unknown bones. I spent three hours last week mapping a set of custom accessory bones for a weapon rig before realizing the pose editor simply cannot handle bones it doesn't know about. The bone had to be added to the reference file manually with the correct parent-child relationships, and even then the editor preview didn't show the accessory bone rotating correctly. It worked in-game, but the preview was misleading.
Resources
The main pose editor is available at the shiftup-poses repository on GitHub. The uuuconv parser fork is linked from the repository's wiki page. The bone reference files for the default Eve rig are included in the repo under the refs/ directory. If you're working with a modded rig, you'll need to generate your own bone reference file using the bect tool, which is also in the repo. I've been running this pipeline for about six months now. It's not fast, and it breaks occasionally when patches change the bone structure, but it's the only reliable method I've found for creating detailed poses in Stellar Blade. The community thread on the Shift Up forums has some additional tips from other creators, but most of that advice is outdated after the 1.04 patch. My notes above reflect the current state of the toolchain as of early 2026.
