3MF topology guide
Check 3MF Topology: Mesh Fault or Build Placement?
Substantially updated 2026-10-25. First published 2026-09-05.
A topology finding can belong to a stored mesh, while a visible conflict can arise from how healthy meshes are placed. Trace that difference before editing. Repeated items are not duplicate triangle records, and an edge-sharing screen cannot settle every vertex or intersection question.
Trace the finding to a resource or a placement
Start with the owned repeated-item build. One cube resource is placed twice; its retained local .NET processor report (24 October 2026) completes with two components and no listed mesh issues. Do not remove the second placed cube merely to obtain one component. Now compare the repeated-face resource: the redundant triangle creates one duplicate finding and three over-shared edges. This calls for a resource-level correction, not deletion of a legitimate build item.
Keep the valid two-item report and the defective-resource report beside the source packages. The server-method processor checks build items independently; local combined-build methods can interpret coincident placements differently. Inspect the actual selected method rather than treating either component count as a universal assembly judgement. Vertex-only and crossing-surface cases need further review beyond an edge-incidence result.
These retained observations run the repository processor, not an authenticated production revision or physical print. Evidence provenance records fixture hashes and the reproduction command. The public 3MF Manifold Checker returns aggregate counts; it does not provide a per-resource diagnosis. Review the source application's references and visible arrangement to identify the affected resource.
Choose the narrow action for the observation
| Observation | Question to resolve | Narrow action |
|---|---|---|
| One resource is defective and reused | Which placements reference this resource? | Review the effect of a resource edit on all references. |
| Several sound resources overlap when placed | Is the overlap intentional, or is a placement/source-model correction required? | Inspect in the source application; do not call an incidence result an overlap detector. |
| Separate closed parts have no listed edge findings | Are quantity, clearance and arrangement intended? | Keep intentional parts and verify the plate. |
| Open or over-shared edges are reported | Which surface should exist at that region? | Locate the finding, then choose supported removal or source reconstruction. |
| Input or required feature is unsupported | Did this method complete the relevant test? | Preserve the package and use the producing application. |
Do not infer a complete manifold proof from edge counts
The tool name describes the question visitors are investigating. Its actual result is bounded by the implemented checks. State which edge, winding and component tests ran; do not infer vertex-manifoldness, intersection clearance or a correct physical connection from the absence of those findings.
The server method compares exact-coordinate edge endpoints within each resolved build item, excluding invalid-coordinate and degenerate faces from edge incidence. One face contributes a boundary; more than two contributes an over-shared edge. Directed pairs also screen winding conflicts. Components connect through shared vertex coordinates, so a point-only touch may count as one component. Duplicate faces remain in the server incidence count, unlike the local removal-plan screen. No distance-tolerance welding or spatial intersection test is performed here.
After correction, compare required items, transforms and dimensions, repeat the relevant check and inspect affected slicer layers. Use boundary interpretation for closure, local repair only for supported removals, and the repair guide to choose a route when a join or surface is uncertain. Keep intentional parts separate rather than reducing a component count for its own sake.