Engine Rebuild Decision
Decided to rebuild the in-house Python mesh engine from scratch directly inside the FastAPI backend.
The original mesh stack was built for the earlier Electron prototype. That stack included multiview.py, trace.py, loft.py, quality.py, and export.py. Those files were not available on this machine, which meant the choice was either to fake the pipeline back together with generic replacements or rebuild it properly.
The decision was to rebuild it properly and place it where the current application actually lives: the FastAPI backend. That keeps the architecture aligned with the current product instead of carrying dead assumptions from the old prototype. It also means the engine logic can stay close to the API surface the frontend already depends on.
The rebuild is following the same core flow rather than inventing a different one. The intended order remains multi-view depth merging, contour tracing, CadQuery lofting, Open3D Laplacian smoothing, and vertex-color GLB export. The point of this session was not feature completion. It was making sure the rebuild path stayed honest to the actual engine design.
There was also a clear constraint on what not to do. No PyTorch and no Blender. The value of the Inter-Forge pipeline is that it stays local, inspectable, and headless. If the rebuild depends on a different toolchain than the product claims, then the product story stops being true.
Why This Decision Matters
This session was mostly about refusing a fake shortcut. The current product is not the earlier Electron prototype, so rebuilding around missing prototype files would have pushed the codebase further away from the real application instead of closer to it.
Placing the engine in the FastAPI backend also sets up the later work more cleanly. The frontend already talks to that backend, the API is where jobs get coordinated, and the later Forge fixes only make sense if the geometry pipeline is being rebuilt in the same place the rest of the application actually runs.
Diff Log: Rebuild Route
The bug here was architectural drift. The engine logic still belonged to the old Electron prototype path. The fix was to move the rebuild target into the FastAPI backend where the current app actually lives.
Bug / Fix
- Electron prototype mesh stack as primary integration target
+ FastAPI backend mesh stack as primary integration target
- multiview.py -> trace.py -> loft.py outside current backend
+ Rebuild multiview -> trace -> loft -> smoothing -> export inside backend