Skip to main content
NexGPU

3D Generation

Run Magic3D's coarse-to-fine pipeline end to end on a GPU you rent by the second

NVIDIA never released Magic3D's code or weights. What ships is the threestudio reproduction: roughly 6GB VRAM for the coarse stage, 5GB for refine — and batch size, not the floor, is what actually eats memory.

Sign up freeView pricing

Magic3D is NVIDIA's text-to-3D method from CVPR 2023 (arXiv:2211.10440, by Chen-Hsuan Lin, Jun Gao, Karsten Kreis, Sanja Fidler, Ming-Yu Liu, Tsung-Yi Lin and colleagues). It targets DreamFusion's two weak points: supervision resolution is too low and optimisation is too slow. The fix is two stages. Stage one gets a coarse model from a 64×64 low-resolution diffusion prior accelerated by an Instant-NGP style sparse hash grid. Stage two converts that into a deformable tetrahedral grid (DMTet), attaches the nvdiffrast differentiable rasteriser, and optimises a textured triangle mesh directly against a 512×512 latent diffusion model. The paper reports 8× higher-resolution supervision than DreamFusion, 15 minutes coarse plus 25 minutes fine on 8 A100s for 40 minutes total against DreamFusion's roughly 1.5 hours, and 61.7% of raters preferring Magic3D's output.

The critical thing to be clear about: there is no official Magic3D implementation and no downloadable weights. The paper's coarse stage uses eDiff-I, NVIDIA's internal base diffusion model, which was never published either. Every runnable Magic3D you will find online is a community reproduction, and the one treated as the de facto standard is threestudio (threestudio-project/threestudio, Apache-2.0). It swaps eDiff-I for open T2I models and ships three configs: magic3d-coarse-if.yaml guided by DeepFloyd/IF-I-XL-v1.0 at guidance_scale 20, 64×64 rendering, implicit-volume geometry, hash grid with n_levels 16 and log2_hashmap_size 19, 10000 steps; magic3d-coarse-sd.yaml as the lower-VRAM Stable Diffusion route; and magic3d-refine-sd.yaml on stabilityai/stable-diffusion-2-1-base at guidance_scale 100, 512×512 rendering, tetrahedra-sdf-grid geometry, isosurface_resolution 128, 5000 steps. A second option is ashawkey/stable-dreamfusion, whose --dmtet stage is essentially Magic3D's refine idea.

The published VRAM numbers look low — about 6GB for coarse-sd, 5GB for refine-sd, 15GB embedding extraction plus 10GB training for coarse-if — but those correspond to the default small batch. threestudio's own README demos use batch size 8; the paper used 32. And batch size is precisely where 3D consistency and convergence speed come from in SDS-style methods. So the realistic rental logic is not "6GB is enough" but "push batch size up to whatever VRAM you have." That is also why per-second billing fits Magic3D so well: this is not a resident inference service, it is a one-prompt, tens-of-minutes-to-hours optimisation job. Export the obj and the machine should stop.

01 —

Which Magic3D Can You Actually Run

The original paper is not reproducible as published. These are the executable paths, with VRAM figures taken from each project's own documentation.

VersionParametersVRAMContextNotes
Magic3D, original paper (NVIDIA, CVPR 2023)eDiff-I base model + latent diffusion, batch size 328× A100 80GB; no single-GPU figure published64×64 coarse / 512×512 fine, 5000 steps eachCode and weights never released, and eDiff-I itself is not public, so a faithful reproduction is impossible. Read it as a method baseline.
threestudio configs/magic3d-coarse-if.yamlDeepFloyd/IF-I-XL-v1.0 guidance, guidance_scale 20~15GB for embedding extraction + ~10GB training (default batch)64×64 rendering, max_steps 10000Highest-quality coarse route. IF weights are gated: accept the licence on the Hugging Face model card and run huggingface-cli login first.
threestudio configs/magic3d-coarse-sd.yamlStable Diffusion guidance~6GB (default batch)64×64 rendering, implicit-volume + hash gridThe low-VRAM coarse route. Use it to validate the pipeline, prompt and camera settings, then switch to IF for final runs.
threestudio configs/magic3d-refine-sd.yamlstabilityai/stable-diffusion-2-1-base, guidance_scale 100~5GB (default batch)512×512 rendering, isosurface_resolution 128, max_steps 5000The DMTet refine stage that produces a textured triangle mesh. Must be chained to the coarse last.ckpt via system.geometry_convert_from.
ashawkey/stable-dreamfusion --dmtetInstant-NGP backbone + DMTet refinement~16GB (Instant-NGP backbone)--iters 5000, needs the 256-resolution tetrahedral grid downloaded separatelyApache-2.0. The author points readers to threestudio in the README, so treat this as a lighter fallback rather than the primary choice.
Feed-forward successors (for comparison)TRELLIS text-xlarge 2.0B / Hunyuan3D 2.1 DiT 3.0B + Paint 1.3BTRELLIS needs ≥16GB; Hunyuan3D 6GB shape, 16GB shape + textureSingle forward pass, seconds to minutesNo per-prompt optimisation. Go here for asset production; stay on Magic3D for controllable distillation research.

02 —

Which GPU to Rent for Magic3D

Size by batch, not by the published minimum — batch is where 3D consistency comes from.

  • Get the pipeline working: coarse-sd plus refine-sd at default batch, validate prompt and export chain

    RTX 3090 24GB$0.193/GPU-hr

    The documented 6GB plus 5GB fits inside 24GB with enormous headroom, making this the cheapest way to run the full two-stage flow once.

  • Production runs: coarse-if with 15GB embedding extraction plus 10GB training, batch pushed to 8

    RTX 4090 24GB$0.540/GPU-hr

    DeepFloyd IF-I-XL text embedding extraction alone peaks at 15GB, so 24GB is what lets you raise batch size afterwards without a reload.

  • Chase paper quality: batch size 16 to 32 with 512×512 refine at full resolution

    RTX A6000 48GB$0.817/GPU-hr

    48GB holds IF guidance activations at large batch while leaving room for the DMTet tetrahedral grid and nvdiffrast buffers.

  • Asset batches: dozens of prompts optimised in parallel on one node

    A100 SXM4 80GB$1.088/GPU-hr

    80GB runs several trials concurrently per card, and NVLink nodes go up to 14 GPUs — a direct match for the paper's 8-GPU setup.

03 —

Four Steps From Boot to Exported OBJ

Launch a PyTorch prebuilt image; everything else happens in one SSH session.

  1. 01

    Boot and clear the two build traps

    In the NexGPU console pick a PyTorch prebuilt image on a 24GB-or-larger card, SSH in, and clone threestudio. Building tiny-cuda-nn sometimes requires downgrading pip to 23.0.1, and installing ninja first cuts CUDA compile time substantially. The refine stage depends on nvdiffrast, which on a headless machine must use the EGL backend; a bare container missing the driver libraries either fails compiling nvdiffrast_plugin_gl.so or crashes at eglInitialize(). Prebuilt images already carry that stack — from bare Ubuntu you would add libegl1 and libgl1 yourself.

    git clone https://github.com/threestudio-project/threestudio && cd threestudio && pip install ninja && pip install -r requirements.txt
  2. 02

    Run the coarse stage, clearing DeepFloyd IF's gate first

    IF-I-XL-v1.0 is gated: accept the licence on its Hugging Face model page, then run huggingface-cli login with your token on the machine or the weight pull returns a flat 401. The config defaults to 10000 steps at 64×64 rendering. If you have VRAM to spare, raise data.batch_size above the default — that is the first quality tip in threestudio's own README. To just check the pipeline runs, swap in magic3d-coarse-sd.yaml, which starts at about 6GB.

    python launch.py --config configs/magic3d-coarse-if.yaml --train --gpu 0 system.prompt_processor.prompt="a delicious hamburger" data.batch_size=8
  3. 03

    Convert to DMTet and tune the isosurface threshold

    The refine stage points system.geometry_convert_from at last.ckpt inside the coarse trial directory, switches geometry from implicit-volume to tetrahedra-sdf-grid, raises rendering to 512×512 and runs 5000 steps. When the coarse density field is sparse or littered with floaters the mesh comes out hollow or shows white edges at the boundary; override it with system.geometry_convert_override.isosurface_threshold — the documented example value is 10., higher tightens, lower loosens.

    python launch.py --config configs/magic3d-refine-sd.yaml --train --gpu 0 system.prompt_processor.prompt="a delicious hamburger" system.geometry_convert_from=outputs/magic3d-coarse-if/a_delicious_hamburger@LAST/ckpts/last.ckpt system.geometry_convert_override.isosurface_threshold=10.
  4. 04

    Export the mesh, pull the files, stop the box

    The mesh exporter writes obj plus mtl by default, ready to drag into Blender or Unity. Pull it over scp or download it from Jupyter, then stop the instance in the console — compute billing stops with the instance, while storage keeps billing until the volume is destroyed, so delete intermediate volumes once you have confirmed the output.

    python launch.py --config outputs/magic3d-refine-sd/a_delicious_hamburger@LAST/configs/parsed.yaml --export --gpu 0 resume=outputs/magic3d-refine-sd/a_delicious_hamburger@LAST/ckpts/last.ckpt system.exporter_type=mesh-exporter

What One Asset Actually Costs

Start with the paper's own configuration. Magic3D's 40 minutes were measured on 8 A100s. NexGPU's A100 SXM4 80GB is $1.088/GPU-hr, so 8 cards is $8.704/hr; 40 minutes is 0.667 hours, and $8.704 × 0.667 ≈ $5.81 per asset at paper speed. Now the budget route: a single RTX 3090 24GB at $0.193/GPU-hr running coarse-sd plus refine-sd, estimated at a full 4 hours per round (real wall-clock depends on batch size and step count), gives $0.193 × 4 = $0.772 per prompt. Twenty prompts on the same setup is $0.193 × 4 × 20 = $15.44 — cheaper than twenty single-asset calls on most commercial 3D generation APIs. The middle path, IF coarse on an RTX 4090 24GB, is $0.540 × 4 = $2.16 per round. Storage is separate: a trial directory with checkpoints and per-step validation videos runs about 5GB, so $0.414/GB-month × 5 ≈ $2.07/month, and destroying the volume after exporting the obj ends that. No minimum rental, no setup fee, no quota request — Ctrl-C a bad coarse model, change the seed, start over, and pay only for the seconds you ran.

04 —

FAQ

Is Magic3D open source? Where do I download the official weights?

It is not, and there are none. NVIDIA published the paper and a project page but never released code, and the eDiff-I base diffusion model behind the coarse stage is not public either, so a faithful reproduction is technically off the table. The de facto standard is threestudio's reproduction (Apache-2.0), which substitutes DeepFloyd IF or Stable Diffusion for eDiff-I, drops guidance scale from 100 to 20, uses analytic normals instead of predicted ones, and adds DreamFusion's orientation loss. Installing it means compiling tiny-cuda-nn and nvdiffrast, which typically costs an evening locally — on NexGPU a PyTorch prebuilt image arrives with drivers, CUDA and the EGL stack already configured, and an RTX 3090 at $0.193/GPU-hr is enough to run the whole chain through once.

How much VRAM does Magic3D need? Is a 6GB card really enough?

threestudio documents roughly 6GB for magic3d-coarse-sd, 5GB for magic3d-refine-sd, and 15GB embedding extraction plus 10GB training for magic3d-coarse-if. But those are default-small-batch numbers, while the README's demo results use batch size 8 and the paper used 32 — and batch size is exactly where 3D consistency comes from in SDS-style methods, with memory scaling roughly linearly. The practical guidance: 24GB to validate, 24 to 32GB for production runs, 48GB to chase paper quality. NexGPU stocks every tier — RTX 3090 24GB $0.193, RTX 4090 24GB $0.540, RTX 5090 32GB $0.723, RTX A6000 48GB $0.817 — billed per second, so moving up a tier just means relaunching.

What is the actual difference between Magic3D and DreamFusion?

Supervision resolution and output format. DreamFusion optimises a NeRF at low resolution throughout. Magic3D splits it: the coarse stage is still a 64×64 NeRF, but refine converts the density field into a deformable tetrahedral grid (DMTet), attaches nvdiffrast differentiable rasterisation, and optimises triangle mesh and texture directly against a 512×512 latent diffusion model. The result is 8× higher supervision resolution, 40 minutes on 8 A100s versus roughly 1.5 hours, 61.7% rater preference, and a real obj instead of a NeRF you can only volume-render. The two-stage split also means you can screen prompts on a cheap card and switch to a big one for refine — which is exactly what NexGPU's per-second billing is built for.

Is Magic3D still worth using, or should I go straight to TRELLIS or Hunyuan3D?

Depends what you want. For asset production the feed-forward generation has clearly won: Microsoft TRELLIS (MIT licence, image-large 1.2B / text-xlarge 2.0B, needs ≥16GB VRAM) and Tencent Hunyuan3D 2.1 (3.0B DiT plus 1.3B Paint, 6GB for shape and 16GB for shape with texture) both produce results in a single forward pass, seconds to minutes. NVIDIA productised its own line as Edify 3D, which delivers quad-topology meshes with organised UVs, 4K textures and PBR materials in about two minutes — but as an API, with no open weights. What per-prompt optimisation methods like Magic3D still offer is research value: any T2I model can serve as guidance, every loss term and camera policy is under your control, and it makes a clean baseline for SDS variants and 3D distillation experiments. NexGPU runs all of them — 24GB and up for Magic3D, an RTX 4090 24GB at $0.540/GPU-hr for TRELLIS or the Hunyuan3D texture pipeline — so you can benchmark them side by side without changing platforms.

Why does the refine stage fail to build nvdiffrast_plugin_gl.so or crash on eglInitialize()?

These are the two most common errors in any Magic3D reproduction and they share a root cause. DMTet refinement needs nvdiffrast for differentiable rasterisation, and a headless server has no X display, so it must use the EGL backend — but a bare container typically lacks libegl1, libgl1 and the matching NVIDIA EGL driver ICD file, so it either fails compiling nvdiffrast_plugin_gl.so on first run or compiles fine and then dies at eglInitialize(). The fix is installing the EGL runtime and confirming NVIDIA's json exists under /usr/share/glvnd/egl_vendor.d — or simply using an image that already has it. NexGPU's 2,000+ prebuilt images include PyTorch and ComfyUI variants shipping the complete EGL graphics stack, so that entire debugging round disappears.

My generated model has two faces (the Janus problem). Can it be fixed?

Mitigated, not cured. threestudio's remedies, roughly by cost-effectiveness: enable the Perp-Neg algorithm with system.prompt_processor.use_perp_neg=true, which targets multi-face artifacts specifically; change the seed with seed=N, which sometimes just resolves it; enable prompt debiasing via system.prompt_processor.use_prompt_debiasing=true or score debiasing via system.guidance.grad_clip=[0,0.5,2.0,10000]; and most fundamentally, raise batch size, because simultaneous multi-view constraints are the real source of 3D consistency. So the price of beating Janus is VRAM and re-runs — on NexGPU that means either an RTX A6000 48GB at $0.817/GPU-hr with batch size maxed out, or several RTX 3090s at $0.193/GPU-hr running different seeds in parallel and picking the winner. Billed per second, the trial-and-error costs about as much as a few coffees.

More in 3D generation

Every model guide

Start building on NexGPU

Enterprise R&D team or solo developer — either way, your first job can be running in minutes.

Sign up freeTalk to sales

Sign up to browse live network pricing. No payment method required.