Preparing UniMate on Debian: GPU Tests, Python Troubleshooting, and the Next Steps

Lab journal — September 12, 2026, Honolulu time*

I set out to explore UniMate, an AI research project for generating motion for 3D characters with different skeletal structures. My goal was to download its code, prepare a working environment on my Debian desktop, and find out how far I could get with the hardware and released files available during this session.

By the end, I had installed the dependencies, performed a successful calculation on my NVIDIA graphics card, loaded Blender’s Python module, and opened UniMate’s inference help menu. I also encountered two useful troubleshooting lessons: a package compatibility warning that did not prevent a basic import, and a Python path problem that made an installed package appear to be missing.

Animation generation remains a future step. The README in my downloaded copy described the pretrained checkpoints and processed dataset as forthcoming. I did not train a model, generate an animation, or verify that a complete model would fit into my graphics card’s memory.

What UniMate does

UniMate works with articulated motion: movement controlled by a framework of bones and joints inside a 3D character. The project describes generating motion from text for different skeletal structures, including animals and other creatures.

Its documented applications include generating motion, filling movement between selected keyframes, editing movement while preserving particular joints, and extending a sequence through multiple prompts.

The software I installed is a Python research workflow operated from a terminal. Installing it did not give me a conventional drawing application or a desktop animation editor. In this workflow, “inference” means using an already trained model to generate motion.

Checking the desktop’s graphics hardware

The first step was to identify the graphics card:

lspci | grep -Ei 'vga|3d|display'

The result identified an NVIDIA GeForce GT 1030. I then ran:

nvidia-smi

The driver responded successfully and showed the following:

Item	Observed result
Graphics card	NVIDIA GeForce GT 1030
Driver version	550.163.01
CUDA version displayed by the driver tool	12.4
Total graphics memory	2,048 MiB
Graphics memory in use at that moment	360 MiB

This established that the NVIDIA driver was running. It did not yet establish that PyTorch could execute GPU operations or that a full UniMate workload would fit into memory. Those are separate questions.

Downloading UniMate

I downloaded the source repository into a dedicated folder:

git clone https://github.com/Friedrich-M/UniMate.git "$HOME/UniMate"

The clone completed successfully, receiving approximately 32.92 MiB. On my desktop, the project folder is:

/home/lvydvy/UniMate

I then inspected its requirements:

cat "$HOME/UniMate/requirements.txt"

The file specified Python 3.10 and a CUDA 12.4 dependency setup. It included PyTorch, Torchvision, text-processing and model libraries, visualization packages, a motion library, and Blender’s Python module.

The requirements also explained a specific compatibility constraint: the Motion dependency uses a legacy build process that imports pkg_resources, so the setup calls for setuptools<81 and installation with --no-build-isolation.

Creating a separate Conda environment

I created an environment dedicated to the project:

conda create -n unimate python=3.10

After accepting the installation prompt, Conda completed the transaction. I activated it with:

conda activate unimate

The terminal prompt changed from (base) to (unimate).

Next, I installed the required setuptools version:

python -m pip install "setuptools<81"

The output showed setuptools 83.0.0 being replaced with 80.10.2. Then I installed the project dependencies:

python -m pip install -r "$HOME/UniMate/requirements.txt" --no-build-isolation

The installation completed and returned to the terminal prompt. Among the installed packages were PyTorch 2.5.1+cu124, Torchvision 0.20.1+cu124, NumPy 2.2.6, and the CUDA runtime dependencies.

These commands record what I ran during installation. Later in the session, I discovered that plain python could resolve to the wrong interpreter. For future work, I will use the explicit environment interpreter shown below.

Verifying actual GPU computation

I ran a small PyTorch test that checked CUDA availability, identified the card, and doubled three numbers on the GPU:

import torch

print("PyTorch:", torch.__version__)
print("CUDA available:", torch.cuda.is_available())

if torch.cuda.is_available():
    print("GPU:", torch.cuda.get_device_name(0))
    x = torch.tensor([1.0, 2.0, 3.0], device="cuda")
    print("GPU calculation:", (x * 2).cpu().tolist())

The output was:

PyTorch: 2.5.1+cu124
CUDA available: True
GPU: NVIDIA GeForce GT 1030
GPU calculation: [2.0, 4.0, 6.0]

This was a concrete success: PyTorch performed a calculation using the graphics card. It was a small functional test, not a performance benchmark or a memory test for UniMate’s complete model.

Investigating the Blender warning

The next check was:

python -m pip check

It reported:

bpy 4.0.0 is not supported on this platform

Before replacing packages, I tested whether Blender’s module could actually load:

python -c "import bpy; print('Blender version:', bpy.app.version_string)"

The result was:

Blender version: 4.0.0

The distinction matters. The import worked, but the warning was not resolved. I have not tested rendering, animated mesh export, or the EEVEE rendering stage. A successful import is useful evidence, but it does not certify every Blender function.

Finding out what animation generation requires

I read the inference section of the local README:

sed -n '/^##.*Inference/,$p' "$HOME/UniMate/README.md"

