A 3D view that changes with every choice the rep makes

A spec sheet does not tell a buyer what they are getting. Product photos show the standard build, not the one with the taller cabinet and the second door, and a rendering from the design team arrives after the deal has moved on. So reps describe, customers imagine, and the mismatch surfaces after the order is placed.

Teams that do have a visualization tool usually run it beside quoting, not inside it. One group maintains the picture and another maintains the pricing rules, and the two drift apart until a customer is shown an option the configurator will not sell them.

The 3D library is the catalog of source files for your environment; upload a file once and any model can reference it. Twelve source formats are accepted: glTF, GLB, STEP, IGES, STL, OBJ, PLY, FBX, DAE, USD, USDZ, and 3MF, with both long and short extensions for STEP and IGES. Uploads are checked against a per-file limit, 200 MB by default, and against the storage allocation for your environment, and an upload that would exceed the allocation is stopped mid-stream, not after you have waited for it to finish.

Conversion runs in the background. Every upload is converted to a viewer-ready glTF, and the asset moves through four statuses: pending, converting, ready, failed. The platform also reads the geometry into a manifest of nodes, meshes, materials, animations, and anchor points, and generates level-of-detail variants for larger meshes. If a conversion fails, the reason is shown on the status badge and you can retry it or upload a corrected file.

Versions protect the models that use an asset. Uploading a new file to an existing asset creates a new version, and it must be in the same format as the original. Bindings point to a specific version, never to the asset in general, so a library upload cannot change a live configurator until an administrator re-saves the model's bindings against the new version. Older versions are kept for audit, and an asset that any model still references cannot be deleted.

Bindings are the link between configuration and geometry. Each binding is one trigger and one or more actions. There are five trigger types: an attribute equals a value, an attribute is one of a list of values, an attribute has a value, an attribute is empty, or an expression written in the configurator's expression language evaluates true. There are ten actions: set visibility, set material color, set emissive glow, set opacity, set transform, replace material, play animation, swap mesh, frame camera, and show annotation. A model can hold up to 200 bindings, each binding up to 50 actions, and a list trigger up to 50 values.

Every geometry, attribute, and option reference is checked against the pinned version and the model at save, with the failing field marked, and colors must be six-digit hex values.

The viewer appears at the top of the configurator workspace for any model that has bindings. It is read-only for the rep: they configure in the form, and the viewer responds. After each change, the server works out which bindings are active and sends that list to the browser, which applies the matching actions, in the same evaluation that updates price, lead time, and the bill of materials. Converted files are served through short-lived signed links tied to the user's logged-in session.

• Upload to the 3D library. Config, then 3D Library. Pick a file, name the asset, and submit. The list shows name, format, size, status, and last update. Names are unique within your environment, so a convention such as model code plus variant suffix keeps the list readable.
• Open the model's bindings. Config, then Models, then the model, then 3D Bindings. Choose an asset version that is ready. The editor's pickers list only the nodes, meshes, materials, animations, and anchors in that version's manifest.
• Start with auto-bind. The Auto-bind button scores the model's attributes and option values against the manifest and returns ranked suggestions. A minimum score, 0.7 by default and adjustable between 0.5 and 0.95, drops weak matches. Apply to all meshes, on by default, lets one visibility suggestion cover every mesh that matches a pattern. Accept the strong suggestions, edit the borderline ones, dismiss the rest.
• Refine by hand. Each action carries its own settings: emissive intensity from 0 to 20, opacity from 0 to 1, animation speed from 0.01 to 10 with loop off and hold-last-frame on by default, camera padding of 1.2 by default, and annotation variants of info, warning, and success.
• Test on the server. Test bindings opens a panel where you set attribute values, run, and see which bindings fire. The server evaluates them with the same evaluator the configurator uses, so a passing test is a real signal. A syntax error in an expression trigger is reported inline and blocks saving.
• Matt, the Neblex AI Assistant. Ask Matt how to express the condition behind a trigger, or to draft the rule or function that sets the hidden flag a binding watches. Matt advises and drafts for you to review; it never saves bindings or changes a model on its own.

• Twelve accepted source formats: glTF, GLB, STEP, IGES, STL, OBJ, PLY, FBX, DAE, USD, USDZ, and 3MF
• Background conversion to viewer-ready glTF with pending, converting, ready, and failed status
• Manifest of nodes, meshes, materials, animations, and anchor points, plus level-of-detail variants for larger meshes
• Per-file upload limit, 200 MB by default, and a storage allocation enforced during upload
• Versioned assets, with bindings pinned to an explicit version so library uploads never change a live configurator silently
• Deletion blocked for any asset a model still references, and retry for a failed conversion without re-uploading
• Five trigger types and ten actions, from visibility and color to camera framing and annotations
• Up to 200 bindings per model, 50 actions per binding, and 50 values per list trigger, adjustable per deployment
• Auto-bind suggestions scored against the manifest, with a minimum score and accept, edit, and dismiss per suggestion
• Server-side binding test that simulates attribute values and reports which bindings fire
• A read-only viewer in the configurator, with active bindings decided on the server and per-model camera, render quality, and exposure settings

The product is a floor-standing electrical enclosure with a body color, a door style, an optional cooling fan, and an optional viewing window.

1. 1The designer uploads the CAD export. A STEP file of the full enclosure goes into the 3D library as "ENC-4000" and moves from pending to converting to ready. The manifest lists the body, both doors, the fan assembly, the window cutout, and the designer's camera anchors.
2. 2The administrator opens 3D Bindings on the enclosure model and selects version 1 of ENC-4000.
3. 3Auto-bind does the first pass. Body Color options Signal Gray, Traffic Red, and Sky Blue each resolve to a color, so a material color binding on the body is proposed per option. Cooling Fan matches the fan assembly mesh, so two visibility bindings are proposed: show when the attribute has a value, hide when it is empty. Door Style options match the two door meshes, and one binding per option shows one door and hides the other.
4. 4The administrator edits one suggestion. The window match scored 0.68, just under the default threshold. They lower the minimum score, accept it, and add a second action: frame the camera on the door anchor with padding 1.5 so the rep sees the window as soon as it is selected.
5. 5A rule supplies a flag. A computation rule already sets a hidden RequiresVentilation value when the installed heat load crosses a threshold. The administrator adds a binding with an expression trigger on that flag whose actions set an emissive glow on the vent grille and pin a warning annotation reading "Forced ventilation required" to the roof anchor.
6. 6Test before saving. They set Body Color to Traffic Red, Cooling Fan to true, and a heat load high enough to trip the flag. The color, fan, glow, and annotation bindings light up; the unselected door's binding does not. A stray bracket in one expression is reported against that trigger before anything is saved.
7. 7The rep configures. Picking Traffic Red recolors the body. Adding the fan shows the assembly. Choosing the windowed door swaps the door and swings the camera to it. The same choices move the price and add the fan kit and window frame to the bill of materials in the sidebar.
8. 8The designer improves the geometry. A corrected fan assembly is uploaded as version 2 of ENC-4000. The live model stays on version 1 until the administrator reopens the bindings, chooses version 2, reruns the test, and saves.