MyBenchLab
MyBenchLab is a visual mechanism simulator. You describe a mechanical assembly as a small bench of connected components and the engine propagates motion through the graph. The 3D viewer shows the mechanism live while you edit.
The engine is kinematic only: it resolves angular velocity (ω) and accumulated angle (θ) at every node, deterministic given the same inputs. No forces, no inertia, no collisions. That keeps the math fast and predictable, which is what you want when exploring ratios, layouts, and gearing decisions.
Available component kinds
| Category | Kind | Description |
|---|---|---|
| Mechanical | Spur gear | External gear with involute-like profile; meshed in parallel-axis pairs |
| Mechanical | Helical gear | Spur gear with a helix angle; same propagation rule, angled teeth |
| Mechanical | Bevel gear | Intersecting-axis gear; mitre pair (45°+45°) supported out of the box |
| Mechanical | Shaft | Rotating rod; couples ports on both ends |
| Mechanical | Rack | Linear rack; pairs with a pinion spur gear via rack-and-pinion connection |
| Mechanical | Pulley | Belt-driven wheel; pairs via belt connection |
| Mechanical | Sprocket | Chain-driven wheel; pairs via chain connection |
| Mechanical | Worm | Worm screw; pairs with a spur gear acting as worm wheel |
| Mechanical | Crank | Rotating arm (lever); same rotational port as a shaft |
| Mechanical | Motor | Self-driving component; injects RPM automatically |
Connection kinds include gear mesh, helical mesh, bevel mesh, rack-and-pinion, shaft coupling, belt, chain, and worm mesh. See the component catalog and connection catalog for full parameter and port documentation.
Mental model
Every bench is a graph:
- Components are typed nodes (a spur gear, a shaft, …). Each one knows its parameters, its 3D geometry, and which ports it exposes.
- Connections are typed edges (gear mesh, shaft coupling, …). Each one owns a propagation rule (how ω crosses it) and optionally a layout rule (how it places the driven part in space).
- Drivers inject ω at specific nodes — typically an input RPM on the first shaft.
On every tick the engine (1) resets ω to zero, (2) applies drivers, (3) BFS-propagates ω through the connections, (4) accumulates θ += ω·dt, (5) renders. A node that receives two inconsistent ω values from different paths is flagged as a conflict — the simulation halts rather than silently averaging.
Authoring
Benches are written in plain JavaScript via the defineBench helper. The compiler strips export default and runs the body in an isolated Web Worker sandbox — no access to window, document, fetch, or Meteor. A minimal bench looks like:
export default defineBench(({ mech }) => {
const G1 = mech.spurGear({
id: 'G1',
teeth: 20,
module: 2,
transform: { position: [0, 0, 0] },
});
const G2 = mech.spurGear({ id: 'G2', teeth: 40, module: 2 });
mech.mesh(G1, G2);
mech.drive(G1, { rpm: 60 });
});The layout solver auto-places G2 tangent to G1 so you rarely need to hand-compute coordinates — only one anchor usually needs an explicit transform. See DSL reference for the full API and Guide for the end-to-end workflow.
Alternatively, use the Blueprint visual editor to build benches by dragging component kinds from a palette and connecting their ports — all mutations write back to the same JavaScript source.
Where things live
| Topic | URL |
|---|---|
| Guide | /docs/guide |
| DSL reference | /docs/dsl |
| Groups / subassemblies | /docs/groups |
| Component catalog | /docs/components |
| Connection catalog | /docs/connections |
| Custom components | /docs/custom-components |
| LLM index | /llms.txt |
Versioning
The engine declares an apiVersion for its plugin contract. Every component or connection kind declares which version it targets, and benches record which engine version they were last compiled against. When the contract evolves, older benches are adapted forward automatically — you should never have to edit a saved bench to keep it running after an engine upgrade.