all lessons / computer_vision_3d / 13 · generative 3D & systems lesson 13 / 13

Generative 3D, dynamics, and 3D systems

The track has built both directions: graphics maps a 3D scene to images, while reconstruction maps observations back to 3D. This capstone asks what happens when measurements are incomplete or absent and a learned prior must supply the missing structure: generate 3D from text or a single image, handle scenes that move (time — the fourth dimension), and ship the result under real latency, memory, sensor, and editability constraints. Then we name the metrics that decide whether any of it worked — and expose the ones that quietly lie.

The plan
Six moves, then a wrap-up. (1) Name the real data obstacle: raw asset count is not the same as usable 3D supervision with canonical scale, complete geometry, materials, cameras, semantics, and physical metadata. (2) Study the historically important 2D-prior distillation route (Score Distillation / DreamFusion) and why independent-view supervision fails. (3) Cover native 3D generation across meshes, points, fields, Gaussians, and structured latents — triplanes are one important representation, not the only backbone. (4) Cover multiview generation and feed-forward reconstruction (LRMs): modern systems often generate consistent views, reconstruct an asset in one pass, then refine it. (5) Dynamics / 4D: deformation fields, 4D Gaussians, and parametric human models. (6) Systems & deployment: representation-by-product, metrics, calibration, time-sync, and the bridge from a 3D engine to synthetic vision data. We close by folding all thirteen lessons back into lesson 01's loop without pretending every method is literally the same algorithm.

1 · The data obstacle: usable 3D supervision, not just asset count

Recovery and generation look symmetric but are not, and much of the asymmetry is a data problem. To recover 3D you can measure geometry (lesson 03) or constrain a scene with several observations (lessons 09–12). To generate 3D you need a prior over plausible shape, appearance, topology, articulation, and often physics — including parts no camera saw. Large 3D collections exist, but their useful supervision is far less uniform than their object counts suggest.

Image-text pretraining can exploit enormous, weakly labeled web corpora. Objaverse-scale collections and captured multiview datasets have made native 3D training possible, but a model-ready asset may still need watertight or at least coherent geometry, consistent units and orientation, usable topology/UVs/materials, camera trajectories, licensing, semantic parts, articulation, collisions, and physical properties. Many files are duplicates, broken, view-biased, or missing those fields. The bottleneck is therefore not a timeless “1000×” ratio; it is the amount, diversity, and provenance of canonicalized, renderable, physically and semantically meaningful 3D for the task.

The organizing question
Ask two first-principles questions: where does cross-view / 3D consistency come from, and when is the computation paid? Three useful families are: distill a 2D prior during per-asset optimization; train a generator over native 3D representations; or amortize reconstruction into a feed-forward network trained on multiview/3D data. They are not exhaustive or disjoint. A modern pipeline may use a video diffusion model for multiview appearance, a feed-forward reconstructor for geometry, native 3D tokens for topology, and test-time optimization for the final asset.
RouteWhere the 3D signal comes fromLandmarkPer-asset costMain failure
2D-prior distillationa frozen image prior + differentiable rendersDreamFusion (SDS)slow — per-asset optimizationview inconsistency / unstable optimization
Native 3D generationassets, scans, or 3D latents/tokenstriplane, mesh, point, Gaussian modelstrain once, sample fastdata quality, topology, representation bias
Multiview + feed-forwardmultiview video/asset corpora, amortizedmultiview diffusion + LRMseconds, sometimes plus refinementhallucinated backs, cross-view/geometry drift

2 · Historical foundation — 2D-prior distillation (SDS / DreamFusion)

DreamFusion was a pivotal proof of concept: its per-prompt optimization does not require a paired text–3D training corpus. A pretrained text-to-image diffusion model (CV lesson 17) contains powerful appearance and semantic priors, though not a guaranteed coherent model of every viewpoint. The method asks a differentiably rendered 3D representation to find a shape whose random-view images the 2D prior considers plausible.

