Last quarter I inherited a catalog problem: 220 furniture pieces, fourteen showrooms, and a web team that wanted every piece in AR and in a store-planning view. The photos existed. The pipeline did not. Tripo3D covered the products, GenAnywhere covered the rooms, and the glue between them was about four hundred lines of Python.
Two inputs, two systems
GenAnywhere handled the showroom side. Pick a store on a map, get the building shell, the parking lot, the street, and the neighbors. It is context at the scale of a site plan, and it is good enough to answer whether a sofa blocks an aisle. That is geospatial context, not product geometry.
Tripo3D handled the product side. Each piece had six to twenty vendor photos taken on a turntable. The API takes those, returns a mesh, and exposes the processing steps I care about: segmentation, retopology and UV mapping, PBR materials, and for the few animated pieces, rigging. One submit call replaces a folder of manual work.
The shape of the job
The manifest is a CSV. One row per SKU, one folder per row, a checksum so a re-run does not pay twice. Batch processing only works when the input set is boring enough to describe in a table. A manifest also makes failures reviewable: a job that times out is one row to re-run, not a folder someone has to inspect by hand.
Two details matter more than the HTTP. First, upload the photos in a consistent order, because the first image becomes the front reference; that order is part of the contract, not a preference. Second, request retopology at the budget the target device can afford instead of the default. A dining chair does not need 80,000 triangles.
The validation gate
Nothing enters the catalog without passing a script. I check scale against the vendor's published dimensions, confirm the UV layer exists, count materials, and look for the armature on the SKUs that need one. This is 3D validation, and it is cheaper than a support ticket.
The gate caught real things. A lounge chair came back 1.8 meters wide because two vendor photos showed a two-seat version. A side table arrived with its top merged into the base because segmentation had eaten the gap. Both were fixed by re-uploading, not by hand modeling.
Units, pivots, and the boring stuff
Tripo3D exports glTF in meters with a Y-up axis, and origins usually sit near the geometric center. The store planner wants Z-up and an origin on the floor. I convert on import and move the origin to the lowest vertex. This is a five-line function and it saves a week of manual placement.
Coordinate systems are the part of automation that gets skipped in planning. GenAnywhere tiles arrive in a projected system tied to the map; product GLBs do not. I keep one scene root, a parent for the site and a parent for products, and record the source CRS in a JSON sidecar for every asset.
Where the map tool fits
GenAnywhere is not a product tool and does not pretend to be. I use it for the shell and the context: walls, windows, floor plates, neighboring buildings that block daylight. The furniture is Tripo3D. The planner assembles them, and the seam between the two is a transform, not a modeling problem. Technical art is mostly owning that seam.
Failure modes worth budgeting for
Background clutter in vendor photos is the common one. A chair photographed in a showroom brings the showroom with it. The segmentation step helps, but a clean cutout at upload is cheaper than a repair later.
Transparent and reflective materials are the second. Glass tables lose their thickness, and chrome reads as flat gray. I flag those SKUs for a manual material pass instead of pretending the automatic texture is finished.
The third is cost. Batch jobs are cheap per unit and expensive in aggregate if you re-run everything after a schema change. The checksum cache is not optional at catalog scale, and neither is a naming rule that survives a new hire.
What the pipeline bought
The catalog ships nine hundred assets a month now, with two people. The AR views work, the store planner works, and the only hands-on work left is the material pass and the occasional bad photo set. The interesting part is that the two tools never touch each other. The map tool builds the room; the asset pipeline fills it.
Top comments (0)