It explained that sampling starts from a training output directory containing a configuration file, dataset statistics, and model checkpoints. The corresponding processed dataset features must also be present because the target skeleton’s conditioning information comes from that dataset.

The downloaded README described pretrained checkpoints as coming soon and the processed UniML3D dataset as being prepared for release. That is the release status recorded in this session; it should be checked again before the next attempt.

Having the source and Python packages therefore did not yet give me all the inputs needed to generate an animation.

Solving the Python interpreter mismatch

After changing into the project folder, I tried:

cd "$HOME/UniMate"
python -m unimate.inference.sample --help

It failed with:

ModuleNotFoundError: No module named 'torch'

That was surprising because PyTorch had already passed the GPU test. Instead of reinstalling it, I checked the interpreter:

type -a python
python -c "import sys; print(sys.executable); print(sys.version)"
echo "$CONDA_PREFIX"

The results exposed the mismatch:

Check	Result
First Python in command search order	/home/lvydvy/anaconda3/bin/python
Environment Python also present	/home/lvydvy/anaconda3/envs/unimate/bin/python
Interpreter actually selected	Base Anaconda Python 3.14.6
Conda environment prefix	/home/lvydvy/anaconda3/envs/unimate

The terminal still displayed (unimate), but plain python selected the base interpreter. The underlying cause of that path ordering was not investigated or permanently corrected during this session.

The immediate workaround was to call the environment’s interpreter explicitly:

"$CONDA_PREFIX/bin/python" -m unimate.inference.sample --help

That worked. After Matplotlib built its font cache, UniMate displayed its inference options and returned to the prompt without a traceback.

The repeatable return procedure

I tested these three commands together successfully:

conda activate unimate
cd "$HOME/UniMate"
"$CONDA_PREFIX/bin/python" -m unimate.inference.sample --help

They activate the environment, enter the project folder, and use the correct interpreter to display the help menu. The --help option does not generate motion, load a complete trained model, or prove that inference will fit into graphics memory.

The live help also displayed hyphenated options such as --exp-dir, --test-cases-json, and --batch-size. When constructing a future command, I will follow the installed command’s help because some README examples use underscore spellings.

Current checkpoint

Component or task	Status at the end of the session
Source code	Downloaded successfully
Conda environment	Created and activated
Python dependencies	Installation completed
NVIDIA GPU calculation	Passed
Blender Python import	Passed
Blender platform warning	Still unresolved
UniMate inference help	Opens successfully with explicit environment Python
Plain python path ordering	Workaround established; permanent fix pending
Pretrained model and processed features	Still needed; described as forthcoming in the downloaded README
Full generation and rendering	Not tested
Full model fit on a 2 GB GPU	Unknown

Future moves

1. Preserve the working checkpoint

Before changing packages or updating the repository, record the installed environment and source revision. These are proposed next-session commands; they were not run during this session:

conda activate unimate
cd "$HOME/UniMate"
git rev-parse HEAD > unimate-source-commit.txt
conda env export -n unimate > unimate-environment.yml
"$CONDA_PREFIX/bin/python" -m pip freeze > unimate-installed-packages.txt

These records help identify the setup that produced the successful tests. They are useful records rather than a guarantee that every package will remain downloadable forever.

2. Recheck the official release materials

Check the project repository for pretrained checkpoints, their matching configuration and statistics, and the required processed skeleton features. Review new instructions before updating the working copy. A model download alone may not satisfy the dataset requirements described in this README.

3. Address the interpreter path separately

Inspect shell initialization and command-path behavior to understand why base Python took precedence. Continue using "$CONDA_PREFIX/bin/python" while the environment is active until that cause is identified. Avoid reinstalling packages merely because the wrong interpreter cannot see them.

4. Attempt one small inference job when the required assets are available

Start with a single supported test case, one repetition, a batch size of one, and motion-only output if supported by that release. This separates model generation from rendering and limits batch-related memory use. It does not guarantee that the model itself will fit into 2 GB.

If the run fails for lack of memory, use the actual error and the released model’s requirements to assess options. CPU execution should be treated as something to verify in the implementation, not an assumed supported fallback. Training a model from scratch is a separate project that has not been sized for this desktop.

5. Test rendering after motion generation works

Once a motion file is produced, test a short skeleton render and then mesh animation/export as separate steps. Revisit the bpy warning if a rendering or export failure points to that package.

Lessons learned

The most useful lesson was that the environment name in the terminal prompt and the interpreter selected by the shell can disagree. Checking sys.executable resolved the mystery of a package that had worked earlier appearing to be missing later.

The session also showed why setup checks should have precise meanings. Driver detection, a GPU calculation, a module import, a help menu, and a complete animation are different milestones. Passing the earlier checks is progress, but each later stage still needs its own evidence.

I finished with a prepared environment and a repeatable way to open UniMate’s command interface. The next meaningful milestone is running a documented example with the required trained model and processed data, then measuring what this modest graphics card can handle.

Project reference

UniMate source repository

This journal is based on terminal output and the downloaded README reviewed during the session. Release availability and dependency instructions may change after this checkpoint.