aitviewer: an interactive viewer for sequences of 3D human data
A set of tools to visualize and interact with sequences of 3D data.
At a glance
- What is it?
- aitviewer is a MIT licensed Python toolkit for viewing and rendering sequences of 3D data, with built-in support for the SMPL family of parametric body models, a Dear ImGui interface and a ModernGL rendering pipeline. It suits computer vision researchers who need to inspect motion capture and parametric human sequences, and it is a heavy install with a pinned Python range and a manual PyTorch step.
- Who is it for?
- aitviewer fits a computer vision researcher who needs to open SMPL, MANO, FLAME or STAR sequences, edit poses and render videos without building a graphics application, because the loaders, camera models and GUI are already there. It does not fit a lightweight script that only needs to save a mesh frame, since the install pulls PyQt6, torch, usd-core and an OpenGL stack, and it does not fit a Python 3.13 environment because the package requires a version below 3.13.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 169 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A viewer for sequences, not for single frames
aitviewer describes itself as a set of tools to visualize and interact with sequences of 3D data, with cross platform support on Windows, Linux and macOS. The word sequences does most of the work here, because the alternative to this library is usually a general mesh viewer that opens one file at a time.
Motion capture and parametric human data arrives as a time series of poses, shapes and root transforms, often with a skeleton, a mesh, camera parameters and a background image. Scrubbing through that in a general purpose viewer means converting formats by hand, and rendering a frame that aligns with the camera in the dataset means writing that conversion yourself.
The feature list is aimed squarely at that workflow. It loads SMPL, SMPL-H and SMPL-X sequences as well as MANO, FLAME, STAR and SUPR, displays them in an interactive viewer, renders 3D data on top of images through weak-perspective or OpenCV camera models, supports animatable camera paths, and allows SMPL sequences and poses to be edited manually. There are prebuilt renderable primitives such as cylinders, spheres and point clouds for building a scene around the data.
The intended user is a researcher or engineer in computer vision or graphics, and the projects list in the README is a good indicator of who that is in practice, with entries from CVPR, ICCV and 3DV work on hands and objects, avatars, electromagnetic motion capture datasets and human performance capture.
Parametric body models need their own files and their own terms
The body models are not included. The quickstart in the README explicitly says that displaying an SMPL-X T-pose requires SMPL models to be installed, and the installation section points to a documentation page on supported models and installing SMPL body models for more advanced setups.
That is worth pausing on, because it is a licensing point as much as a setup point. SMPL, MANO and FLAME are distributed by their own research groups, each with its own access and licence conditions, and the repository links to those project pages rather than mirroring the models. aitviewer loads the models once you have them; it does not grant rights to them.
The model surface is broad enough that the loader layer is not trivial. The examples directory shows dedicated scripts for a good part of it, including quickstart_smpl.py, quickstart_mano.py and quickstart_flame.py for the three main families, load_AMASS.py and load_VIBE.py for common motion datasets, load_3DPW.py for a captured 3D people dataset, load_BVH.py, load_obj.py, load_point_clouds.py and load_GLAMR.py. load_SUPR.py and load_STAR.py cover the other two body models named in the feature list.
The examples are also the best documentation in the repository. They are short, they are named after the thing they load, and they show the import path for each type.
Installing pulls a GUI stack and leaves PyTorch to you
The basic install is a single command:
uv pip install aitvieweror the same without uv if you do not use it. Two things follow from that command that are easy to miss.
The first is that the GPU version of PyTorch is not installed automatically. The README says that if your environment already contains it you should be good to go, and otherwise you should install it manually. That is a deliberate separation, since the CUDA build depends on your driver and your hardware, and it also means a fresh install will not give you the accelerated path.
The second is the Qt binding. This installs PyQt6, and if you need PyQt5 you install the extra:
uv pip install aitviewer[pyqt5]For working on the code itself, the README documents a source install:
git clone [email protected]:eth-ait/aitviewer.git
cd aitviewer
pip install -e .The dependency list in the packaging metadata explains the size of the install: torch, numpy, opencv-contrib-python-headless, smplx, moderngl-window, moderngl, imgui, trimesh, scipy, omegaconf, joblib, scikit-image, Pillow, websockets, usd-core and PyQt6.
Headless rendering and remote mode for servers
Not every use of a 3D viewer has a screen attached. Two features cover that case, and they are the ones that separate aitviewer from a desktop mesh viewer.
Headless mode is for server rendering of videos and images, and there is a matching example script, examples/headless_rendering.py. The point is that you can produce rendered output on a machine with no display, which is what a training pipeline or a batch job needs.
Remote mode is for non-blocking integration of visualization code. The dependency list includes websockets, and the examples make the shape of it clear: remote.py, remote_amass.py, remote_custom_viewer.py and remote_two_way_communication.py. The idea is that the visualization runs somewhere else, typically a machine with a GPU, while the code driving it stays on the machine where the data lives, and the two talk over a socket instead of sharing a process.
The two-way example is the interesting one, because a one-way channel is only for pushing data to a viewer, while a two-way channel lets the driving code react to what happens in the scene.
Related examples cover the rest of the workflow: camera_path.py for animatable camera paths, animation.py for playback, missing_frames.py for sequences with gaps, gaussian_splatting.py, and load_template.py for a template mesh.
The rendering pipeline is ModernGL with an ImGui interface
Rendering is handled by a ModernGL based pipeline, and the README makes a performance claim about it, running at 100fps or more on most laptops. That figure is the project's own claim rather than an independent measurement, so treat it as an indication of the pipeline's design rather than a guarantee for your hardware.
The graphics stack is specific. moderngl-window is pinned to 3.1.1 and moderngl to 5.12.0 in the packaging metadata, and imgui is pinned to 2.0.0 for the interface, which the feature list describes as a built-in extensible GUI based on Dear ImGui. Pinning those versions tells you the library is tested against a particular combination of the OpenGL context handling and the immediate mode GUI, and that you should expect to match it rather than upgrade one of them in isolation.
The interface choice is deliberate and it has consequences. Dear ImGui is drawn by the application rather than being native widgets of the operating system, so the viewer looks the same on Windows, Linux and macOS, and extending the interface means writing ImGui panels rather than Qt dialogs. For a research tool that is usually the right trade, since the same code renders identically for every user and for a screenshot in a paper.
Export is part of the feature set too, with screenshots, videos and turntable views, the last two as mp4 or gif.
A heavy dependency tree and a Python ceiling
aitviewer is not a light dependency, and that is the main thing to weigh before adding it to an environment.
The install brings in torch, PyQt6, usd-core, scikit-image, trimesh and an OpenGL stack together. usd-core in particular is a large dependency to carry for a viewer, and it is not optional in the metadata. The project also pins Python: the package requires a version of 3.10 or later and below 3.13, which means a 3.13 environment is not supported and a 3.9 environment is not supported either.
The rendering requirements compound it. The pipeline needs a working OpenGL context, which on a headless server means an offscreen context or a machine with a GPU and a display, and the README's own performance claim is about laptops, so the target is a machine with a graphics stack rather than a bare container.
Two smaller oddities are worth knowing. The tool's own formatting dependencies, black and isort, are listed among the runtime dependencies rather than the development ones, and the pytest configuration filters deprecation warnings from chumpy, skvideo and smplx, which are the libraries behind some of the model loaders.
So the honest framing is that aitviewer is a research environment package, not a library you drop into a production service next to a web framework.
A general mesh viewer or a hand-written OpenGL scene instead
The alternative to aitviewer is usually one of two things, and the difference in approach is worth spelling out.
The first is a general purpose mesh or point cloud viewer. It opens files, renders them and lets you look. What it does not do is know anything about body models, camera conventions or sequence formats, so the work of loading an SMPL sequence, aligning it to a dataset camera with a weak-perspective or OpenCV model, and exporting a video becomes your code. aitviewer takes that work as given and provides it.
The second is writing your own OpenGL or offscreen renderer. The difference is where the effort goes. In that case you control the pipeline end to end, you can make the rendering exactly match what a paper needs, and you avoid the GUI stack entirely, but you also own the camera maths, the mesh handling and the export code.
The deciding question is usually whether your data is parametric human motion or ordinary geometry. If it is SMPL, MANO or FLAME sequences, or a dataset with a camera model attached, aitviewer removes a large amount of conversion code. If it is plain meshes and you already have a renderer, the install is not worth it.
MIT licensed, released regularly, and quiet since May
The licence is MIT, and the repository carries the usual MIT LICENSE file. The package metadata also names the three authors, Manuel Kaufmann, Velko Vechev and Dario Mylonopoulos, and the README gives contact addresses for the first two and says the software was developed by all three.
Releases are frequent. The list shows v1.14.2 on 2026-05-07, v1.14.1 on 2026-05-05 and v1.14.0 on 2026-05-05, with the version stored dynamically in the package metadata from the aitviewer module attribute rather than hardcoded in pyproject.toml. The repository was last pushed on 2026-05-07, so nothing has landed on main since that release, and it is not archived.
The project asks to be cited, and gives a citation block with a Zenodo DOI of 10.5281/zenodo.10013305, plus a CITATION.cff file at the root for tooling that reads it. A badge in the README points at the same DOI, and the code style badge names black, which matches the black configuration in pyproject.toml with a line length of 120 and a py310 target.
Contributions are welcomed, specifically module and feature contributions, and the tests are run through a GitHub Actions workflow with pytest configured to collect from the tests directory.
Editorial conclusion
aitviewer fits a computer vision researcher who needs to open SMPL, MANO, FLAME or STAR sequences, edit poses and render videos without building a graphics application, because the loaders, camera models and GUI are already there. It does not fit a lightweight script that only needs to save a mesh frame, since the install pulls PyQt6, torch, usd-core and an OpenGL stack, and it does not fit a Python 3.13 environment because the package requires a version below 3.13. Before you adopt it, install the body model files the documentation describes, confirm your GPU setup has the PyTorch build you need, and check the examples/load_AMASS.py and examples/load_VIBE.py loaders against the exact dataset format you work with.
Frequently asked questions
How do I install aitviewer?
Run `uv pip install aitviewer`, dropping uv if you do not use it. For PyQt5 instead of PyQt6 use `uv pip install aitviewer[pyqt5]`, and to work on the code itself clone the repository and run `pip install -e .`.
Does aitviewer install PyTorch with GPU support?
No. The README states that the GPU version of PyTorch is not installed automatically, so you either already have it in your environment or you install it yourself.
Do I need the SMPL body models to use aitviewer?
Yes for the parametric body models. The quickstart says displaying an SMPL-X T-pose requires the SMPL models to be installed, and the README points to the documentation page on installing SMPL body models for advanced setups.
Can aitviewer render on a server without a display?
Yes, through headless mode, which the README lists as support for server rendering of videos and images, with a matching example in examples/headless_rendering.py. The remote mode feature covers non-blocking integration over a socket.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/eth-ait-aitviewer)Was this useful?