Set up the loop exactly as in lesson 01 §1, but with a generative critic in place of a captured image. Let the thing we optimize be a 3D representation with parameters θ — a NeRF (lesson 09) or a set of 3D Gaussians (lesson 10). Repeat:

This is Score Distillation Sampling (SDS), the engine of DreamFusion. Concretely, noise the render, let the diffusion U-Net \hat{ε}_\phi predict the noise, and the SDS gradient of the loss L w.r.t. the 3D parameters is (dropping a per-step weight w(t)):

θ LSDS = 𝔼t,ε[ w(t)\,(\hat{ε}φ(xt; y, t) − ε)\;·\;∂x/∂θ ] .

Read it piece by piece. The bracket (\hat{ε}φ − ε) supplies an image-space update derived from the diffusion denoiser for prompt y. The factor ∂x/∂θ is the renderer Jacobian: it carries that update into 3D parameters. SDS avoids backpropagating the full diffusion-model Jacobian and uses the noise residual as a practical gradient estimator. The asset-optimization loop needs no paired 3D target; its knowledge still comes from the images, captions, biases, and any view-conditioning data used to train the prior.

The trap: the multi-face "Janus" artifact
SDS supervises each rendered viewpoint independently against a 2D prior that has an overwhelming bias toward canonical front views (the web is full of faces and product fronts, not backs). So every viewpoint independently tries to become a front — and you get an animal with a face on the back of its head, or a person with two fronts. This is the Janus problem (named for the two-faced Roman god), and it is the signature failure of naïve SDS. Its cause is structural: a per-view 2D prior has no notion of a consistent 3D object. Alongside it: oversaturated, cartoonish colors and low diversity (many prompts collapse to similar looks), both traceable to the high guidance weights SDS needs to get a usable gradient.

Fixes, and why they work. Two lines of attack, each removing one root cause:

Place SDS correctly in the 2026 landscape
SDS is a historical foundation and still a useful optimization ingredient, not the universal default for production image/text-to-3D. Multiview-aware image/video priors now provide stronger joint-view consistency; feed-forward reconstructors amortize geometry prediction; native 3D models can directly generate structured assets; and many systems combine those pieces with a short refinement stage. The lasting lesson from SDS is the interface: a learned image prior can supervise 3D through a renderer — and its blind spots become 3D artifacts.

3 · Native 3D generation

The native family confronts the data gap head-on: train a generative model directly on 3D data (Objaverse and friends). Diffusion, flow matching, or autoregression can operate over different 3D encodings. The first question is therefore what 3D representation do you generate?, and the answer recapitulates the representation zoo of lesson 01:

An influential representation for 3D-aware generation is the triplane, popularized by EG3D. The obstacle is exactly lesson 01 §3: a dense 3D feature volume is O(N³) and blows up memory. The triplane factors that volume into three orthogonal 2D feature planes — one each in the XY, XZ, and YZ planes. To read the feature at any 3D point (x,y,z), project it onto all three planes, bilinearly sample each, sum (or concatenate) the feature vectors, and decode them into color, density, SDF, or another field quantity:

f(x,y,z) = \text{MLP}\big(\,Pxy(x,y) + Pxz(x,z) + Pyz(y,z)\,\big) .

Three wins fall out at once. Memory drops from O(N³) to O(3N²). The planes are ordinary 2D feature maps, so mature 2D CNN/diffusion machinery applies. A small decoder preserves continuous queries and differentiable rendering. But this factorization is not free: axis-aligned planes impose representation bias, and a radiance-field triplane is not automatically an artist-ready mesh. Modern native systems also generate mesh tokens, sparse voxel/point latents, Gaussian sets, and part graphs; the output contract should select the representation.

4 · Multiview priors and feed-forward reconstruction (LRM)

SDS pays optimization cost per asset; a native generator samples from its learned 3D distribution. A Large Reconstruction Model (LRM) solves a different problem: it amortizes image→3D inference into a transformer trained on large multiview/3D datasets, mapping one or a few images directly to a 3D representation — a triplane, Gaussians, a field, or a mesh — in a forward pass. Some systems stop there; others spend a smaller test-time refinement budget to enforce the input views or improve topology.

This is the sharpest contrast in the whole track. Recall how lessons 09–10 produce a 3D asset: you take posed images of one scene and run gradient descent for minutes-to-hours on that scene's parameters, from scratch, every time. NeRF and 3DGS are per-scene optimizations — brilliant fits, but the work is not reusable across scenes. LRM amortizes that optimization into a network: it pays the cost once, at training time, over many scenes, and thereafter reconstruction is a forward pass. Put side by side:

NeRF / 3DGS (lessons 09–10)LRM (feed-forward)
What is optimizedthe 3D parameters of this one scenenetwork weights, once, over many scenes
Cost at inferenceminutes–hours of gradient descent per sceneone forward pass — seconds
Views neededtypically many posed viewsone or a few images
Quality ceilingas good as the optimization & views allowbounded by the training distribution
Outputa radiance field / Gaussians for that scenea field, Gaussians, or mesh predicted directly

The trade is prior strength and speed versus instance-specific fitting. A feed-forward model can plausibly complete unobserved regions but inherits its training distribution; per-scene optimization can fit the observed views more tightly but cannot recover unseen truth without a prior. For “here is a photo, give me a usable asset now,” the strongest practical pattern is increasingly hybrid.

The modern landscape is a pipeline, not three sealed boxes

  1. Condition and expand the evidence. A multiview-aware image/video diffusion model produces a camera-indexed set of jointly consistent views, normals, or depth rather than scoring each view independently. This gives the reconstruction stage more evidence, but generated views are hypotheses — not measurements.
  2. Reconstruct feed-forward. An LRM or geometry foundation model predicts Gaussians, a field, or a coarse mesh in one pass. This amortizes the expensive search and establishes a consistent coordinate frame.
  3. Convert for the product. Extract or generate a mesh if collision, UV editing, rigging, or conventional rendering is required; keep Gaussians or a field if novel-view quality is the product.
  4. Refine and validate. Optimize briefly against the real and generated views, regularize topology/materials, and reject cross-view contradictions. Refinement can improve consistency, but it cannot turn a hallucinated back view into ground truth.

Native 3D generation remains important when the desired output is itself structured — valid mesh topology, semantic parts, articulation, or scene graphs. Multiview generation is strongest when web-scale appearance priors matter. Feed-forward reconstruction is strongest when latency matters. A “state-of-the-art method” is therefore defined by the output contract and validation set, not by one universal architecture.

5 · Dynamics — the fourth dimension (4D)

Everything up to here, generation included, assumed a static scene. Real scenes move: people walk, cloth flaps, cars drive. Adding time turns 3D into 4D, and the representations of lessons 09–10 extend in two natural ways.

Dynamic NeRF / 4D Gaussian Splatting. Two strategies dominate, and they map onto the implicit/explicit split:

Parametric models for the special case that matters most: humans. A general deformation field is unconstrained; but humans (bodies, faces, hands) are so common and so structured that the field built low-dimensional parametric mesh generators for them, fit from data:

ModelCoversParameters
SMPLfull bodypose θ (joint rotations) + shape β
FLAMEface / headexpression + shape + pose
MANOhandshand pose + shape

Each is a differentiable function M(θ, β) → \text{mesh}: feed a few dozen numbers, get a full mesh. Crucially the rotations here are exactly the SO(3) joint rotations of lesson 02 — SMPL's pose θ is a stack of axis-angle rotations, optimized on the manifold. Because the parameter count is tiny, you fit the model to images or point clouds by optimizing those few parameters (the inverse-rendering loop of lesson 01, restricted to a low-dimensional prior). This is what powers markerless motion capture, avatar/AR try-on, and animation: the parametric model supplies the missing 3D prior that makes an otherwise ill-posed fit well-posed.

6 · 3D systems and deployment — the CV 19 analog

This section is to this track what CV lesson 19 was to the 2D track: the shift from "does the method work in a paper" to "does the system survive contact with a product." Three parts: representation by product, evaluation metrics and their pitfalls, and the silent failures nobody puts in the paper.

