This page collects practical recommendations for 3D creators working in TwikBot. Following these guidelines will help you build configurators that are clean, performant, maintainable, and ready for production.
3D Asset Preparation
Keep polygon counts as low as possible. Web-based visualisation has real performance constraints. Aim for the lowest polygon count that still delivers acceptable visual quality. Avoid importing assets directly from CAD without optimisation — CAD geometry is almost always too dense for web use.
Clean up meshes before uploading. Remove duplicate vertices, non-manifold geometry, and unnecessary edge loops before bringing assets into TwikBot. Clean geometry reduces file size and prevents unexpected visual artefacts in the configurator.
Use sharp edges instead of geometry-based bevels where possible. Rather than adding extra geometry to simulate hard edges, use sharp edge definitions and rely on normal map baking. This keeps polygon counts low while preserving visual quality.
Always UV unwrap surfaces that will receive decals, text, or texture projections. UV unwrapping is required for any surface where image-based or vector content will be applied. Do this in Blender before uploading — it cannot be corrected after the fact inside TwikBot.
Organise your meshes by configurable zone. Divide geometry into logical parts that reflect how the product will be configured. A mesh that covers an entire product cannot be partially swapped or coloured — split it into the zones that need to behave independently.
Graph Editor Structure & Organisation
Name every node clearly and consistently. The Graph Editor can become complex quickly. Use descriptive names for all nodes from the start — renaming later is time-consuming and easy to forget.
Group related nodes visually. Use the Graph Editor's layout to keep related logic together. Separate input parameters, material logic, geometry logic, and output nodes into distinct areas of the graph. Use post-its to label sections and add notes — this makes complex graphs significantly easier to read and hand over to others.
Build incrementally and test at each step. Add one piece of logic at a time and verify it works before moving on. Debugging a complex graph is significantly harder than catching issues early.
Avoid duplicating logic — use shared nodes where possible. If the same logic applies to multiple parts of the product, structure your graph to reuse it rather than duplicating nodes. This makes future changes much easier to manage.
Performance Optimisation
Optimise textures for web delivery. Use compressed texture formats where possible and avoid unnecessarily large texture resolutions. A 2K texture is sufficient for most configurator use cases — 4K should only be used where fine detail is genuinely required.
Limit the number of simultaneous geometry swaps. Each geometry swap requires loading a new mesh. Where possible, combine swappable elements into a single mesh with visibility logic rather than loading separate assets.
Test performance on mid-range hardware. Your development machine is likely faster than your end users' devices. Always test configurator performance on a mid-range laptop or mobile device before releasing.
Keep memory usage low, especially for mobile and iOS. iOS devices have strict memory limits and will crash or reload the browser tab if a configurator exceeds them. Use the MB tool in the Graph Editor tools panel to monitor the memory footprint of your product during development. Optimise textures, reduce polygon counts, and limit the number of simultaneously loaded assets to keep memory within safe limits.
Use baked shadow planes instead of real-time shadows where possible. Real-time shadow calculations are expensive in WebGL. A baked shadow plane delivers comparable visual results at a fraction of the performance cost.
Parameter & UI Design
Design parameters from the user's perspective, not the technical perspective. Parameter names and option labels should reflect how a customer thinks about the product, not how the geometry or materials are structured internally. Avoid technical names like "mesh_variant_02" — use "Carbon fibre" instead.
Keep the number of visible parameters manageable. A long list of parameters is overwhelming. Use parameter groups, step-based navigation, and conditional visibility to surface only what is relevant at each stage of the configuration.
Use option lists with clear, descriptive labels. Where a parameter has a fixed set of choices, use an option list rather than a free text or numeric input. This prevents invalid inputs and makes the configurator easier to use.
Use dynamic parameter visibility to simplify the UI. Hide parameters that are not relevant given the current configuration state. For example, if a logo option is disabled, hide all logo-related parameters rather than leaving them visible but inactive.
Test the full configuration flow as a real user would. Go through the entire configurator from start to finish as if you were a customer. Check that the order of parameters makes logical sense, that labels are clear, and that the visual feedback matches expectations at every step.
Export & Output Setup
Define export files as early as possible in the project. Export requirements are often more complex than they initially appear. Clarify the required output formats and file specifications with the manufacturer or client before building the graph, not after.
Verify export files against manufacturing requirements before releasing. Always validate that generated export files meet the exact specifications of the downstream process — file format, units, tolerances, and any format-specific requirements such as line thickness or corner radius for CNC or print outputs.
Use the "show in order" setting deliberately. Only include parameters in the order summary that are meaningful for production or fulfilment. A cluttered order summary makes downstream processing harder.
Test exports with real orders, not just previews. Export files are only generated when an actual order is placed. Always place test orders and inspect the resulting files before releasing a product.
Project & Release Management
Use product versioning to manage changes safely. Never edit a product that is already live in a project without creating a new release version first. This ensures that existing orders and configurations are not affected by changes in development.
Keep projects focused. A project should represent a single deployment context — for example, a specific customer's configurator website. Avoid adding unrelated products to the same project.
Use password protection during development and testing. Enable password protection on projects that are not yet ready for public access. This prevents customers from accessing incomplete or untested configurators.
Document your release notes. Keep a record of what changed in each product release. This is valuable for troubleshooting, client communication, and maintaining a clear history of the product's evolution.
Working with Partners & Clients
Align on export file specifications before starting. Manufacturing requirements vary significantly between clients and production methods. Clarify file formats, tolerances, and naming conventions at the start of the project to avoid rework later.
Involve the client in parameter naming and UI flow early. Clients often have strong opinions about how their product should be presented. A brief review of the parameter structure and UI flow early in the project prevents significant changes later.
Set clear expectations around what TwikBot can and cannot do. Refer to [Capabilities & Limitations] when scoping a new project with a client or partner. It is better to surface constraints early than to discover them mid-project.
Use the Onboarding Guide as a handover tool. When handing over a finished configurator to a client, point them to the Onboarding Guide as their starting point for understanding and managing the product going forward.