WorldGen: two lines of API over a dependency list that only resolves on one Linux wheel

Two lines of code, and what they stand on

The promise is a complete 3D scene from a prompt in seconds, and the usage example is genuinely two lines: construct the object, then ask for a world. The scenes are explorable in any direction with loop closure, work indoors and out, and render at any resolution with any camera setting along any trajectory, which is the part that matters if you are feeding them into a simulation rather than looking at a render. What sits underneath is where the effort went. Three dependencies are not ordinary packages. One is a direct link to a prebuilt wheel on a release page, built for a specific torch version, a specific Python version, Linux and x86_64. One is the viewer library pulled from the author's own fork, modified to show double-sided texture meshes. One is a utility library pinned to a single commit rather than a version. Read those three lines as the real specification of the project.

The manifest declares a version twice

The packaging metadata contains a contradiction that will surface the first time anyone builds a wheel. The project table sets the version to 0.1.0 as a literal. Further down, a dynamic metadata section tells the build backend to read the version from the package's own attribute instead. Both cannot be in force, and which one wins depends on the backend and its version, which means the artefact you build locally and the artefact on the index are not guaranteed to agree. The rest of the manifest is plain: a standard build backend, a source layout where the package lives under the src directory, a Python floor of 3.11, and a classifier set that says operating system independent, which given the wheel dependency below is worth taking with a pinch of salt.

Recursive clone, then three installs that skip resolution

The install section starts with a recursive clone, which is the first hint that submodules carry code rather than documentation. Then a conda environment on Python 3.11, then torch and its vision library installed on their own before anything else, then the package itself. The last two installs both come from git and both deliberately skip dependency resolution, with a comment saying the depth estimation library needs that to avoid version conflicts. That is a pragmatic choice and it has a predictable cost: if a transitive dependency is missing or wrong, nothing catches it at install time and you find out at import. The last line of that block is cut off mid-flag in the visible file, so the exact option being passed to the third-party 3D library is not readable here.

The documented panorama example calls a private method

There is a note about generating from a 360 degree panorama, which is the format the pipeline is built around internally. You supply an equirectangular image with a two-to-one aspect ratio, and the example that follows is a call to a method whose name is marked private, taking the panorama as its only argument. Everything else in the file uses the public entry point, so this one example teaches you to reach past the interface. That is a fair thing for a note to do if you are describing an internal capability, and a poor thing if you copy it into your own code, since a private marker in a name is a promise that it may change without notice. If you need panorama input, treat the public method's image argument as the supported path and check whether it accepts equirectangular input.

Low memory mode is a boolean with a threshold in a comment

The constructor takes a device and a low-memory flag, and the comments on both examples tell you the same thing: set the flag to true if your card has less than 24 gigabytes of memory. The changelog dates the feature to October 2025 and puts a number on it, roughly ten gigabytes of memory for generation. So the flag is not a quality toggle with a vague cost, it moves the requirement from a single high-memory card down to something a workstation card can do. What the file does not say is how much quality you lose, or whether the low-memory path is the one behind the mesh output added a few months later, so if you are choosing hardware for a specific job, that is the question to put to the author rather than assume from the flag name.

Both output formats are written as .ply files

The default return value is a Gaussian splat, saved as a point cloud file that any standard splatting viewer can open, and the documented call is short enough to copy whole:

worldgen = WorldGen(mode="t2s", device=device, low_vram=False) # Set low_vram to True if your GPU VRAM is less than 24GB.
splat = worldgen.generate_world("<TEXT PROMPT to describe the scene>")
splat.save("path/to/your/output.ply")

Passing a return flag switches to a mesh instead, written through a 3D library rather than the splat writer, and the changelog is unusually direct about the preference, saying mesh should give better results than splats. Two details are worth knowing before you pick. Both outputs use the same file extension, so the format is not obvious from a directory listing and you will need to track it yourself. And the mesh path is the one described as better, yet the default is the splat, which suggests the splat path is the one that was optimised for. The mesh addition is dated April 2025, four months before the code was released.

Sharp went from eight views to six, and became optional

The changelog is where the engineering is. The most recent entries describe reworking the sharper reconstruction so that depth from the cubemap aligns the per-face point clouds for better global consistency, and reducing the input from more than eight views to the six cubemap faces. The day before, the depth estimator was replaced wholesale, moving from one project to another for better 360 degree depth. In March the project scale bug that was hurting output quality was fixed and the sharp path's dependency was made optional, so the default mode no longer needs it. Before that, the sharp path was added as experimental in the first place and is still described as experimental, with a demo flag to reach it and a claim that it may beat the default. Two items remain unchecked: a technical report with a video, and better background inpainting.

A demo server on one port, and a citation dated 2025

The quick start is a single script with a handful of flags, and it launches a local viewer server on one fixed port where you explore the generated scene in real time. The flag set covers text prompt, image input, the experimental sharp mode and mesh output, and two of those example lines are cut off mid-sentence in the visible file, one of them a comment about installing something first. The viewer library is a fork, which is what lets it render the double-sided mesh textures. Finally, the citation block gives the year 2025 and the repository as the publisher, which is right for the release date but reads oddly against a last commit in April 2026 and a changelog with four months of entries after it. Minor, and the kind of thing a user copying the citation will propagate without noticing.

Editorial conclusion

This is a research release with the honesty of one: the changelog records a scale bug, a dependency made optional, an experimental path with a flag, and two items still unchecked. Two things decide whether you can run it at all. One dependency is a direct link to a prebuilt wheel for a specific torch build, a specific Python version, Linux and x86_64, so a Mac, a Windows machine, or a different torch will fail at install rather than degrade. And a second dependency is the viewer's own fork, so this package installs its own version of a library other code on your machine may also expect. Read the install section as written, in order, and check the wheel URL before you plan hardware around it. Apache 2.0, version 0.1.0 in the manifest, last commit 2026-04-12.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. ZiYang-xie/WorldGen on GitHub