State the budgets. See what breaks them.
MBE3Dstudio is a 3D model-based engineering studio. Build the assembly, route the harness, state the budgets as constraints, and check mass, power, clearance, voltage drop, thermal, sensor coverage and traceability against the model you actually built, not against a spreadsheet beside it.
One model, one pass
Geometry, power, harness, sensors, requirements and verification are one JSON file. A single analysis pass computes every derived number exactly once, so the screen and the report cannot disagree.
Constraints that execute
Eight constraint kinds (mass, power, clearance, CG envelope, harness length, voltage drop, sensor coverage, heat density) are evaluated, not read. Each one reports by how much it missed.
Answers in milliseconds
The whole pass re-runs on every edit. Drag a part and the mass, the CG, the interference set and the failing constraint list are already updated before you let go.
Private beta
MBE3Dstudio is in private beta
Access, deployment and programme support are arranged directly. Tell us what you are building.
The problem
The geometry and the budget are different documents
The mass budget is a spreadsheet
The CAD says one thing, the mass roll-up says another, and nobody knows which was updated last. The number that goes to the review board is the one somebody retyped.
Traceability drifts the day it ships
A hand-maintained trace matrix is a snapshot of a model that has since moved. Coverage percentages are true on the morning they were exported and untrue by the afternoon.
“Violated” with no number
A red flag that does not say by how much cannot be triaged, cannot be argued with, and cannot be closed. It is a feeling, not a finding.
What the pass computes
Eight analyses over one model
Mass properties
Total mass, centre of gravity and the full inertia tensor about the CoG, rolled up through the assembly tree. Per-part density falls out of the envelope volume, so a wrong mass is visible as a wrong material.
How it is computed →Power, by operating mode
Every part states its draw per mode. The budget is a real per-mode roll-up including harness loss, not one worst-case number nobody believes.
How it is computed →Clearance and interference
Envelope-to-envelope gaps across the whole assembly. Two parts occupying the same volume is an error whether or not anybody wrote a constraint for it.
How it is computed →Harness length and voltage drop
Runs are routed through explicit waypoints, so length is a measured polyline, not a straight line. Gauge and current give resistance, drop, copper mass and dissipated watts.
How it is computed →Thermal screening
Dissipation per part per mode, volumetric heat density by scope, and the pairs of hot parts sitting close enough to be each other's problem at peak load.
How it is computed →Sensor coverage and occlusion
Each sensor's field of view is swept against the assembly and the vehicle body. You get the unoccluded fraction and, by name, the part doing the blocking.
How it is computed →Traceability, derived
Requirement → function → component → verification, recomputed from the graph every time it is shown. There is no separate document, so there is nothing to drift.
How it is computed →Model integrity
Cycles in the assembly tree, ports wired to nothing, functions allocated to no component, requirements referenced by nobody. Structural nonsense is caught before physics is even attempted.
How it is computed →How it works
Model it, constrain it, read the findings
Build the assembly
Parts carry an envelope solid, a mass, a placement in their parent's frame, ports, a power profile per mode and, for sensors, a field of view. Drag them in the viewport or type the numbers; both edit the same model.
State the constraints
Write the budget as an executable constraint and tie it to the requirement it came from. “The pod shall not exceed 14.0 kg” stops being prose and becomes a check with a limit, a scope and a unit.
Read what is wrong, with numbers
Findings sort by severity, name the offending parts, and select them in the 3D view when clicked. Export the review as Markdown, the bill of materials as CSV, and the viewport as a PNG.
The worked example
A model built to fail its own constraints
MBE3Dstudio opens on a roof-mounted autonomy sensor pod: 15 parts, 11 routed runs, 8 requirements, 6 verification activities and 8 executable constraints. One of those constraints is violated on purpose, and a second finding is a verification record that no longer matches the design, because a tool that opens on an all-green model teaches you nothing about what it is for.
Three more complete models ship with it, under Examples in the toolbar: a survey quadrotor whose battery was trimmed too far aft and whose skid rails are in frame, a 3U cubesat that asks for more power than it generates and deploys a solar wing across its star tracker, and a robotic work cell that reaches to within 40 mm of its guard. Each fails somewhere different, because that is where the analysis earns its keep.
- The V2X antenna mast sits inside the lidar's swept field of view:
91.11 % / 97 %unoccluded, traces to SYS-014. - A verification record still carries the harness routing that r5 replaced:
VER-003marked failed at10.1 % / 5 %, traces to ICD-011. - Mass was past that allocation until r6 pocketed the baseplate and thinned the shell:
13.8 kg / 14 kg, closed against SYS-001.
Where it earns its keep
Early enough to still change the design
Concept trade studies
Three sensor layouts, three sets of numbers, the same afternoon. Because the envelope, the harness route and the budget are one model, moving a part re-costs the mass, the drop and the coverage at once, so a layout can be rejected on measurements rather than on instinct.
Sensor pods and retrofits
Roof racks, mast heads and bolt-on autonomy kits live or die on occlusion and voltage drop. MBE3Dstudio carries the host vehicle as reference geometry, so a camera blocked by the roof skin shows up as a percentage with the blocker named.
Enclosure and payload packaging
Fitting compute, power and thermal into a sealed box is a clearance problem, a heat-density problem and a CG problem simultaneously. Here they are the same problem, checked on every drag.
Design reviews that hold up
The review pack is generated from the same analysis object the engineer was looking at. The verdict line, the constraint table, the trace matrix and the BOM come out of one pass, so the document and the screen cannot disagree.
Private beta
Bring us a model that is about to go to review
Tell us what you are building and we will get back to you within 24 hours with access and a starting model.