HY-World 2.0: Tencent's Open-Source 3D World Model That Outputs Meshes, Not Videos

What HY-World 2.0 actually produces, and who needs that

Video world models generate frames. HY-World 2.0 generates geometry. The README draws the distinction itself: systems like Genie 3, Cosmos and HY-World 1.5 "generate pixel-level videos", while HY-World 2.0 "directly produces editable, persistent 3D assets (meshes / 3DGS) that can be imported into game engines like Blender/Unity/Unreal Engine/Isaac Sim". That single design decision determines the audience.

If your downstream step is a renderer, a physics engine, or a level editor, a video file is a dead end. You cannot collide with a pixel, relight it, or move a camera through it. A mesh or a Gaussian Splatting scene can be loaded, edited and re-rendered at a cost that does not grow with viewing time. The README's comparison table makes the claim explicit: rendering cost is "one-time generation; rendering cost ≈ 0", against per-frame inference for video models.

The project serves two groups. Reconstruction users have captured footage or multi-view photos and want a digital twin: WorldMirror 2.0 predicts depth, surface normals, camera parameters, point clouds and 3DGS attributes in a single forward pass. Generation users start from a text prompt or a single image and want a navigable scene. Both groups are technical: the requirements file pins torch==2.7.1, cupy==13.6.0 and pycolmap==3.10.0, which is not a stack you assemble by accident.

The honest framing is that this is research infrastructure with a product attached. The README links a hosted demo at 3d.hunyuan.tencent.com/sceneTo3D and notes an HY World 2.1 update in July 2026, so the open repository is one layer of a larger release, not the whole thing.

The four-stage generation pipeline and the single-pass reconstruction model

Generation and reconstruction are separate paths inside one framework, and the README is specific about how generation is decomposed.

World generation runs four stages: panorama generation with HY-Pano 2.0, trajectory planning with WorldNav, world expansion with WorldStereo 2.0, and world composition with WorldMirror 2.0 plus 3DGS learning. Read that sequence as a data flow. Text or a single image becomes a panoramic image. WorldNav decides where the camera should travel. WorldStereo 2.0 expands the panorama outward into surrounding views. WorldMirror 2.0 then reconciles the accumulated views into a consistent 3D representation, and 3DGS learning fits the final scene. Each stage is a model with its own weights, which is why the news section announces them in separate waves: WorldMirror 2.0 on April 16, 2026, HY-Pano 2.0 on May 11, 2026, and World Generation inference code plus WorldStereo 2.0 weights on May 18, 2026.

Reconstruction skips all of that. WorldMirror 2.0 is described as "a unified feed-forward model that simultaneously predicts depth, surface normals, camera parameters, 3D point clouds, and 3DGS attributes in a single forward pass". The README states it supports flexible-resolution inference between 50K and 500K pixels. One pass, five outputs. That is the more conventional and more predictable of the two paths, because you supply the views rather than asking a model to invent them.

The architecture has a consequence worth naming: generation quality is bounded by the weakest stage. A panorama that misplaces a wall will propagate through expansion and composition, and no amount of 3DGS fitting repairs a geometric contradiction. The README presents the pipeline as a strength. It is equally a chain of failure modes.

Installing HY-World 2.0 from the repository

The README does not contain installation commands, a quickstart, or a list of entry points. It points to the model weights on Hugging Face (huggingface.co/tencent/HY-World-2.0) and ModelScope (modelscope.cn/models/Tencent-Hunyuan/HY-World-2.0), and the repository ships requirements.txt, requirements_git.txt, hyworld2/, examples/worldgen/ and examples/worldrecon/. What follows is assembled from those files, not from a documented procedure, so treat it as a starting point rather than a supported path.

Create an isolated environment and install the pinned dependencies. The versions matter: torch is pinned to 2.7.1 and numpy to 1.26.4, and mixing them with a system CUDA toolkit is the most likely source of immediate breakage.

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

The repository also carries requirements_git.txt, which by its name holds dependencies installed directly from git rather than from an index. Install it after the main file, since it is the layer most likely to pull in packages that are not on PyPI.

pip install -r requirements_git.txt

For a first real use, look at the two example directories rather than guessing at an entry point. examples/worldgen/ corresponds to the generation path (text or image to 3D world) and examples/worldrecon/ to the reconstruction path (multi-view images or video to 3D). Open the files in the one matching your input before running anything, because the README does not document the arguments either example expects. If neither directory contains a runnable script, that is your answer about the project's current state.

Where HY-World 2.0 breaks down or is the wrong tool

