Fantastic!
Adds Edge-Halfedge, Edge-Vertex, and Edge-Face circulators (and corresponding circulator ranges). These are especially useful in combination with smart ranges and their associated functional programming style. For example:
int valence_after_collapse(SmartEdgeHandle _eh)
{
return _eh.vertices().sum([&](auto _vh) { return _vh.valence(); }) - 2;
}
Their iteration behaviour is defined as follows:
for (auto heh : eh.halfedges()) {
// ...
}
is the same as
for (int i = 0; i < 2; ++i) {
auto heh = eh.halfedge(i);
// ...
}
for (auto vh : eh.vertices()) {
// ...
}
is the same as
for (int i = 0; i < 2; ++i) {
auto vh = eh.vertex(i);
// ...
}
for (auto fh : eh.faces()) {
// ...
}
is the same as
for (int i = 0; i < 2; ++i) {
auto fh = eh.halfedge(i).face();
if (fh.is_valid()) {
// ...
}
}
One additional change was adding a default argument to PolyConnectivity::halfedge_handle
, i.e.
mesh.halfedge_handle(eh)
is now equivalent to
mesh.halfedge_handle(eh, 0)
This greatly simplifies the implementation of the Generic Circulator, which can now call halfedge_handle()
on any center element type to obtain a starting halfedge.
One column of whitespace (and a -
) too much next to the 0.
Have you considered adding a halfedge_handle(EdgeHandle _eh)
method (or a default value for the second parameter of the halfedge_handle(EdgeHandle, int)
one). Maybe that would have simplified the implementation?
Max Lyon (9dfced6d) at 27 Feb 13:26
Max Lyon (14c973f4) at 22 Feb 12:12
Write custom properties to file by default
Max Lyon (250210e2) at 22 Feb 10:59
Merge branch 'lyonm/custom-property-writing' of https://www.graphic...
... and 1 more commit
I'm not quite sure I understand what you are saying. With the proposed changes still only persistent properties are written. However, so far, they were written independent of whether the CUSTOM flag was set or not. Now, CUSTOM needs to be part of the option in order to actually write the persistent properties. I agree that this would be a breaking change. I can make it so that CUSTOM is part of the DEFAULT options, which would at least keep the current behavior where people are using DEFAULT (either explicitly by passing DEFAULT, or implicitly by not passing any options). But for those who were using other flags without explicitly specifying CUSTOM but also relied on the fact that custom properties are written anyway, this would still be breaking. Would you be ok with that?
Max Lyon (7f3e219b) at 08 Feb 12:56
add missing OpenMesh:: namespace
Max Lyon (ebb000e1) at 08 Feb 09:25
add IO::Options::Custom to reading and writing in unittests_tutoria...
Max Lyon (4d760373) at 06 Feb 15:50
Merge branch 'master' into lyonm/custom-property-writing
... and 49 more commits
Max Lyon (e097a50a) at 06 Feb 09:11
only write custom properties if the Custom option is set
Max Lyon (172ab59f) at 03 Feb 14:43
Max Lyon (8005fadc) at 03 Feb 14:42
Max Lyon (8005fadc) at 03 Feb 11:19
Merge branch 'master' into lyonm/merge-from-ReForm
... and 5 more commits