Add option to compute topology based on corners only

[TheBB]

Currently the SplineModel classes determine object equality and orientations based on the whole controlpoint array. In some situations it may be prudent to allow for more varied objects to compare equal. This adds an interior keyword argument that, when set to false, only compares the corner points (actually, the corner control points) to determine when one object is “equal” to another.

[TheBB]

Added a bugfix commit on this PR. If the first candidate node whose view() succeeds is to be returned, we can't wrap the whole loop in a single try. :-P

[VikingScientist]

How general is the topology part going to be? Here is my go at worst-case scenario which might be good to keep at the back of your mind during this:

Pawn mapping [00:30]

It is the mapping of a chess pawn piece and contains

• Faces degenerating to lines
• Faces degenerating to vertices
• Lines degenerating to vertices
• Periodicity in one parametric direction

all wrapped into a single NURBS patch. If you include periodicity, then the object has zero corners, and without periodicity it has 3 corners.

[TheBB]

I don't think anyone has set down any specifications for how general it needs to be. I can at least tell you about those cases, that it should do the following (i.e. if it doesn't, it's a bug):

• Degenerate objects will work in the following sense. A face degenerated to a line will still be understood to be a face, although two of its edges will be correctly identified to be identical (but they are not identical to the face itself). For two adjacent volumes, if the interface face (interface?) is degenerate, the bases in the degenerated directions will still need to match for the model to identify them as neighbouring.

• Periodicity is not explicitly supported. It is possible that periodic objects will work and that the model will contain an artificial face in your pawn, but I haven't tested that.

[VikingScientist]

I've uploaded some test cases for you to play around with. They are meant to cover

• 2D model (might be low tolerance for neighbourhood with this one)
• Large 3D model (1728 patches for scalability)
• Pawn model linked above
• Self-connection with swapped parametric direction
• Chess board just because it is fun

You can find them all on my branch

Thinking about this now, then I don't think it is necessary to cover periodicity in the topology parts of the code. We already have support for periodicity in the basis-function class, and I think should suffice. It means that the moebious box-example will not be supported at all, but I think we can live with that.

I am however curious as to how well you mange to pick up on connecting 4 different volumes on a single degenerate face (that is the F1 space on the Capablanca example). Is it assumed that an intersectionface can only be associated with two volumes?

[TheBB]

Thanks. I actually had some tests on this but I can't find them now. Fairly upset because they were not easy to write. :cry:

Is it assumed that an intersectionface can only be associated with two volumes?

No, that's not assumed.