(a) Representation by product

The whole track's refrain — choose the representation from the constraint, not the fashion (lesson 01) — is decided here. Four products, almost no shared design choices:

ProductRepresentationHard constraintWhy
AR / VRtextured meshes, level-of-detail streamingtight memory + battery; GPU-native drawmobile GPUs rasterize meshes cheaply; LOD streams only what's visible
Autonomous vehiclesLiDAR points → voxels / BEV / occupancyhard real-time, multi-sensor fusiondetection/planning run in bird's-eye-view; occupancy handles unknown objects (lesson 11)
Content / graphicsmeshes, or Gaussians for captureartist editability + tool ecosystemmeshes plug into DCC tools; Gaussians (lesson 10) capture real scenes fast
RoboticsSDF / TSDF, occupancy gridsfast collision queries for planninga dense-grid SDF supports constant-time local interpolation; other SDF representations have different query costs

Two of these deserve a note. Robotics leans on TSDF fusion (truncated signed distance function) — the KinectFusion recipe: integrate each depth frame into a running voxel SDF, averaging out sensor noise into a clean surface you can both render and query for collisions. And autonomous stacks increasingly predict occupancy directly (lesson 11) precisely because a bounding-box detector fails on the object classes it was never trained on, whereas "is this volume occupied?" degrades gracefully.

(b) Evaluation metrics — and their pitfalls

Each 3D task has its own metric; you must know what each measures and where each lies.

What you evaluateMetricMeasures
Geometry (shape)Chamfer distance, F-score@τChamfer: mean bidirectional nearest-neighbor distance. F-score: precision/recall of points within threshold τ
Novel-view synthesisPSNR, SSIM, LPIPSpixel error; structural similarity; learned perceptual distance
DepthAbsRel, δ<1.25mean relative error; fraction of pixels within a 25% ratio band
3D detection3D mAP, nuScenes NDSmean average precision over 3D IoU; NDS blends AP with translation/scale/orientation errors
6-DoF poseADD, ADD-Smean 3D distance between predicted and GT model points (ADD-S uses nearest-neighbor, for symmetric objects)
The trap: a metric can pass while the result is wrong
Two pitfalls to say out loud in an interview. (1) Chamfer distance can be disproportionately sensitive to outliers. It averages nearest-neighbor distances, so a very distant stray point adds an unbounded per-point contribution (or an even larger squared contribution), though averaging means whether it dominates depends on point count and convention. Chamfer can also reward coverage over fine detail: a blobby, over-dense prediction may score well while missing crisp structure. F-score@τ is bounded and thresholded, but introduces a task- and scale-dependent τ; report the convention and usually multiple geometry measures. (2) PSNR ≠ perceptual quality. A slightly blurry render can beat a sharp one on PSNR because blur has low pixel error, yet look worse to a human — which is why LPIPS exists and why novel-view papers report complementary metrics. The widget below makes pitfall (1) tangible for this point set.

(c) The silent failures

These sink real 3D systems and appear in no benchmark:

Bridge: turn a 3D engine into a vision-data engine
A prebuilt scene becomes useful supervision only after its latent state is parameterized, its sensors are modeled, and every frame is synchronized with reproducible labels. The dedicated Synthetic Vision Data track continues from here: scenario distributions and counterfactual branches, camera/LiDAR measurement chains, RGB/depth/normals/flow/occupancy ground truth, leakage-safe splits, neural appearance transfer, and the real-data loop that decides whether simulation helped.

Where this leaves you — the whole track in one line

Step all the way back. Lesson 01 introduced a powerful loop: pick a 3D representation → render or project it → compare to observations → update the representation. Across these thirteen lessons, lesson 02 gave the SE(3) machinery to place and optimize poses; lessons 03–05 moved from depth and point clouds through registration to surfaces; lessons 06–08 built the forward graphics path; lessons 09–10 built differentiable radiance-field and Gaussian renderers; lesson 11 learned across 3D scenes; and lesson 12 recovered relative, metric, calibrated, and unposed geometry from images.

