bf8b1a35d5
2 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
m3ultra
|
bf8b1a35d5 |
Close all four open items: MoGe camera, manifold remesh, winding, UV bake
THE DECIMATION FLOOR WAS MISDIAGNOSED. I attributed it to ~180k boundary edges. It is non-manifold edges. Measured on the shipped 500k mesh: boundary edges 32,370 NON-MANIFOLD 81,112 <- the actual blocker, 2.5x more Quadric decimation cannot collapse an edge shared by more than two faces. Upstream's own fix (fill_holes, via CUDA-only cumesh) targets boundaries and caps at max_hole_perimeter=3e-2, so it was never going to help: trimesh's equivalent moved boundaries 32,370 -> 30,990 and the floor only 214k -> 210k. That falsified it. --manifold: voxelise -> fill -> marching cubes. Removes BOTH classes at once and so closes three of the four items in one change: as shipped 499,984 faces bnd 32,370 nonmani 81,112 watertight=F IoU 0.969 remeshed 1,178,142 faces bnd 0 nonmani 0 watertight=T IoU 0.949 -> 20k 19,998 faces bnd 0 winding consistent IoU 0.956 25x smaller, fully manifold, consistent winding, for 1.3% silhouette IoU. Lossy by design - it gives up the dual grid's open-surface representation - so it is opt-in. UV BAKE is unblocked by the same change: its cost is driven by face count, not by remesh. 5.0s at 20k faces against >20min at 214k. No longer offline-only when paired with manifold. THE SCALING TRAP, worth knowing: marching_cubes returns vertices in VOXEL INDEX space. Translating without apply_scale(pitch) leaves the mesh ~292x too large. It still exports and renders as a plausible object; it silhouettes at IoU 0.08. That is how it was caught. MoGe-2 CAMERA is now wired and is the default, matching upstream; --fixed-fov keeps the old constant. It runs once per image in torch/MPS, ~0.4s after load. Reporting this one straight: it did NOT improve the samples. On 1_img, fixed 49.1 deg scored 0.893 and MoGe's 29.7 deg scored 0.883. Two caveats keep it as the default anyway - the silhouette metric projects with the SAME FOV used to generate, so a wrong-but-consistent camera can still score well and the metric cannot fully arbitrate camera correctness; and the bundled samples are synthetic renders, not the photographs MoGe reads. Real photos are the intended input here, and upstream estimates too. But the constant is one flag away and the measurement is on record rather than assumed. Operator gains manifold, divisions, fixed_fov. README and PROFILE.md corrected where they repeated the boundary-edge claim. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
m3ultra
|
516e3e4457 |
Mesh cleanup: weld, strip floaters, iterative decimation
The raw cascade output is ~4M verts / 8M faces and is not usable as-is. cleanup.py is ordinary mesh hygiene, kept out of the model code, and the ORDER is the whole point: weld -> strip floaters -> decimate -> strip again -> fix normals CORRECTION TO THE FLOATER COUNT. The health pass reported 52,855 components with 52,838 fragments under 100 faces, and I took those for stray shells. They were mostly NOT: the decoder emits per-voxel vertices, so coincident corners are duplicated and the same continuous surface reads as tens of thousands of islands. Welding FIRST collapses it to a single component, and only 6,332 faces are genuinely stray. Ordering the pass the other way round removes 250k faces of real geometry and calls it cleaning. Two performance fixes, both because an operator runs this every job: - Component labelling is a scipy union-find over the VERTEX graph, not trimesh.face_adjacency. Same answer, ~240s -> ~1s on this mesh. - fix_normals runs LAST, on the decimated mesh. It walks face adjacency, so on the raw 7.99M-face mesh it costs minutes and the result is then thrown away by decimation. Cleanup went ~243s -> ~20s. Decimation is iterative. A single fast_simplification call will not reduce past roughly 4.4% of its input whatever target_reduction (or agg) is asked for: from 7.99M faces, targets of 200k, 50k and 20k ALL returned 351,535. Repeated smaller passes get further because each re-evaluates quadrics on the collapsed mesh. MEASURED, on the sample: target 500,000 -> 499,984 faces silhouette IoU 0.965 19.3s target 200,000 -> 214,322 faces silhouette IoU 0.823 34.8s target 100,000 -> 214,322 faces silhouette IoU 0.823 target 20,000 -> 214,322 faces silhouette IoU 0.823 HONEST LIMITATION: ~214k is a hard floor, and reaching it costs real fidelity (0.965 -> 0.823). The cause is the ~180,000 BOUNDARY edges the Flexible Dual Grid produces for open surfaces - quadric decimation will not collapse those, and no aggressiveness setting changes it. Below ~214k needs a REMESH, not a decimator. 500k is effectively lossless and is the setting to use; anything under 214k is not currently reachable and the loop stops rather than spinning. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |