Some context. We generate in an image-to-3D tool our team runs in the browser: a photo in, a GLB out, usually inside two minutes. The speed is real and it ruined us for a while, because at two minutes a model, nobody audits anything. You drag, you drop, you upload. The first complaint email taught me to slow down.

The uncomfortable truth about image-to-3D is that the generator is honest about what it saw and inventive about what it didn't. Your photo shows three sides of a pitcher. Your product page promises all of them. So before anything goes live, every model walks through three gates. The whole inspection runs about 90 seconds per model, and it has caught problems in five of the last fourteen.

Gate one: the back-half audit. I don't admire the front — the front is the photo, it'll be fine. I spin straight to the back. If I want to be thorough, I drop the file into an STL viewer and rotate it under flat lighting, where melted seams and invented geometry have nowhere to hide. A ceramic pitcher from this batch had a beautiful, correct handle on the left side. The photo only ever showed the left side. The right handle came out mirrored — a subtle mirror, the kind you only catch at the second glance. Customers take the second glance. That's the whole job.

Gate two: material honesty. Generated textures can run up to 4K, and at 4K the glaze has genuine depth. Beautiful. But my rule is the model may be less detailed than the product, never different. So I zoom to wherever a customer will zoom — the glaze line, the wood grain, the stitching — and check the texture against the physical sample on my desk. If the generated surface implies a material we don't sell, that's a return ticket wearing a hero render.

Gate three: hand it to a stranger. Someone who doesn't know the product picks up the laptop, and I watch where they drag first. People rotate toward the most interesting face. If the most interesting face is one the generator invented, the model is teaching customers something wrong about something they can still return. That's not a visualization problem; that's a refund queue.

Then the verdict, one of three letters. A means live — six this month. B means one regeneration away: wrong detail, but the input was sound, and a re-run costs one credit and roughly three minutes, so B is a queue item, not a crisis — all five Bs cleared the same afternoon. C means internal only. Three models sit in that bucket, and their jobs are real: packaging mockups, design reviews, the deck where I show the team how far a single photo gets us. C isn't failure. It's a model whose audience is employees.

I used to think the hard part of 3D commerce would be generating the models. It turns out generation is the cheap, fast, solved part. Publishing a wrong one is the expensive part, and it stays expensive in ways that outlive the launch — screenshots, reviews, the customer who tells the group chat the product looked nothing like the spin. So the review gate stays, ninety seconds at a time. The generator makes fourteen. I decide which six the customers meet.

The rental column

Cloud pricing for this category is subscription-per-credits. trellis2.app, for reference, runs \(19/month for 15 credits, \)49 for 50, and \(99 for 120. Assume one credit per generation and the per-model cost lands at \)1.27, $0.98, and $0.83. The launch-window discount on credit packs shaves roughly 20% off while it lasts; don't build a permanent cost model on a sale. At 40 models a month you never leave the $19 tier. At 200 you are stacking two Business plans and asking the GPU question seriously.

What the subscription actually buys is wider than inference: 25+ style presets, a 4K texture pass, automatic cloud storage, the whole upload-preview-download surface. None of that appears on the invoice as a line item. All of it is engineering weeks you never spend.

The ownership column

Self-hosting starts with a 24GB-class GPU. The architecture behind this generation of tools scales up to 2B parameters, and you want VRAM headroom rather than a laptop card; call it $2,000. Power is the line everybody overestimates. At roughly 400W under load, a two-minute generation burns about 0.013 kWh, which is pennies a month and honest to ignore.

The real cost is people. A serving endpoint, a queue, storage, retries, monitoring: five to eight engineer-days to stand up, plus a maintenance drip that never fully stops. Price internal time conservatively at $600 a day and year one runs about $5,000 to $7,000 all-in before your first model generates.

Where they cross

At $0.83 to $0.98 per model, the rental column crosses the ownership column somewhere around 5,000 to 8,000 generations in year one. That is roughly 400 to 650 models a month, steady, all year. Below that line, an idle GPU quietly becomes the most expensive furniture in the office. If the person standing up the pipeline is a founder whose evenings are "free," the crossover drops toward 200 a month, and that number seduces people into side projects they abandon in March. Price the time anyway.

