Running AniGen on an Apple Silicon Mac to Create a Rigged 3D Model from One Image

Running AniGen on an Apple Silicon Mac: Creating a Rigged 3D Model from One Image

Hello, everyone.

Turning a single illustration into an animatable 3D character would be useful. The difficult part is that we need more than the visible shape: we also need a skeleton and a definition of how each part follows each bone.

Today, I tested the Apple Silicon port of AniGen on an M1 Max Mac to see whether it could generate rigged 3D models from two images.

The short result is that a simple mascot image succeeded, while a character illustration with thin limbs and clothing failed. One of the two inputs completed under the fixed conditions.

What I tested

AniGen generates three parts together from one image:

• mesh: the surface geometry of the 3D model
• skeleton: the bones used to move the model
• skinning weights: values that define how strongly each vertex follows each bone

I used AniGen-mac and tested the following on MPS, the PyTorch interface to Apple's GPU stack:

• whether it could produce mesh.glb, skeleton.glb, and a background-removed image
• whether the GLB contained a mesh, skin, joints, JOINTS_0, and WEIGHTS_0
• how the result changed between a simple mascot and a more complex character illustration
• where the failed case stopped in the pipeline

Lab: kiarina/labs/2026/07/11/anigen-mac

Reproducing the test

You need an Apple Silicon Mac, macOS 26 or later, full Xcode 26 or later, mise, uv, Node.js, Google Chrome, and FFmpeg. Allow about 24 GB for the source, Python environment, pretrained weights, and other first-run files.

git clone --depth 1 --filter=blob:none --sparse \
  https://github.com/kiarina/labs.git
cd labs
git sparse-checkout set .gitignore .mise/tasks Makefile mise.toml 2026/07/11/anigen-mac
mise -C 2026/07/11/anigen-mac run

The first run builds the dependencies and Metal extensions, then downloads pretrained weights from Hugging Face. Completed results are reused. Set ANIGEN_FORCE=1 to rerun inference.

Models and licenses

I used these fixed settings:

• AniGen-mac commit: 4ff0baa
• weights: VAST-AI/AniGen
• SS Flow: ss_flow_duet
• SLat Flow: slat_flow_auto
• seed: 42
• simplify ratio: 0.95
• texture size: 1024
• bake mode: fast

The Hugging Face model repository is labeled MIT, and AniGen's own source code uses the MIT License.

That does not mean every bundled dependency is uniformly covered by MIT. The project's THIRD_PARTY_LICENSES.md lists FlexiCubes under Apache-2.0 and part of the CUDA CUBVH component as restricted to non-commercial or research use. This Mac inference path uses Metal components such as mtlbvh instead of CUBVH, and the AniGen README says CUBVH is required for training but not inference. Before using or distributing the result, check the current terms of every component in your actual path and consider how they apply to your intended use.

How AniGen works

The pipeline can be reduced to three steps:

1. Remove the background and extract features from the input image.
2. Build a coarse 3D structure with Sparse Structure, then generate detailed geometry, skeleton, and skinning in Structured Latent space.
3. Use FlexiCubes to extract a triangle surface from the internal scalar field and export it as GLB.

You can think of Sparse Structure as a rough 3D blueprint and Structured Latent as the detailed internal representation. FlexiCubes converts that representation into a triangle mesh that a 3D viewer can display.

AniGen's main idea is to represent Shape, Skeleton, and Skin together as S³ Fields over the same space, instead of generating a shape first and rigging it with an unrelated model afterward. The goal is to produce geometry and articulation that agree with each other.

Results

I ran the test on a MacBook Pro with an Apple M1 Max and 64 GB of memory.

Input	Result	Time	Geometry at extraction	Final output
miineko1	success	751 s	358,370 vertices / 716,820 faces	9,854 vertices / 14,427 triangles / 10 joints
miineko2	failed	879 s	1,866,415 vertices / 0 faces	none

Successful mascot image

Both mesh.glb and skeleton.glb loaded as GLB 2.0. The rigged mesh contained one mesh, one skin, ten joints, and the JOINTS_0 and WEIGHTS_0 attributes required for skinning. It did not contain an animation clip.

The front shape and colors broadly followed the input. The unseen back was simpler than the front. I also prepared a turntable video to inspect the result from all sides. It rotates the camera around a static pose; it is not a skeletal animation.

Failed character illustration

Sampling completed, but FlexiCubes produced vertices followed by zero triangle faces. The later decimation step therefore stopped with Input mesh for decimation must be all triangles, and no GLB was produced. The zero-face result also occurred in another run with the same seed.

I recorded values before and after FlexiCubes to check whether the internal field lacked any surface at all.

scalar values:           16,974,593
finite values:           16,974,592
negative values:            821,173
positive values:         16,153,420
surface cubes:            1,470,942
surface edge references:  7,657,618
output vertices:           1,866,415
output faces:                      0

The field contained both positive and negative values, and about 1.47 million candidate surface cubes were detected. The evidence therefore does not suggest that there was no surface signal. All faces disappeared later, while resolving candidates into triangles.

Interpreting the failure

The confirmed facts are that the failed case processed about 16.78 million cubes, found surface candidates, generated vertices, and still ended with zero faces. Some runs also recorded an MPS command-buffer error.

My working hypothesis is that the large indexing path in FlexiCubes did not complete correctly on MPS, causing case resolution or triangulation to break. The unmodified AniGen-mac commit raised out-of-range errors when indexing with large boolean masks. The lab applies a small patch that converts those masks to explicit valid indices. That patch allowed the first image to complete, but did not fix the second image's zero-face result.

The second input has thinner limbs, hair, clothing, and a bent leg. This complexity may have contributed to the much larger intermediate data, but two images are not enough to identify the input itself as the cause.

Test environment

machine: MacBook Pro (Apple M1 Max, 64 GB)
OS: macOS 26.5.1, arm64
Xcode: 26.6
Metal compiler: 32023.883
Python: 3.10.18
PyTorch: 2.12.0 (MPS available)
NumPy: 1.26.4
Pillow: 12.3.0

The checkpoints alone occupied about 20 GB, so the first-run setup is substantial. I did not test external motion, deformation quality while moving the bones, other model variants, or parameter sweeps.

Final thoughts

Generating not only geometry but also a skeleton and skinning data in a valid GLB on a Mac was an interesting result. The successful output opened directly in a 3D viewer and looks useful for prototyping.

However, one success out of two inputs is not stable enough to treat this as a dependable image-to-asset tool. A failure after more than ten minutes and a roughly 24 GB initial setup are also significant costs. Next, I would test whether resizing or cropping the input, or switching Flow variants, reduces the intermediate data and improves the completion rate.