This capstone changes the source of constraint. Reconstruction is anchored primarily by measurements; generation is anchored primarily by a learned prior; modern systems mix both. SDS literally pushes a prior through a renderer, LRMs amortize reconstruction, and native generators learn a distribution directly in a 3D representation — so not every method is the same inverse-rendering algorithm. The unifying questions are deeper: what is represented, what observations or priors constrain it, which transformations preserve consistency, where is computation paid, and how is failure measured? Dynamics adds time; deployment adds sensors and budgets; the synthetic-data bridge turns the forward engine into a controlled source of observations. That is the whole track, and it points back to the track index and its four questions — representation, rendering, recovery, system.

Takeaway
The data bottleneck is not a fixed image-to-asset ratio; it is enough canonicalized, diverse, renderable, semantically and physically useful 3D supervision. Treat the method space as overlapping families. SDS / DreamFusion is a historical foundation: push a frozen image prior through a differentiable renderer, revealing Janus and other prior inconsistencies. Native 3D models generate meshes, points, fields, Gaussians, parts, or structured latents; triplanes are one efficient factorization, not the universal backbone. Multiview diffusion + LRMs can generate joint-view evidence, reconstruct in a forward pass, convert to a product representation, and refine briefly — generated views remain hypotheses. Dynamics/4D add deformation fields, primitive trajectories, or human priors. For systems, representation follows the product; metric choice must match the failure; dense-grid SDF lookup is fast but not every SDF query is O(1); and calibration can sometimes be estimated but must still be observable and monitored. Synthetic data is distribution and measurement engineering, continued in the Synthetic Vision Data track. The unifying questions are representation, source of constraint, consistency, compute, and validation — not the claim that every generator is literally inverse rendering.
Chamfer distance vs F-score — why one metric lies
A fixed ground-truth shape (blue points along a curve) and a prediction (orange, a copy you perturb). We compute both directions of Chamfer, the symmetric Chamfer, and the F-score@τ (harmonic mean of precision and recall within threshold τ). Faint gray links show a few nearest-neighbor matches. Now click "add outlier": one stray point sends the Chamfer distance soaring while the F-score barely flinches — the §6(b) pitfall, made tangible. Then shrink τ to watch a blobby, over-dense prediction lose F-score even when one Chamfer direction looks fine.
outliers: 0
Chamfer(GT→pred)
Chamfer(pred→GT)
Symmetric Chamfer
F-score@τ
Show the core JS
// nearest-neighbour distance from point p to set Q (brute force)
function nnDist(p, Q){
  var best = Infinity;
  for (var i=0;i<Q.length;i++){
    var dx=p.x-Q[i].x, dy=p.y-Q[i].y, d=dx*dx+dy*dy;
    if (d<best) best=d;
  }
  return Math.sqrt(best);
}
// directional Chamfer = MEAN of nearest-neighbour distances (one direction)
function chamferDir(A, B){
  var s=0; for (var i=0;i<A.length;i++) s+=nnDist(A[i], B); return s/A.length;
}
var cGP = chamferDir(GT, PRED);        // GT → pred
var cPG = chamferDir(PRED, GT);        // pred → GT
var symmetric = 0.5*(cGP + cPG);       // symmetric Chamfer (average form)

// F-score@τ = harmonic mean of precision and recall of points within τ
function frac(A, B, tau){               // fraction of A within tau of some B point
  var n=0; for (var i=0;i<A.length;i++) if (nnDist(A[i],B)<=tau) n++;
  return n/A.length;
}
var precision = frac(PRED, GT, tau);    // preds that are near a GT point
var recall    = frac(GT, PRED, tau);    // GT points that are covered by a pred
var F = (precision+recall>0) ? 2*precision*recall/(precision+recall) : 0;

// KEY: adding one far outlier to PRED spikes chamferDir(PRED,GT) (its NN dist is huge,
//   and it enters the MEAN) while precision drops by only 1/|PRED| → F-score barely moves.

Interview prompts