Year two changes shape. Hardware is sunk, the maintenance drip remains, and ownership gets cheaper at high steady volume. The crossover moves down. Whether it moves enough depends almost entirely on whether your volume is flat or spiky.

The tiebreakers off the spreadsheet

Burst capacity first. A launch week doing ten times normal volume gets absorbed by cloud; behind your single GPU, it queues. Second, product surface. The underlying SLAT architecture came out of published Microsoft Research work, which gets you geometry, but the style system, the 4K texture pass, and the preview UI are finished product features you would be rebuilding from scratch; Trellis 2 ships all three today. Owning the model often means inheriting a second product to maintain, and a security review of a self-hosted endpoint is its own afternoon.

The decision rule

Under about 50 models a month: rent, and stop revisiting the question. Steady volume above roughly 400 a month, existing GPU infrastructure, and a team that genuinely likes running inference: self-hosting starts to earn its keep. The 100-to-400 middle band: rent, watch the monthly number, re-run this spreadsheet quarterly, because volume is the only input that moves and everything else follows it.

My own column reads about 40 a month and zero ops appetite, so I rent. The GPU question is really a volume question. Check the number first; the hardware decision sits downstream of it, never upstream.

Directory convention

assets/
  raw/                  # source photos, immutable, never edited in place
  models/
    sku-0042/
      src.jpg           # the exact image used
      v01.glb
      v02.glb

Two rules make everything else work. First, raw/ is append-only: a reference image never gets edited, a bad one gets superseded by a new file. You will want to know later which photo produced which geometry, and the only reliable answer is the untouched original sitting next to the result. Second, regenerated models get a new version number, always. GLB is binary — diffs tell you nothing — so the version history is your history.

Naming

Kebab-case SKUs, zero-padded versions. The suffix convention I adopted: v01, v02 for regenerations, -lp for decimated low-poly derivatives (v02-lp.glb). Boring, greppable, and it sorts correctly everywhere. The one rule I'd defend in a code review: no version ever overwrites another. Disk space is cheaper than forensic archaeology, and "just replace it and rename the old one old" is how v02 ends up containing v01.

Batch sessions

When a set of references is ready, I queue them in one session through trellis2.app — generations run 1-3 minutes each in the cloud and results autosave — then download the finished GLBs into their SKU folders as v01.glb. The queue rhythm matters more than it sounds: batch the uploads, go do something else, then triage results in a single pass. Per-file context switching is where every past mistake happened.

Validation gate

Every GLB passes through a small script before it can be committed:

npx gltf-validator assets/models/sku-0042/v01.glb

The gate checks three things: triangle count against the prop's budget, texture dimensions (4K masters get downscaled to 1K-2K for engine use — the 4K original stays in cloud storage, retrievable if a hero page ever needs it), and that materials reference embedded textures rather than dangling paths. Failures print the reason and exit 1, so it can run locally and in CI with zero ceremony.

Version control

GLBs live in Git LFS; the source photos are small enough for plain Git. Every commit touching a model references the source image hash in the message:

feat(assets): sku-0042 v02 — regenerated from raw/sku-0042-b.jpg (a3f9c1e), low-poly preset

That one line answers the question that used to eat an afternoon: "which photo did this model come from, and what settings produced it?" When we regenerate six months later, we start from a recorded style preset instead of somebody's memory of one. We alternate mostly between a low-poly preset for background props and photoreal for hero assets, and both are now vocabulary in the commit log, not tribal knowledge.

What's still manual

Two things: the upload-queue step, and the keep-or-regenerate judgment call. Those are the parts where taste operates, and fencing them off from the mechanical parts is deliberate. I'd rather review twenty previews in one sitting than interleave them with file juggling.

The honest measure of this setup: a 20-prop batch that used to take an error-prone afternoon now takes about an hour, and the boring parts — naming, validation, provenance — stopped producing surprises. That's what automation is for. It doesn't replace judgment; it makes sure judgment gets spent on the calls that deserve it.