Editorial scope
Pixal3D, Pixel3D, or Pixel 3D: which spelling is right?
The repository, paper, and model card spell the project Pixal3D (with an a). Pixel3D and Pixel 3D are the same project written the way most people type it, and both spellings appear in search queries alongside the correct one. There is no second model called Pixel3D in this comparison: when a page or a video says “Pixel3D vs Trellis 2” it is comparing the Pixal3D implementation against TRELLIS.2, which is exactly what this article does. The ordering is also interchangeable — “Pixal3D vs Trellis 2” and “Trellis 2 vs Pixel 3D” ask the same question.
One caveat matters for both spellings: Pixal3D's main branch and its paper branch are different implementations. Pin the branch and commit before you compare anything, or your “Pixel3D” result will not match someone else's.
Decision summary
| Question | Pixal3D | TRELLIS.2 |
|---|---|---|
| Primary research emphasis | Pixel-aligned conditioning and input-view fidelity | General high-resolution image-to-3D generation |
| Current implementation relationship | Main branch uses the TRELLIS.2 backbone | Upstream standalone 4B pipeline |
| Official example output | GLB mesh from one image | PBR-ready GLB plus preview video |
| Hardware claim we can verify | A low-VRAM mode exists; no fixed minimum is promised in README | Official code requires at least 24 GB VRAM and cites A100/H100 |
| Code license | MIT | MIT |
The practical implication is that a result difference cannot be attributed to two wholly unrelated model families. Pin the exact Pixal3D branch and commit before testing: its main branch and paper branch represent different implementations.
What we actually verified
On August 28, 2026, the TripoSplat editorial pass checked the projects' primary repositories and the Pixal3D paper record. This is an original source-verification audit, not an inference-speed benchmark. The table below records each check so a reader can reproduce it.
| Check | Observed evidence | Primary source |
|---|---|---|
| Pixal3D implementation | README says main uses TRELLIS.2; paper results live on a separate branch | TencentARC/Pixal3D README |
| Pixal3D conditioning | Paper describes back-projecting image features into a 3D volume | arXiv:2605.10922 |
| Pixal3D output contract | Official inference command writes a GLB file | TencentARC/Pixal3D README |
| TRELLIS.2 scale and representation | 4B model, 512³–1536³ resolution, O-Voxel representation | microsoft/TRELLIS.2 README |
| TRELLIS.2 local requirements | Linux, NVIDIA GPU with at least 24 GB VRAM, tested on A100/H100 | microsoft/TRELLIS.2 README |
| Licensing | Both repositories expose MIT licenses; dependencies may differ | Repository license files |
Primary links: Pixal3D repository, Pixal3D paper, and TRELLIS.2 repository.
Evidence boundary
Architecture difference that matters
Pixal3D: explicit pixel-to-3D correspondence
Pixal3D's research contribution is the conditioning path. Multi-scale image features are back-projected into a 3D feature volume, giving the generator an explicit relationship between input pixels and 3D space. The paper frames this as a way to improve fidelity to the source view and describes extensions to multi-view and scene generation.
TRELLIS.2: a general O-Voxel generation system
TRELLIS.2 uses a 4B flow-transformer pipeline and O-Voxel structured latents. Its official documentation emphasizes complex topology, high-resolution assets, and surface attributes such as base color, roughness, metallic, and opacity. The example pipeline exports a PBR-ready GLB.
Why branch pinning changes the comparison
The Pixal3D repository says its current main branch is an improved implementation based on TRELLIS.2, while the paper branch corresponds to the published SIGGRAPH results and uses a different base. Record the branch and commit SHA next to every output; otherwise a future rerun may not be the same experiment.
A reproducible side-by-side test protocol
Pin source versions
Record repository URL, branch, commit SHA, checkpoint, dependency lock, and license file.
Use the same input set
Include a hard-surface product, an organic object, a thin structure, transparency, and a difficult rear-view case.
Hold hardware and measurement constant
Use one GPU, cold and warm runs, synchronized timing, peak allocated VRAM, and the same output resolution target.
Preserve raw outputs
Keep the source image, command, logs, GLB, preview renders, and a checksum so readers can audit the result.
Score visible and hidden surfaces separately
Rate source-view fidelity, novel-view plausibility, topology, material channels, and cleanup time as distinct measures.
Publish failures as well as winners
Show out-of-memory runs, malformed geometry, texture failures, and rerun variance instead of selecting only good samples.
Short recommendation