Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement full coherence validation #778

Closed
hannobraun opened this issue Jul 5, 2022 · 1 comment
Closed

Implement full coherence validation #778

hannobraun opened this issue Jul 5, 2022 · 1 comment
Labels
topic: core Issues relating to core geometry, operations, algorithms type: development Work to ease development or maintenance, without direct effect on features or bugs type: feature New features and improvements to existing features

Comments

@hannobraun
Copy link
Owner

The Fornjot kernel distinguishes between local and global representations of geometric and topological objects. Local representations are 1- or 2-dimensional (curve or surface coordinates) while global representations are always 3-dimensional.

To catch various mistakes, whether by the user or bugs in the code, the kernel does validation to check whether a shape (or part of a shape) is valid. One category of validation is called coherence validation. Coherence validation makes sure that the local and global representations within a shape match. This is currently not fully implemented.

As of this writing, all validation code lives in fj-kernel's validation module. Coherence validation is implemented in coherence.rs. It would be beneficial to have full coherence validation implemented for all objects.

Please note that it might make sense to shuffle some things around before/while implementing this. For example vertices (Vertex) currently don't refer to the curve they are on, but maybe they should (as opposed to Edge referring to that curve). Another idea is to split Curve into local and global variants, similar to Vertex/GlobalVertex. I'm not saying that these things need to be done as part of this issue. I just want to express that the current structure isn't fully solidified (and likely won't be for a long time), and that shuffling things around to aid with the implementation of this issue is perfectly acceptable.

@hannobraun hannobraun added type: development Work to ease development or maintenance, without direct effect on features or bugs topic: core Issues relating to core geometry, operations, algorithms type: feature New features and improvements to existing features labels Jul 5, 2022
@hannobraun
Copy link
Owner Author

Closing in favor of #1129.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: core Issues relating to core geometry, operations, algorithms type: development Work to ease development or maintenance, without direct effect on features or bugs type: feature New features and improvements to existing features
Projects
None yet
Development

No branches or pull requests

1 participant