CADjs: Web-Based 3D Rendering for Generative Design

CADjs is useful only if it protects the engineer from waiting on geometry. That is the first principle behind this methodology: the browser must stay responsive while the model changes, or the generative design loop becomes a slow slideshow of stale assumptions.

Quick Nav

1. The Rendering Bottleneck in Generative Workflows
2. Selecting and Combining Core Libraries
3. Constructing the Controlled Rendering Pipeline
4. Verification Protocol and Edge-Case Handling
5. Replicating the Setup in New Projects

The Rendering Bottleneck in Generative Workflows

Latency changes engineering judgment

The rendering problem does not begin with triangles. It begins with hesitation.

When a designer waits too long for a topological variant to appear, the parameter sweep stops feeling exploratory. It becomes selective before the data supports selectivity. In the research cycle behind this CADjs methodology, traditional web-based CAD tools showed regeneration latency in the range of roughly 45 to 90 seconds for complex topological variants. That delay was tolerable for a single concept review, but it was poorly matched to sessions that required several hundred to over a thousand distinct geometric configurations.

I treat that as a design constraint, not a user-experience annoyance. A generative workflow asks the engineer to compare patterns: rib growth, void placement, wall-thickness sensitivity, support-access trade-offs. If each comparison carries a large pause, the engineer starts pruning the design space based on patience rather than mechanics.

Controlled comparison: full CAD regeneration versus lightweight rendering

The controlled comparison was simple. One path asked the browser to behave like a compact CAD workstation, regenerating complex variants through conventional web CAD routines. The other path separated visual feedback from heavyweight model authorship. CADjs follows the second path.

The objective was not to replace parametric CAD. It was to create a browser-side rendering layer that could expose the consequences of parameter changes quickly enough for engineering judgment. A sweep of bracket cutout positions, for example, does not need manufacturing drawings at every step. It needs a stable view of whether load paths remain plausible, whether voids collide with keep-out regions, and whether the model has started producing suspicious geometry.

Summary: The bottleneck was not only computational. It changed how aggressively engineers explored the design space.

Selecting and Combining Core Libraries

Assign each library one job

The CADjs stack works because it avoids asking one library to solve the whole problem. three.js owns the scene graph, camera, lighting, BufferGeometry handling, and renderer configuration. CSG.js handles boolean solid modeling over primitive combinations. dat.gui exposes live parameters so the engineer can change dimensions without rebuilding the interface.

This separation matters. Raw WebGL shader work would have offered deeper rendering control, but it would also have pulled attention away from the mechanical workflow. The team explicitly bypassed that route during the integration phase, which spanned roughly two to three weeks. For this methodology, a maintainable scene pipeline had more value than custom graphics cleverness.

For renderer behavior, camera setup, and geometry conventions, the official three.js documentation remains the most useful reference point. I prefer to keep that dependency ordinary. Exotic rendering code is hard to audit when the real question is whether a generated part can survive downstream CAD-to-CAE cleanup.

Boolean operations need boundaries

CSG.js sits at the most sensitive point in the stack. It creates the visual solids that engineers inspect, but it also introduces the risk of non-manifold output when sequential subtractions become aggressive. Primitive combinations in this methodology were clocked at roughly 120 to 250 milliseconds for CSG.js boolean operations, measured across experiments. That timing is fast enough to support interactive work, but not fast enough to ignore scheduling.

dat.gui provides the surface area for the parameter study. It should expose only parameters that the rendering pipeline can regenerate safely: rib count, bore diameter, lattice pitch, shell offset, or support-clearance envelope. It should not become a dumping ground for every internal variable in the optimization script.

Quick Tip: Name GUI controls after engineering intent, not code variables. Use “web thickness” rather than “t_web_03” unless the audience is the solver developer.

Constructing the Controlled Rendering Pipeline

Initialize the scene before geometry becomes interesting

The pipeline starts with discipline: create the renderer, attach the canvas, establish the scene, configure the camera, set controls, add lights, then load the first geometry. That order sounds plain because it should be plain. A generative viewer becomes hard to debug when camera state, mesh construction, and parameter binding all initialize at once.

1. Create the WebGL renderer and bind it to the target container.
2. Initialize the scene with a neutral background and predictable units.
3. Configure camera position, near and far planes, and orbit controls.
4. Add basic directional and ambient lighting for shape legibility.
5. Build the first mesh from the current parameter object.
6. Bind dat.gui controls after the initial geometry has rendered once.

