docs/brainstorm/05-mechforge-rendering-stack.md

MechForge Rendering And Simulation Stack

Date: 2026-04-24

The Confusion To Resolve

For MechForge there are four separate jobs:

1. Generate or modify a design.
2. Render the design so humans can inspect it.
3. Simulate or verify the design.
4. Export the design to real CAD/manufacturing formats.

One tool does not need to do all four.

Recommended MVP Stack

Layer	MVP choice	Why
Design representation	Structured parametric JSON	Easy for LLMs, easy to validate, easy to convert.
Browser renderer	Three.js	Fast, visual, interactive, works inside a web demo.
Fast verifier	Custom beam/truss-style solver	Good enough for reward curves and RL feedback.
Export	STL from Three.js mesh	Immediate tangible artifact.
Future CAD backend	CadQuery first, OpenSCAD second	CadQuery is Python-native and more flexible for OpenEnv.
Future simulation backend	simplified FEM, FEniCSx, or specialized solver	Swap in after the environment loop works.

Why Not OpenSCAD First?

OpenSCAD is good for deterministic programmatic CAD. It is available on macOS and can generate real geometry, but it is not the fastest path for a live web app.

Use OpenSCAD later if we want:

• scriptable constructive solid geometry,
• reproducible .scad artifacts,
• STL export through the OpenSCAD CLI,
• simple parts made from unions/differences.

For the first experiment, Three.js is better because it gives immediate visual feedback in the browser.

Why Not Full FEA First?

Full FEA is the wrong first milestone. It risks spending the hackathon on meshing, solver stability, and packaging instead of the OpenEnv loop.

Better:

1. Start with a simplified verifier that produces a reward.
2. Show that LLM behavior improves under that reward.
3. Add higher-fidelity simulation only after the loop is stable.

The judges care most that the environment trains meaningful behavior and shows improvement. A simple but coherent verifier is acceptable if we explain the limitations honestly.

Benchmark Plan

Before committing to the full environment, run GPT-5.4 through a small prompt-to-design benchmark:

• Prompt asks for a lightweight bracket under a load case.
• Model returns structured design JSON.
• Renderer shows the part.
• Verifier scores mass, stress proxy, deflection proxy, safety factor, and manufacturability.
• We inspect whether the model uses real design patterns like ribs, load paths, holes in low-stress areas, and avoids invalid geometry.

This tells us whether current frontier models already solve the task or whether there is room for RL improvement.

What The Experiment App Does

The app in experiment-mechanical-idea/ implements this benchmark:

• Frontend: Vite + Three.js.
• Backend: Express + OpenAI Responses API.
• Input: natural-language mechanical design prompt.
• Output: structured parametric design JSON.
• Render: plate, ribs, holes, bosses, fixed holes, load arrow.
• Verifier: fast beam-style estimate.
• Export: STL from the rendered mesh.

Final Recommendation

For the OpenEnv version:

1. Keep the agent action space constrained.
2. Use Three.js for the judge-facing demo.
3. Use Python/CadQuery later for real CAD export.
4. Keep simulation/verifier independent from the renderer.
5. Do not let the LLM generate arbitrary meshes in the first version.