[MeshRefinement](AI) ADD the new InfinyToolkit.MeshRefinement plugin with the TetrahedronSubdivisionController that use the public API of MeshRefinement plugin - #61
Merged
Conversation
epernod
added
pr: new feature
pr: status to review
…public controller The public face of the MeshRefinement plugin, as its own dll. A scene requires InfinyToolkit.MeshRefinement and names TetrahedronSubdivisionController; the subdivision engine stays private to MeshRefinement, reached only through its TetrahedronSubdivisionManager facade. Laid out as a sub-plugin the way MeshRefinement.CUDA is, with its own config.h.in, init and factory registration. The controller moved here verbatim apart from what ownership requires: the export macro is SOFA_INFINYTOOLKIT_MESHREFINEMENT_API and the namespace is sofa::infinytoolkit, since a consumer writing C++ against it is writing against InfinyToolkit now. The engine handle is qualified as sofa::meshrefinement::TetrahedronSubdivisionManager, which is the only name it takes from the other plugin. Its 8 tests moved with it, into the plugin's own test target - InfinyToolkit had no test infrastructure before this. They still load their scenes from MeshRefinement/examples, since that is where the meshes are; the tests pass against the new dll, cut and refinement both. CudaSubdivisionController.cpp carries the Cuda instantiations that MeshRefinement.CUDA used to hold, for the reason it cannot hold them now: the controller is here, and MeshRefinement must not depend on InfinyToolkit. It compiles only when both SofaCUDA and MeshRefinement.CUDA are found, and links the facade instantiations the latter exports. NOT BUILT HERE: SofaCUDA is not enabled in this build tree, so the Cuda path is written from the interface and never compiled. It wants checking on a machine with CUDA before anyone relies on the two Cuda scenes.
MeshRefinement renamed its public boundary: the facade is MeshRefinementAPI and TetrahedronSubdivisionManager is now the private engine that the two managers were merged into. Everything on this side is an outside consumer, so all of it moves to the boundary - the sub-plugin's controller, and the two carving performers. The controller's header comment described the old arrangement, where cutting derived from subdividers and the point was that one manager answered both halves. That is now a single engine, so the comment says what actually matters to a reader here instead: the engine is private to MeshRefinement and this controller reaches it only through the one published header, which is why nothing in the header names an implementation type. InfinyToolkit.MeshRefinement's 8 controller tests pass, and Cube_AdvCarvingWithRefinement still reaches bwdInit and initialises the refine performer through the boundary with no warning.
epernod
force-pushed
the
dev_meshrefinement_facade
branch
from
September 11, 2026 13:37
96c87cf to
2f0ce91
Compare
… the code The comments carried a running account of how the component came to be - what it replaced, which key moved and why, why a type is aliased in the class rather than pulled in by a using, why the manager is owned rather than shared. None of that tells a reader what the class does today. What stays is the documentation: what each operation does and what it returns, what each Data means, the two-phase shape of cutting, and the key bindings the example scenes rely on. What goes is the history. Two facts worth keeping were rewritten rather than deleted, because they are about the current code and not about its past: the cut thickness is the tolerance for snapping points onto the plane, and refineTetrahedra range-checks its ids because the engine does not and an id past the end is read out of the tetrahedron array. Some wording carried over from the original controllers is corrected while these lines are being touched - "plan" for plane throughout the cut Data, "terahedra", "Booleen". Comments only. Verified by diffing with the trailing ///< text stripped: the six declarations whose doc comment changed are character-identical on both sides. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ry for its scenes
epernod
commented
Sep 13, 2026
epernod
left a comment
epernod
left a comment
Contributor
Author
There was a problem hiding this comment.
clean Claude comments
Co-authored-by: erik pernod <erik.pernod@gmail.com>
epernod
added
pr: status ready
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Need to be merged as the same time as:
https://github.com/InfinyTech3D/MeshRefinement/pull/39