# DrawingSpinUp: a three-stage pipeline that animates one character drawing

> DrawingSpinUp is the official PyTorch implementation of a SIGGRAPH Asia 2024 paper that turns a single character drawing into an animated 3D character. The pipeline runs contour removal, textured character reconstruction and a two-stage style translator, and it demands a pinned CUDA toolchain and checkpoints hosted outside GitHub.

**LordLiang/DrawingSpinUp** — (SIGGRAPH Asia 2024) This is the official PyTorch implementation of SIGGRAPH Asia 2024 paper: DrawingSpinUp: 3D Animation from Single Character Drawings

- Repository: https://github.com/LordLiang/DrawingSpinUp
- Website: https://lordliang.github.io/DrawingSpinUp/
- Stars: 658 · Forks: 67
- Language: Python
- License: not declared
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/lordliang-drawingspinup

## One drawing in, an animated character out

The repository is the official PyTorch implementation of the SIGGRAPH Asia 2024 paper DrawingSpinUp: 3D Animation from Single Character Drawings. The project page is hosted at lordliang.github.io/DrawingSpinUp, the paper is on arXiv, and the topics tag it as 3d-animation, non-photorealistic-rendering and style-transfer.

The scope is narrower than the name suggests, and the README is precise about it. You begin with a character drawing, described as a 512x512 texture.png with a foreground mask.png. From that single image the pipeline reconstructs a 3D character, then transfers the drawing's style onto an animation, and the result is a moving character that keeps the look of the original sketch. The style transfer is the point: this is about animating a drawing rather than animating a rigged character that already exists.

That makes the audience two groups. The first is the research audience reproducing a published method, which is what the script naming and per-stage training flags are written for. The second is an artist or animator with a drawing and a rig who wants the stylised result and is willing to run three training stages to get it.

The repository layout matches the pipeline. The top level is three numbered directories, 1_lama_contour_remover/, 2_charactor_reconstructor/ and 3_style_translator/, plus dataset/, docs/, pdf/ and requirements.txt. Each stage is a self-contained program that reads from and writes to the dataset directory, which is why the README spends so much of its length on directory trees.

## Three stages, one dataset directory, one uid

The plumbing is simple and worth understanding before anything runs. Every character is identified by a uid, which the README describes as a name you give your drawing after resizing it to 512x512 and obtaining its mask. The uid is what every script takes as its argument, and it has to be registered in two files: drawings_uids.json and, if you need the thinning operation, drawings_uids_thinning.json.

The data layout is fixed. Under dataset/AnimatedDrawings/preprocessed/ sits one directory per uid, and inside it the char/ subdirectory holds the inputs and outputs of the drawing stage, while the mesh/ subdirectory holds the reconstructed geometry and the animation files.

Stage one is contour removal. The README says FFC-ResNet is used as the backbone to predict the contour region of a given character drawing, and the stage directory is named 1_lama_contour_remover after the LaMa repository it is borrowed from. Its output is ffc_resnet_inpainted.png alongside mask.png and texture.png.

Stage two is character reconstruction, in 2_charactor_reconstructor/. It generates multi-view images with mv.py and fuses them into a textured character with recon.py, and it needs a separate pretrained isnet model for background removal of the generated multi-view images, downloaded as isnet_dis.onnx into a dis_pretrained directory.

Stage three is the style translator, 3_style_translator/, which is where training and inference happen.

Everything is keyed on the uid, so a mistake in a json file or a missing directory surfaces as a script that cannot find its input rather than as a subtle rendering error.

## A pinned CUDA stack and a diffusers warning

The install section is the part to read twice. The hardware note says all experiments were run on a single RTX 4090 GPU, with a single RTX 2080 Ti also acceptable. The environment is stated as Python 3.8.20, PyTorch 2.0.0, Cuda Toolkit 11.8 and Ubuntu 22.04.

The environment is created with conda, and PyTorch is installed from the cu118 wheel index:

