Skip to content

Fix MMU segmentation overflow, height-preview mismatch, and stuck loading overlay#1

Open
CharlesCNorton wants to merge 3 commits into
prusa3d:mainfrom
CharlesCNorton:fix/segmentation-preview-loading
Open

Fix MMU segmentation overflow, height-preview mismatch, and stuck loading overlay#1
CharlesCNorton wants to merge 3 commits into
prusa3d:mainfrom
CharlesCNorton:fix/segmentation-preview-loading

Conversation

@CharlesCNorton

Copy link
Copy Markdown

Three issues in the STL/OBJ/3MF export and preview path, one commit each.

MMU segmentation overflow above 16 materials

encodePrusaTriangleState in src/lib/export/threeMf.ts implemented only the first escape of PrusaSlicer's TriangleSelector painting format (the 0b11 marker followed by four bits of state - 3), which covers states up to 16. States of 17 and above wrapped inside the 4-bit field and serialized to the same token as a lower state, so the painted extruder was wrong on import with no error. It is reachable from the UI: two-light mode produces materialCount² materials and the Palette control goes up to 8, i.e. 64 materials.

The encoder now emits the second escape (0b1110 followed by eight bits of state - 17) that PrusaSlicer's deserializer expects for states 17 through 272. Tokens for states 0 through 16 are unchanged, so existing exports are unaffected.

Height-mode preview did not match the export

In Axis (height) mode the preview shaded per fragment over the vertex bounding box, while the exporter assigns one band per triangle from the triangle centroid over the centroid range. As a result the preview did not reflect the painted output: a single exported face could span several bands on screen, and a given point could fall in a different band than it does in the export.

The preview now bands per face. createSurfaceGeometry bakes a per-face centroid attribute, the shader reads it instead of the interpolated fragment position, and the height range comes from the same centroid range the exporter uses. Directional mode is unchanged, since it already shades per face through flat normals.

Loading overlay could stay up indefinitely

isProcessing is set when a mesh is loaded and was cleared only by the preview's first-paint callback. If that callback never fired (lost WebGL context, or animation frames starved while the tab is in the background), the loading overlay stayed up and every control stayed disabled with no way to recover. A watchdog now clears the loading state after a timeout if the preview has not reported back.

States 17 and up overflowed the 4-bit extended field and serialized to the same token as a lower state, painting the wrong extruder on import. Add the 0b1110 escape plus eight bits of state-17 that the deserializer expects. Tokens for states 0-16 are unchanged.
The shader banded per fragment over the vertex bounding box while the exporter bands per triangle over the centroid range, so the preview did not reflect the painted output. Bake a per-face centroid attribute, read it in the shader, and normalize over the centroid range.
isProcessing was only cleared by the preview first-paint callback, so a lost WebGL context or starved animation frames left the overlay up and the controls disabled. Add a watchdog timeout that clears the loading state if the signal does not arrive.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant