LHM++ and the case for reconstructing a human from images without a pose

What the model produces and how fast

LHM++ is an efficient large-scale human reconstruction model that generates high-quality, animatable 3D avatars within seconds from one or multiple pose-free images. The word pose-free is the interesting one, because it means the input does not have to be a person in a known pose, which is what separates this from a body-fitting pipeline that needs a skeleton estimate before it starts.

The model specifications table is unusually concrete. Four variants are listed, all at 700M, all with a feature dimension of 1024, 16 attention heads, 160,000 Gaussian Splatting points and an encoder dimension of 1024. The variants are LHMPP-700M-PixelShuffle, LHMPP-700M-SMPLX-FREE, LHMPP-700M and LHMPPS-700M, and the Views column is Any for all of them, meaning the model is not restricted to a fixed number of input images.

The timing columns are the headline. For a single view the inference time is 0.79 seconds, rising to 1.00 s at four views, 1.31 s at eight views and 2.13 s at sixteen views. The service requirement is 8 GB for three of the variants and 7.3 GB for LHMPPS-700M, so a single consumer card is enough.

The one output column that differs is the 3DGS output: the PixelShuffle and SMPLX-FREE variants have it checked, and the plain LHMPP-700M and LHMPPS-700M variants do not.

The project is Apache-2.0 licensed, the primary language is Python, and the paper is on arXiv at 2506.13766v2.

The architecture is the speed story

LHM++ achieves dramatic speedups over LHM-0.7B via an Encoder-Decoder Point-Image Transformer architecture, and the project guide is clear that this is the mechanism rather than a hardware trick.

The project description says the model is efficient, and the efficiency analysis section presents the comparison across different configurations as three separate figures, one a static chart, one a comparison image and one an animation.

The name of the architecture tells you the shape of the problem. An encoder-decoder arrangement with points and images as two modalities suggests the model works in a space where a point representation of the human and the input images are both first class, which is a different starting point from a pipeline that renders a depth map and then fits a body model to it.

The repository layout reflects the pieces of a research pipeline rather than a tidy library. There is app.py at the root, which is the Gradio application, a core/ directory, an engine/ directory, a benchmark/ directory, configs/, tools/, scripts/, lib/, torch_utils/ and dnnlib/, plus legacy.py for older entry points and convert.sh as a convenience script. A requirements.txt pins everything, and there is a separate INSTALL.md alongside INSTALL_CN.md.

The point for an adopter is that this is a research codebase with an inference path and a benchmark harness, not a packaged library with a stable API.

The install is a long, pinned sequence with compiled extensions

The environment setup is where most of the friction lives, and the project is upfront about the pins.

You clone and enter the directory:

git clone https://github.com/aigc3d/LHM-plusplus
cd LHM-plusplus

Then the stack is installed in a fixed order, starting with a specific PyTorch build:

# install torch 2.3.0 cuda 12.1
pip install torch==2.3.0 torchvision==0.18.0 torchaudio==2.3.0 --index-url https://download.pytorch.org/whl/cu121
pip install -U xformers==0.0.26.post1 --index-url https://download.pytorch.org/whl/cu121

Then the dependencies, with one optional package noted for a specific use:

# install dependencies
pip install -r requirements.txt
pip install rembg[cpu]  # only use during extracting sparse view inputs.

After that come the compiled extensions, several of which need a source build rather than a wheel. pointops is installed from the vendored lib/ directory, spconv comes from a cu121 wheel, and torch_scatter has a comment that you should pick the wheel matching your CUDA version, with a worked example for PyTorch 2.3, CUDA 12.1 and Python 3.10.

Then pytorch3d, installed without an index and pointed at a specific wheel directory for that same combination:

pip install --no-index --no-cache-dir pytorch3d -f https://dl.fbaipublicfiles.com/pytorch3d/packaging/wheels/py310_cu121_pyt230/download.html

And the Gaussian Splatting rasteriser, diff-gaussian-rasterization, which the guide offers as a direct install or as a recursive clone and local install. simple-knn is another one, and gsplat is noted as installable from a pre-compiled wheel.

The pattern is clear: this is a CUDA 12.1 and PyTorch 2.3 world, and several of the components are not on PyPI in a form that pip can resolve for you.

Gaussian Splatting export and the two rendering paths

The recent releases are about output formats, and this is the part of the project that has moved most.

The first new feature is exporting a gs.ply file, run through scripts/inference/to_gs_ply.py, which saves 3D Gaussian Splatting as a standard .ply file. It can be a canonical T-pose, by leaving the pose directory empty, or a single SMPL-X JSON frame by pointing at one. It is supported for LHMPP-700M-PixelShuffle, which is the default, and for LHMPP-700M-SMPLX-FREE, and the supported model names live in a named list in core/utils/model_card.py.

The second is gs_render output, which in app.py produces RGB output from Gaussian splatting only, with no neural refinement. You launch it with the --gs flag when the model is one of the two above, or switch the Output Renderer setting to gs_render in the user interface.

The PixelShuffle variant is described as the SMPLX-FREE variant with an MLPPixelShuffle neural renderer, a lighter dense head than DPT, and it supports 3DGS-PLY export along with the gs_render output. The hub weights for it are pending, so the guide says to use a local checkpoint with the --model_path argument until they are published.

There is also a newer LHMPP-700M build that supports standard 3D Gaussian Splatting PLY as an output format, and the earlier LHMPP-700M-SMPLX-FREE and LHMPP-700M-PixelShuffle are the two that carry the 3DGS output tick in the specifications table.

The practical reason to care about the PLY export is interoperability. A standard .ply file can be opened by any Gaussian Splatting viewer, so the output is not locked inside this project.

Benchmarks shipped, benchmarks still open

The TODO list at the end of the project summary is a good indicator of how finished the research side is, because the checkboxes are specific.

Done: the core inference pipeline, the release of the code and the pretrained weights, the HuggingFace demo integration, and the dynamic reconstruction benchmarks. The dynamic reconstruction work covers evaluation code and validation data for NeuMan, SelfCapture and Vid2Avatar.

Not done: benchmarks for novel view and pose synthesis, where THuman-2.1 and similar datasets are listed as a TODO, though a DNA-Rendering data download script with --download and --untar options is available and the evaluation metrics are still to come. Also open are the ModelScope space online demo, the release of the training and testing data once a licence is available, and the training codes release.

So the inference path is complete and reproducible, the dynamic reconstruction evaluation is there, and the training side is not published. That last point matters for anyone planning to fine-tune rather than run the released checkpoints.

The model cards also reference a HuggingFace Space under the name Lingteng, and the project offers a Chinese version of the documentation for people who prefer it.

Three licence files, and the one that is not Apache

The licence situation at the repository root is worth reading carefully, because there are three files and they say different things.

The main licence is Apache-2.0, which is also what the repository records as the licence identifier. But alongside it sit LICENSE_NVIDIA and LICENSE_WEIGHT, which is the project telling you that some components in the distribution are under different terms.

That is standard practice for a model release that builds on a specific body model and on trained weights, and the presence of the files is better than their absence, but it does mean the permissive licence on the code does not automatically extend to everything you download and run. Anyone shipping a product on top of this, or redistributing the weights, has to read which terms apply to which artefact.

The attribution line in the project summary lists the authors, with a large group of contributors from Tongyi Lab at Alibaba Group, SYSU, CUHK-SZ and Fudan University. The contact author links to a personal page, and the project also publishes a Chinese version of the documentation and a Chinese install guide, and a separate INSTALL.md and INSTALL_CN.md pair.

The overall shape of the release is a research artefact with pretrained weights, a demo space, a video walkthrough and full inference code, published under a permissive code licence with separate terms for parts of the model.

Editorial conclusion

LHM++ suits a graphics or research team that needs a rigged, animatable human avatar from a handful of photographs without hand-fitting a skeleton, since the model produces a 3D Gaussian Splatting avatar in about 0.79 seconds for a single view on an 8 GB card. It does not suit a team without an NVIDIA GPU and a CUDA 12.1 environment, since the install path pins PyTorch 2.3 and several compiled extensions, and it does not suit anyone who needs the training code or the training data, since both are still open items in the project list. Before you build on it, read the three licence files at the repository root, because the code is Apache-2.0 while the NVIDIA and weight licences impose separate terms.

Frequently asked questions

Official sources

1. aigc3d/LHM-plusplus on GitHub
2. Issues
3. License: Apache-2.0
4. README