```sh
conda create -n drawingspinup python=3.8
conda activate drawingspinup
pip install torch==2.0.0+cu118 torchvision==0.15.1+cu118 torchaudio==2.0.1+cu118 --extra-index-url https://download.pytorch.org/whl/cu118
```

The requirements file is installed next, with an explicit warning attached to it:

```sh
pip install -r requirements.txt # only tested on diffusers[torch]==0.19.3, may have conflicts with newer versions of diffusers!!!
# tiny-cuda-nn
pip install git+https://github.com/NVlabs/tiny-cuda-nn/#subdirectory=bindings/torch
```

That comment is the single most useful line in the install instructions. diffusers[torch]==0.19.3 is pinned in requirements.txt, and the author is telling you not to upgrade it, because the conflict will surface later in the training stages rather than at install time.

The rest of requirements.txt pins the rest of the stack: opencv-python, tqdm, pyyaml, omegaconf, kornia, einops, onnxruntime, triton, transformers, xformers, trimesh, pytorch_lightning, nerfacc, scipy, pymcubes, open3d, libigl, scikit-image, scikit-learn and pandas. The presence of triton, xformers and nerfacc alongside tiny-cuda-nn tells you the rendering path depends on custom CUDA kernels rather than only on PyTorch operators.

## Blender for rendering and checkpoints on a file share

Frame rendering is done by Blender, and the repository downloads its own copy. The clone step fetches the project, then pulls Blender 3.6.14 for Linux and extracts it:

```sh
git clone https://github.com/LordLiang/DrawingSpinUp.git
cd DrawingSpinUp
# download blender for frame rendering
wget https://download.blender.org/release/Blender3.6/blender-3.6.14-linux-x64.tar.xz
tar -xvf blender-3.6.14-linux-x64.tar.xz
```

Blender ships its own Python, so trimesh has to be installed into that interpreter rather than into your conda environment:

```sh
# install trimesh for blender's python
wget https://bootstrap.pypa.io/get-pip.py
./blender-3.6.14-linux-x64/3.6/python/bin/python3.10 get-pip.py
./blender-3.6.14-linux-x64/3.6/python/bin/python3.10 -m pip install trimesh
```

Two dependencies sit outside pip entirely. tiny-cuda-nn is installed from its GitHub repository, and python-mesh-raycast is cloned and built with python setup.py develop.

The weights are the last piece and the least convenient. The README asks you to download 120 processed character drawings and reconstructed 3D characters from a preprocessed.zip link on pan.baidu.com, and it points at a tiny subset of the Amateur Drawings Dataset maintained by facebookresearch as the source. The contour removal models come from a separate experiments.zip on the same file share host.

This is the practical fragility of the project. Two required checkpoints sit behind a Chinese file sharing service with a password in the URL, and the isnet model comes from a Hugging Face URL. If those links are unreachable from your network or have expired, the pipeline stops before the first script runs. Everything else in the install is a standard package install; these are not.

## Two training stages and a renderer with two engines

The toy example is the best way to see the shape of the work. The README offers an example uid, ff7ab74a67a443e3bda61e69577f4e80, with two retargeted animation files, and the scripts for it run in order inside the 3_style_translator directory:

```sh
cd 3_style_translator
# render keyframe pair for training
python run_render.py --uid ff7ab74a67a443e3bda61e69577f4e80
# stage1 training
python train_stage1.py --uid ff7ab74a67a443e3bda61e69577f4e80
# stage2 training
python train_stage2.py --uid ff7ab74a67a443e3bda61e69577f4e80
# render frames for inference
python run_render.py --uid ff7ab74a67a443e3bda61e69577f4e80 --test
```

and then inference and output:

```sh
# inference
python test_stage1.py --uid ff7ab74a67a443e3bda61e69577f4e80
python test_stage2.py --uid ff7ab74a67a443e3bda61e69577f4e80
# generate GIF animation
python gif_writer.py --uid ff7ab74a67a443e3bda61e69577f4e80
cd ..
```

The renderer is configurable. The README says the default rendering engine is BLENDER_EEVEE, which is faster, and that it can be switched to CYCLES by passing the engine type to the same script.

