Advertisement

TRELLIS.2 vs. 3D Gaussian Splatting: Two Different 3D Contracts

2026-09-05

TRELLIS.2 and 3D Gaussian Splatting (3DGS) both produce something that can be viewed from more than one angle, but they solve different problems.

TRELLIS.2 asks: given one image of an object, what complete, portable 3D asset is plausible?

3DGS asks: given many overlapping images of a stable scene, what visual representation best explains those observed views?

Calling one better without naming the input and deliverable is misleading. The first is a learned image-to-asset generator. The second is a multi-view scene-reconstruction pipeline.

TRELLIS.2: infer an asset beyond the visible pixels

TRELLIS.2 is a 4B-parameter image-to-3D model. Its official implementation describes a field-free sparse voxel representation called O-Voxel, a sparse 3D VAE, and staged sparse-structure, shape, and material generation. It can export a PBR GLB with base color, roughness, metallic, and opacity attributes. The representation is designed to preserve open surfaces, non-manifold geometry, and internal structures. The official TRELLIS.2 repository is the primary source.

The important word is infer. A single image cannot show the back of a footballer, the underside of a chair, or the occluded part of a house. TRELLIS.2 fills that absence with a learned 3D prior. Its 360-degree turntable is a renderer orbiting the generated asset, not evidence that the source image contained 360-degree coverage.

3DGS: fit a scene to multi-view evidence

3DGS begins with Structure-from-Motion: overlapping photographs provide camera poses and sparse points. The optimizer then learns a cloud of anisotropic 3D Gaussians whose positions, covariances, opacity, and appearance reproduce the captured views under differentiable splatting. The original work combines Gaussian optimization with adaptive density control and a visibility-aware renderer. The original 3DGS project explains the representation and renderer.

This makes 3DGS strong at locally faithful free-viewpoint rendering of a static, well-captured scene. It also means that poor overlap, motion, reflections, or textureless surfaces can prevent the reconstruction from forming at all. COLMAP's capture guide explains the image conditions required before Gaussian optimization begins.

The two output contracts

QuestionTRELLIS.23D Gaussian Splatting
Minimum useful inputOne foreground object image, preferably alpha-maskedMany overlapping images or sampled video frames of one static scene
Where 3D information comes fromA learned generative prior plus visible image cuesMulti-view geometry, camera poses, and image fitting
Native representationSparse structured latent, exported as a PBR GLBThousands to millions of anisotropic Gaussians, usually a PLY or splat
Main output contractCandidate static asset for downstream review or editingRealistic novel-view rendering of the captured scene
Unseen regionsInferred rather than observedWeakly constrained when the capture lacks views
Not a substitute forSurvey-grade reconstruction, rigging, or temporal continuityClean topology, UV authoring, collision, rigging, or single-image asset generation

A TRELLIS.2 GLB and a 3DGS PLY are therefore not interchangeable. A GLB can enter a DCC or game-asset review, but its topology, material, scale, and rigging still need inspection. A Gaussian PLY can look excellent from novel views yet has no implicit game-ready mesh contract.

What our local experiments showed

The local TRELLIS.2 path took a single footballer reference and produced a PBR GLB with one mesh, 343,320 vertices, 497,550 faces, and a four-second turntable preview. A matching power-shot reference produced a second static GLB. That is useful for art reference, but it is not continuous animation: the two poses have no shared skeleton, vertex correspondence, or temporal constraint. Both remain reference geometry until an independent DCC review establishes a downstream asset contract.

The local 3DGS chair path used 48 aspect-preserved frames. COLMAP registered all 48 and recovered 12,525 sparse points. A 250-step smoke run preceded a 7,000-step run, which produced 532,612 Gaussians with run-specific validation values of PSNR 25.718, SSIM 0.921, and LPIPS 0.098. The result preserved the chair and surrounding room context as one static scene rather than separate mesh assets.

Those outputs are demonstrations, not a quality leaderboard. The TRELLIS.2 input was one generated reference image with a mesh-asset objective. The 3DGS input was multi-view camera evidence with a scene-rendering objective. Comparing their scores would be meaningless.

Choose the tool by the contract

Use TRELLIS.2 when the input is a single art-directed image and the useful output is a candidate static object asset. Treat hidden-side geometry and final topology as review items.

Use 3DGS when the subject is genuinely static and its appearance across nearby viewpoints matters more than mesh editability. Supply real multi-view capture, qualify it with COLMAP, and deliver a splat plus rendered views.

Use neither as a shortcut for a continuous character action. A sequence of TRELLIS.2 poses is a collection of static models. A conventional 3DGS run assumes the subject did not move during capture. Dynamic Gaussian methods and motion capture require a separate time-aware design.

Next research plan

  1. Capture a stronger static-scene baseline. Use a house facade, room corner, or similarly textured scene with fixed exposure and white balance, several height bands, substantial overlap, and held-out views. Run COLMAP qualification before any GPU work.
  2. Compare reconstruction tools on the same capture. Run gsplat and Splatfacto on the identical training and validation split. Compare registration coverage, resource use, validation renders, artifact size, and blind visual review. Do not claim geometry accuracy without ground truth.
  3. Test a surface-oriented Gaussian method only if mesh value is real. If editable surfaces become the requirement, evaluate 2D Gaussian Splatting on the same qualified capture. Its official implementation uses oriented 2D surface elements and includes geometry-oriented regularization and meshing paths. The official 2DGS implementation is the starting point.
  4. Keep generation and reconstruction separate. TRELLIS.2 belongs in the single-object asset lane with independent Blender intake checks. 3DGS belongs in the static-scene lane and should not be forced into a mesh requirement prematurely.
  5. Defer dynamic 4DGS. Continuous action needs synchronized multi-view video or another reliable time-aware capture design, a static-background policy, temporal evaluation, and a separate environment qualification. A handheld orbit of a moving footballer is not enough.
Advertisement