EmbodiedGen turns images and prompts into simulator ready assets and scenes

From intent to a world a policy can be trained in

The stated goal of EmbodiedGen V2 is narrow and specific: to compile language, images and edit commands into policy ready 3D worlds, with physically plausible assets, large-scale scenes and task-driven interactive environments that deploy across major simulators. The audience is embodied AI research, and the problem it addresses is the one that sits between a generative 3D model and a robot learning pipeline. A mesh is not enough. A policy needs a URDF, a collision proxy, a scale, a mass, a friction value, and a scene it can move through, all consistent with each other, and all in a format the simulator accepts. EmbodiedGen assembles that package, and the README describes the properties as VLM-inferred, meaning a vision-language model is the component that reads the asset and proposes its physical characteristics.

One standardized layout, six simulators

The export claim is the strongest part of the project. A standardized layout loads with consistent geometry, collision and physics across SAPIEN, Isaac Sim, Isaac Gym, MuJoCo, Genesis and PyBullet. That matters because simulator fragmentation is the other half of the problem. A dataset that only opens in one simulator is a dataset tied to that simulator's asset conventions, its coordinate conventions and its contact model, and porting it later is close to starting again. The trade in EmbodiedGen is that the asset has to be expressible in a common subset, which is exactly why the pipeline generates a convex collision proxy rather than a full collision mesh, and why scale, mass and friction are treated as outputs to be checked rather than as fields you fill in. Among the pinned packages, SAPIEN is a simulator in that list and is pinned to a beta version, and ManiSkill, the manipulation stack built on it, is pinned to a beta as well, a hint about where the simulation side of the collaboration sits.

The generative backend is pluggable, and that is where quality comes from

The project does not generate geometry itself. It orchestrates backends, and the README names three: SAM3D, TRELLIS and the Hunyuan3D Pro cloud API, switchable with a single flag. The image-to-3D and text-to-3D commands expose that choice through an image3d_model option, and the cloud backend is described separately as an API rather than a local model, which is a real constraint if your data cannot leave the machine. Everything that makes the output simulation ready, the URDF packaging, the convex collision proxy, the inferred physical properties, the quality check with automatic retries, sits around the backend rather than in it. That division is the honest way to think about this project. EmbodiedGen is the assembly line, and the backend decides the shape of the part. If you are evaluating it, the meaningful test is the same prompt through two backends, not the number of pipelines the tool ships.

Installing means a conda environment, a CUDA argument and a GPT agent

The quick start is explicit about the requirements, including the ones that are easy to skip:

git clone https://github.com/HorizonRobotics/EmbodiedGen.git
cd EmbodiedGen
git checkout v2.1.0
conda create -n embodiedgen python=3.10.13 -y
conda activate embodiedgen
# Manually install one CUDA toolkit when needed. cu126 remains the default.
# bash install.sh cu126 # RTX 40-series.
# bash install.sh cu128 # RTX 50-series / Blackwell.
conda deactivate && conda activate embodiedgen
bash install.sh basic # around 10 mins

Note the reinstall of the environment after the toolkit step, and the CUDA variant argument, which is chosen per GPU generation rather than per driver. Python 3.10.13 is the pinned interpreter. Then one GPT agent backend has to be configured, because most pipelines need it. For Azure OpenAI or OpenRouter you select the backend and put the API key in embodied_gen/utils/gpt_config.yaml. For the Codex CLI you run codex login and set agent_type: codex in the same file, with no project API key required. The setup guide at docs/documentation/gpt_agent.md covers the configuration, environment variables and deployment choices.

The command line is the real interface, not the demos

The project exposes its capabilities as a set of console entry points, declared in pyproject.toml:

[project.scripts]
img3d-cli = "embodied_gen.scripts.imageto3d:entrypoint"
text3d-cli = "embodied_gen.scripts.textto3d:text_to_3d"
texture-cli = "embodied_gen.scripts.gen_texture:entrypoint"
scene3d-cli = "embodied_gen.scripts.gen_scene3d:entrypoint"
layout-cli = "embodied_gen.scripts.gen_layout:entrypoint"
sim-cli = "embodied_gen.scripts.simulate_sapien:entrypoint"
room-cli = "embodied_gen.scripts.gen_room:entrypoint"
affordance-cli = "embodied_gen.scripts.affordance_annot.affordance_annot:entrypoint"

