BIGmount

A modular mounting system does not have an assortment in the usual sense. It has individual parts and rules for combining them. The number of possible variants does not grow with the number of parts but with the combinations between them. For an online shop that is exactly where the difficulty starts, because every variant on offer needs a picture.

Photography runs into a practical limit here. Not because it cannot be done, but because it does not scale with the catalog. Every new combination means another setup, and every change to a component triggers repeat shoots. Consistency adds to that: perspective, lighting and framing have to match across all variants, otherwise an overview page looks restless and the difference between two variants becomes harder to read.

So a task of this kind raises an early question: should the images be individual pieces at all. When a product is described by data, its picture can be derived from the same data. The work then moves away from the shoot and towards maintaining that data.

For BIGmount we built a Blender tool that produces the product images. A plugin written in Python reads the parts lists as CSV, assembles the 3D configurations from them and renders them in batches. Camera position and framing are calculated automatically from the size of each configuration.

That last part carries the most weight. A fixed camera only works while all variants are roughly the same size. As soon as one configuration turns out considerably longer or taller, the subject is either cropped or lost in the frame. Derive the framing from the actual dimensions instead, and every variant fills the image in a comparable way without anyone adjusting individual shots afterwards.

Using the CSV list as the starting point has a second effect. It is the same basis on which the configurations themselves are described. Image and parts list cannot drift apart, because they are not maintained separately. A WooCommerce plugin for price maintenance in the shop covers the second stream of data, the one that gets confusing quickly with combinable products.

Once images are generated from data, data quality becomes the deciding factor. A typo in a parts list does not produce a missing image, it produces a wrong one, and a wrong image is noticed less often. It is worth building in checks that reject a configuration before it is rendered, rather than hunting for it in a finished catalog.

The second point is repeatability. A tool that produced a catalog once is worth little if nobody can repeat the run later. That calls for a fixed place where the components live, output file names that can be traced back, and the option to re-render selected variants instead of the entire set every time.

Finally, it pays to limit the scope on purpose. Not every mathematically possible combination belongs in a shop. Which variants are actually offered is a decision about the assortment, not about the technology. An automation should be able to reflect that decision without making it in advance. Otherwise the catalog grows faster than anyone can keep track of it.