Someone posted a wish on a dev forum that I've watched a dozen people chase: a suit-customizer site built with three.js, a body model wearing a nicely textured jacket, sliders for fit, fabric, collar, cuff, cut, and the scene re-rendering live as you tweak. Reasonable ask. The reality they hit was less kind. Asking the model to generate the geometry directly gave them cubes. Asking it to drive Blender gave them a bad model. Someone in the replies told them they'd taken a wrong turn and should use image or video generation instead, and the original poster's honest response was basically: okay, but how does that render in real time?
It doesn't, cleanly. That whole thread is a good map of a mistake I keep making myself, so let me walk through how I'd actually cut the problem apart.
The part the model is bad at, and the part it isn't
The instinct is to treat "3D suit customizer" as one task and throw the model at all of it. But it's really two jobs wearing one coat. One job is producing believable clothed-body geometry with drape, seams, and fabric that reads as fabric. The other is wiring up the configuration surface: presets, parameter validation, state, the loop that turns a user's choices into something the scene can consume.
The first job is where the blocks come from. A language model narrating vertex positions or spitting out a mesh has no feel for how a lapel sits or how wool falls, so you get boxes or garbage. That's not a prompt problem you can grind your way out of. The second job is boring, deterministic, and completely inside what these tools do well. That's the half worth building.
So the move is to stop asking the model to sculpt geometry it can't, and treat the mesh as fixed input data. You get the model made properly, once, by whatever pipeline actually produces good assets. From then on it's a file you load, not a thing you generate. Everything the user touches lives in a layer above it.
Where VicroCode stops, said plainly
Before the fun part, the boundary, because it matters here more than usual. VicroCode does not run Blender, and it does not generate 3D models. If your plan depends on the platform producing or refining a mesh, that plan doesn't fit, and no amount of framing changes it. The clothed-body asset has to come from somewhere else and arrive as a finished file.
What the platform does give you is the config layer and the delivery. You can host an HTML viewer, run a Python backend, keep presets in a database, expose an endpoint, and publish the whole thing. That's the winnable half, and it happens to be the half the forum poster kept fumbling.
Pin the mesh, host the viewer
The front end is a static three.js scene: load the fixed model, set up lights and a camera, and expose the handful of parameters you actually support as UI controls. Fabric swaps become material or texture changes on existing surfaces. Fit and cut become whatever your asset was authored to allow, morph targets, swappable sub-meshes, blend weights, whatever the artist baked in. The viewer never invents geometry. It only reads a config object and applies it to parts that already exist.
Because it's just HTML, JS, and asset files, you can run HTML online and get a shareable URL without standing up your own web server. Whether the final render looks good is unverified and depends entirely on the quality of the asset you loaded, not on anything the platform claims. I'd build the shell against a placeholder model first so the plumbing is proven before a real suit ever shows up.
The config brain lives in Python
This is the piece the thread never got to, and it's the piece that makes the thing feel real. The browser shouldn't decide what's a legal combination. A double-breasted cut might rule out certain lapels; a fabric might only ship in specific finishes. Put that logic in a small backend so the rules live in one place and the viewer stays dumb.
You can run Python online to host that config service: take the user's selections, validate them against the ruleset, resolve a named preset into the full parameter set the scene expects, and hand back a clean object the viewer applies. Expose it as an API endpoint the front end calls on each change. Keep the contract small, a config in, a resolved config out, so you can swap the asset or extend the rules later without touching the browser code.
Presets in SQLite, not hardcoded
Early on I always hardcode presets in the source, and I always regret it, because the moment you want to add a fabric or tweak a default you're back in a redeploy. Put them in a table instead: preset name, the parameters it sets, which options it allows, display order. The Python endpoint reads from it, so adding a new style is a row, not a release.
When you need to fix a swatch or reorder the list, the SQLite editor lets you edit rows directly rather than writing a one-off migration script for every small change. It's the difference between the catalog being data you manage and being code you're scared to touch.
The uncomfortable business note
Running alongside these build threads is a steady drumbeat of people asking how anyone actually makes money with AI, and a recurring answer that only the shovel sellers win. I don't think that's the whole story, but it's a useful gut check. A suit customizer is a demo until it's attached to something that pays, an order, a lead, a fitting booking. Build the config layer so the resolved output is also the thing you'd hand to fulfillment, not just a pretty preview. The platform can publish and monetize the project, but revenue and any customer outcome are unverified and entirely on you and the offer, not on the tooling.
What I'd actually ship first
If I were the person in that thread, I'd stop fighting the model over geometry today. I'd stand up the HTML viewer against a placeholder mesh, wire the Python config endpoint with two or three presets in a table, and prove the full loop end to end: click a swatch, endpoint resolves it, scene updates. Ugly placeholder, working machine. Then, and only then, drop in the real asset once it exists. The blocks were never the interesting problem. The config layer was, and that's the part you can build and host right now.