Camera controls and scene initialization sequences were standardized over roughly a month of testing. The result was less dramatic than a new optimization algorithm, but more valuable in daily work: fewer false defects caused by inconsistent viewport state.

Regenerate geometry only when dimensions change

The geometry loop follows an OpenSCAD-inspired pattern. Parameters describe the solid. Boolean operations combine or subtract primitives. The resulting mesh passes into the three.js scene as renderable geometry.

The technical constraint is that parameter sliders can fire more often than geometry can be rebuilt. The workaround is to decouple mesh generation from the main render thread and regenerate only when specific dimensional inputs change. In this CADjs setup, the update cycle was throttled to limit mesh regeneration calls to roughly four per second.

That trade-off is deliberate. A slider may feel slightly less continuous, but the frame remains coherent. The engineer sees a sequence of valid states rather than a flickering cascade of half-built solids. For generative design review, visual continuity often carries more value than raw input immediacy.

Note: Throttling is not a substitute for efficient geometry. It only prevents the interface from punishing the browser while valid updates are still being computed.

Verification Protocol and Edge-Case Handling

Mesh integrity checks after CSG operations

Verification starts where the pipeline is most likely to lie: after boolean operations. Non-manifold geometry generation during rapid sequential CSG subtractions is a practical risk, especially when subtractive features approach shared faces or tangent intersections. A model can look acceptable from one camera angle and still fail later in meshing, export, or simulation.

The verification protocol injected deliberate non-manifold edges into the CSG pipeline to test whether automated checks caught the defect. That is the right kind of ugly test. It does not flatter the renderer; it asks whether the methodology behaves when geometry becomes inconvenient.

Automated integrity checks added roughly 12 to 18 milliseconds of overhead per boolean operation. I would not remove that overhead casually. In a browser-based generative workflow, an early warning about invalid topology is often cheaper than discovering the defect after CAD cleanup or CAE preprocessing.

Facet count pressure and browser limits

Facet count is the quiet failure mode. The scene still loads, the controls still respond, and then the frame rate collapses when a variant crosses a practical rendering threshold.

Performance monitoring indicated severe frame drops when facet counts escalated to somewhere around 150,000 to 220,000 polygons. Frame rate stability depended heavily on the client machine's available VRAM, so the same variant could feel acceptable on a workstation and nearly unusable on a thin laptop. Real-time boolean operations also degrade significantly on mobile browsers lacking dedicated GPU acceleration.

This is where the methodology needs restraint. Keep inspection meshes lighter than final manufacturing meshes. Use the browser to steer the design space, not to certify every downstream representation. The unanswered question is where each organization should draw that boundary for its own components, hardware, and review culture.

Replicating the Setup in New Projects

Pin dependencies before extracting patterns

Replication begins with dependency order, not code reuse. Load the rendering library, then the boolean library, then the GUI layer, then the project-specific geometry definitions. If the order shifts, errors can look like modeling defects when they are really initialization defects.

Dependency pinning locked the rendering library to revision 128 to avoid breaking changes in the BufferGeometry API. That choice is not glamorous, but it protects the methodology from accidental drift. A generative design viewer should not change behavior because a package manager fetched a newer renderer on Monday morning.

• Pin the rendering library revision used by the project template.
• Record the CSG.js version alongside known boolean edge cases.
• Keep dat.gui bindings outside the core geometry functions.
• Store default parameters in a single object that can be serialized.
• Document the maximum practical facet range for the target review machines.

Extract a minimal viable scene template

The minimal template should contain the renderer, camera controls, lighting, parameter object, geometry builder, update scheduler, and mesh integrity hook. Strip out the optimizer. Strip out component-specific heuristics. Leave only the rendering loop and the smallest useful example geometry.

In this methodology, template extraction and documentation required roughly a week of dedicated developer effort. That time produced a clean baseline for future generative design studies rather than another project-specific viewer. The distinction matters. A reusable CADjs template should make the next design space easier to inspect without smuggling in assumptions from the last bracket, housing, or manifold.

Summary: Replication succeeds when the viewer is boring, versioned, and explicit about its limits. The engineering creativity belongs in the parameterized geometry and the constraints, not in fragile rendering setup.

Citations

• three.js documentation for renderer, scene graph, camera, and BufferGeometry reference behavior.