That naming tells you the pipeline stages: image to 3D, text to 3D, texture generation, scene generation, layout generation, a SAPIEN simulation step, room generation and affordance annotation. Two of the examples in the README are worth reading closely, because the arguments show the intended workflow. A text prompt goes straight to a 3D asset:

text3d-cli --prompts "small bronze figurine of a lion" --output_root outputs/textto3d

and an existing mesh can be re-textured with a natural language prompt:

texture-cli --mesh_path apps/assets/example_texture/meshes/horse.obj \
    --prompt "A gray horse head with flying mane and brown eyes" --output_root outputs/texture_gen

The output of the image-to-3D path is listed as URDF plus mesh in obj or glb form, plus a 3DGS point cloud in ply form, plus a video.

Gradio services cover the interactive cases

For exploratory work the project ships local Gradio applications, and each is launched as a Python script that opens on a local port:

python apps/image_to_3d.py    # http://localhost:8081
python apps/text_to_3d.py     # http://localhost:8082
python apps/texture_edit.py   # http://localhost:8083
python apps/visualize_asset.py  # http://localhost:8088

The models are downloaded automatically on first use, which is convenient and also means the first launch of each service needs the download bandwidth and the disk. The four services cover image to 3D, text to 3D, texture editing and asset visualisation. The distinction between the services and the command line entry points is worth making, because they are aimed at different users. The services are for a person iterating on a prompt or a mesh, while the command line tools are the batch interface you would put behind a job runner when you need a thousand assets rather than one that looks right.

V2 adds scenes, affordances and a conversational edit loop

The V2 section lists what is new, and three items change the scope. The first is 3D Vibe Coding, which builds and edits simulator ready scenes through natural language dialogue via Claude Code slash commands, where each edit is a bounded, physics-validated skill call rather than free-form generation. The second is large-scale scene generation, producing multi-room, navigable, instance-editable houses at controllable complexity tiers from minimalist to detail. The third is part-level affordance: functional part segmentation, per-part semantics, and simulation-validated 6-DoF grasp poses for any generated asset, which is the feature that connects asset generation to manipulation research. The closed-loop learning claim is stated in the README with numbers, and it cites a sim2real reinforcement learning paper for them: task success rising from 9.7 to 79.8 percent in simulation and from 21.7 to 75.0 percent on real robots. Those are the project's own reported figures from a specific paper, not independent measurements, and you would want to read that paper before repeating them.

Apache-2.0 code, pinned dependencies and a wide model surface

The licence is Apache-2.0, declared in pyproject.toml with the licence file listed, and the project version there is v2.1.0 with Python 3.10 or newer required. One packaging detail is unusual and worth knowing before you install: the dependencies array in pyproject.toml is empty, and the real dependency set lives in requirements.txt, pinned to specific versions, including torch 2.8.0, torchvision 0.23.0, xformers, diffusers 0.34.0, transformers 4.42.4, openai 1.58.1 and gradio 5.48.0. Two simulator packages are pinned to beta releases, sapien 3.0.0b1 and mani_skill 3.0.0b21, which tells you the simulation side of the stack is moving. The repository itself is organised with apps/, embodied_gen/, install/, docker/, docs/, scripts/, tests/ and thirdparty/ directories, with mkdocs.yml for the documentation site, pytest.ini for the tests, a .pre-commit-config.yaml, and ruff configured with a line length of 79 and the Google docstring convention. The release history is steady, with v2.0.0 on 2026-07-09, v2.0.1 on 2026-08-05 and v2.1.0 on 2026-08-19, and the last push was on 2026-08-24.

Editorial conclusion

Adopt EmbodiedGen if you need policy ready 3D assets and scenes faster than you can author them by hand, and if you already work in one of the six supported simulators, because the export path is the point of the project and it is where the time is saved. Do not adopt it if the physical fidelity of a single asset matters more than the throughput, since the geometry, collision proxy and material properties are inferred by a generative backend and a vision-language model rather than authored. Before you commit, run the same prompt through more than one of the SAM3D, TRELLIS and Hunyuan3D backends and compare the results yourself, check which CUDA variant your GPU needs since the install script takes it as an argument, and read the licence and the model weights terms separately from the code licence.

Frequently asked questions

Official sources

1. HorizonRobotics/EmbodiedGen on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases