In this post, I want to quickly describe the main building blocks that go in to creating a 3D Product Configurator. My goal is to keep it simple enough for most people to understand, without getting too technical. I’ve created a simple “back of a napkin” diagram to get the ball rolling.
A 3D configurator is built using the same approach as building a 3D game. Essentially we are talking about a 3D interactive application, and the process behind the scenes is the same as building any software application, but with a much richer user interface. The main difference compared to 3D games is that the 3D models are built based on real products, often converted from 3D CAD data, and the configurator has the potential to link to a company’s IT system for placing orders.
Here is a diagram that describes the basic architecture of a 3D Product Configurator.
When the application is in action, it is a continuous cycle of the following steps – display 3D scene – get user interaction – perform an action – update 3D scene. These steps are not too dissimilar to any other software application apart from the fact that the visual display is alive and may continue to move, animate or update. The input screen serves as a window into a 3D space, which takes you beyond the limitations of a 2-dimensional display, giving you “depth” to play with.
3D World
The 3D configurator starts by having a 3D world that the digital product exists in. The 3D world is created using 3D applications such as Maya, 3DS Max and Modo, just to name a few key players. These applications create the 3D models and save them out in a format a game engine can read. A game engine is then used to import all the 3D models, and create all the interaction using it’s programming language (code). The game engine is at the heart of the 3D configurator as this is where the 3D assets and programming code come together to form the functionality.
Asset Library
The asset library is where all the objects that are used in the 3D scene live, and often these are just a set of files sitting in a folder structure. The library typically consists of 3D models, material shaders, sounds and images (often used for 3D textures) just to name a few of the main items. The 3D game engine links to these assets and decides what to display based on the interaction rules that get programmed.
Input Devices
Like any modern software application, “app” or game, 3D configurators are built to work on multiple platforms such as computers, tablets, touchscreens, phones, or game consoles. The 3D Configurator application itself, is installed or setup in similar ways to how modern games and software are setup. The user interaction can be through a keyboard, mouse, touch screen or game controller. The 3D configurator detects user interaction in the form of “input into the device”, and triggers a set of code associated with the type of input detected.
Code
This is all the programming rules that are created to enable all the functionality for the 3D configurator. It is built in the same way all software programs are made by a set of files that contain modules, functions and procedures that link to each other.
System Integration
Through the programming code, there is the ability to communicate with other software applications, databases or files to increase the 3D configurator’s ability to integrate with other systems for greater flexibility, scale and streamlining. Product information and placing orders can be accessed directly to and from a company’s IT systems.
So there, we have it, 3D Product Configurator architecture in a nutshell. This diagram will evolve and become more formalised as I continue my research and settle on a visual that describes it in the best way, but for now, “done is better than perfect”! I welcome any and all feedback to help shape this, as it’s purpose is a communication tool to help connect the dots for all of us.
3D Product Configurator Design 