The animation data itself comes from Mixamo. The rest_pose.fbx in the mesh directory is the rigged character generated by Mixamo, and dab.fbx and jumping.fbx are two retargeted animation files. So the pipeline does not create the rig or the motion: you supply a rigged character and retargeted clips, and the method contributes the stylised rendering that makes the rig look like the drawing.

That division of labour is the key thing to understand before you commit hours of GPU time to it.

## Research code with research caveats

A few properties of the repository deserve to be stated plainly, because they bear on whether you should build on this code.

The licence is reported as unknown, and there is no licence file in the top-level entries. For a research implementation that is a common state, and it means there is no stated permission for commercial reuse. Anyone shipping a product built on this pipeline has to resolve that with the author.

There are no GitHub releases, so there is no versioned distribution to install and nothing to pin. The repository is not archived and the last push was on 2026-09-25, so the code does move, but the state you read is not a released state.

The training cost is unstated. The README says the experiments were run on a single RTX 4090 and that stage one and stage two are separate trainings, but it gives no training time, no iteration counts and no memory requirement, so you cannot budget the compute before starting. It also documents neither a training resume path nor a way to reuse a stage one model across characters.

The alternative is to work from the underlying dataset instead of the pipeline. The 120 characters are described as a tiny subset of the Amateur Drawings Dataset from facebookresearch/AnimatedDrawings, and the reconstruction work borrows render codes from Wonder3D. If your goal is a dataset of annotated character drawings rather than a stylised animation, the dataset gives you the drawings without the reconstruction, the retargeting requirement and the pinned CUDA stack. If your goal is the animated result, this pipeline is the implementation to use, with the checkpoint availability as the risk to check first.

## Conclusion

DrawingSpinUp fits a research group reproducing non-photorealistic character animation on a single modern GPU, or an artist who wants to drive its three stages with their own drawing and rig. It is the wrong choice for a production pipeline, since the environment is pinned to Python 3.8, PyTorch 2.0.0 and CUDA 11.8, the diffusers version is known to conflict with newer releases, the checkpoints live on a Baidu share link and the repository carries no licence, so there is no stated permission for commercial reuse. Before starting, check that the pretrained models are reachable from your network, that your Blender download matches the 3.6.14 build the scripts expect, and that the RTX 4090 class hardware the authors used is what you have.

## FAQ

### What hardware and software does DrawingSpinUp need?

The README states the experiments were run on a single RTX 4090 GPU, with an RTX 2080 Ti also acceptable, and the environment is Python 3.8.20, PyTorch 2.0.0, Cuda Toolkit 11.8 and Ubuntu 22.04. Blender 3.6.14 is downloaded for frame rendering.

### What are the three stages of the DrawingSpinUp pipeline?

They are 1_lama_contour_remover, which uses FFC-ResNet to predict the contour region of the drawing, 2_charactor_reconstructor, which generates multi-view images and fuses them into a textured character, and 3_style_translator, which trains stage one and stage two and renders the final animation.

### Where do I get the pretrained models and the processed characters?

The README points to a preprocessed.zip link on pan.baidu.com holding 120 processed character drawings and reconstructed 3D characters, and to a separate experiments.zip on the same host for the pretrained contour removal models. The isnet model for background removal is downloaded from a Hugging Face URL.

### Can I run DrawingSpinUp with my own drawing?

Yes. Prepare a 512x512 character drawing as texture.png with its foreground mask.png, give it a uid, and register that uid in drawings_uids.json and, if you need thinning, drawings_uids_thinning.json under dataset/AnimatedDrawings.

## Sources

- [Issues](https://github.com/LordLiang/DrawingSpinUp/issues)
- [LordLiang/DrawingSpinUp on GitHub](https://github.com/LordLiang/DrawingSpinUp)
- [Project website](https://lordliang.github.io/DrawingSpinUp/)
- [README](https://github.com/LordLiang/DrawingSpinUp/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lordliang-drawingspinup