The dependency list is the first real constraint. cupy==13.6.0 ties you to a specific CUDA major version. pycolmap==3.10.0 and open3d==0.18.0 are compiled packages with their own build requirements. pymeshlab==2023.12.post2 and the nanobind, pybind11 and scikit-build-core entries in the same file suggest at least one component builds from source. On a machine without a matching CUDA toolkit, the install fails before you reach any model code, and the README offers no troubleshooting section.

The second constraint is the absence of a documented interface. There is no CLI reference, no Python API listing, no list of environment variables, and no stated hardware requirement beyond the implicit need for a CUDA GPU. The four-stage generation pipeline means four sets of weights to download and place correctly. If the repository's example scripts do not encode the expected layout, you are reverse-engineering it from the code in hyworld2/.

The third is scope. Reconstruction expects multi-view images or a casual video of a real scene. If you have a single photograph and want a walkable environment, that is the generation path, and generation invents geometry that was never observed. For applications where the 3D asset must correspond to a real place, that distinction is the whole decision.

Finally, the licence. The repository entry is License.txt and the GitHub metadata reports NOASSERTION. The README does not summarise the terms. If your use is commercial, that file is the first thing to read, not the last.

How it differs from video world models and from photogrammetry

The comparison the README makes is against video world models: Genie 3, Cosmos, and the project's own predecessor HY-World 1.5 (WorldPlay plus WorldCompass). The difference is not quality, it is output type. A video world model produces frames that exist only during playback. HY-World 2.0 produces an asset that persists and can be imported into Blender, Unity, Unreal Engine or Isaac Sim. If your goal is a demo clip, a video model is simpler and probably sufficient. If your goal is something a user can walk around in for an hour, the video approach accumulates inference cost with every interaction while a 3D asset does not.

The comparison against classic photogrammetry is less flattering and more useful. Tools in that family reconstruct geometry from images through optimisation. WorldMirror 2.0 is a feed-forward model: it predicts depth, normals, camera parameters, point clouds and 3DGS attributes in one pass. Feed-forward inference is faster and works from sparser input, but it is a learned prior. Where a photogrammetry pipeline fails it usually fails visibly, with holes or a drifted camera solve. A learned model can produce a plausible surface that is confidently wrong, and you will only notice when the scene is loaded into an engine and the walls do not meet.

The four-stage generation pipeline has no direct equivalent in either camp. Choosing a camera trajectory, expanding a panorama, and then composing the results is a generative approach to scene construction. It is what makes text-to-world possible at all, and it is also why the output should be inspected geometrically before it is trusted.

Maintenance, upgrade cost, and the licence question

The last push to the repository was on 2026-08-12, roughly a month before this writing, and the repository is not archived. The news entries show a steady release cadence through 2026: the technical report and partial code on April 16, WorldMirror 2.0 weights the same day, HY-Pano 2.0 on May 11, World Generation inference code and WorldStereo 2.0 weights on May 18, and an HY World 2.1 product update in July. That is a project still being extended rather than a frozen snapshot.

Upgrade cost is the part to weigh. Because the pipeline is four models, an upgrade can touch any one of them, and the pinned versions in requirements.txt mean that moving torch or numpy forward is a deliberate act. The framework also depends on external repositories through .gitmodules and requirements_git.txt, so a clean install depends on code outside this tree. Budget for a container or a pinned environment rather than a shared Python installation.

On licensing, the repository ships License.txt and GitHub reports the licence as NOASSERTION, which means the platform could not classify it automatically. The README does not restate the terms, and the model weights are hosted separately on Hugging Face and ModelScope, where they may carry their own conditions. I am not giving legal advice here, only pointing at the files: read License.txt, and check the model card on whichever host you download from, before you build anything on top of the output.

Editorial conclusion

Adopt HY-World 2.0 if you need editable 3D output (meshes, point clouds, 3DGS) for a game engine or simulation pipeline and you have a CUDA GPU plus the patience for a multi-model stack whose dependencies are pinned to exact versions. Do not adopt it if you want a single pip install, a hosted API, or a documented end-to-end script: the README describes the architecture but shows no install commands, no entry point, and no command-line flags. Before committing, verify three things in the repository itself: that hyworld2/ contains runnable inference entry points for both examples/worldgen/ and examples/worldrecon/, that the model weights on Hugging Face or ModelScope match the code revision you clone, and that the License.txt terms are acceptable for your use, since the repository is marked NOASSERTION and the README does not restate the licence.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Tencent-Hunyuan/HY-World-2.0 on GitHub