Better fix than rBbef5cb3aa2e5a: consider edges between faces with opposed normals as sharp.
In fact, previous code was broken more deeply in this case (inconsistent normals across
a 'smooth fan') - some loop normals would even never be computed!
Fixing this is possible (even wrote it, actually), but this adds more complexity
to a piece of code that is already awfully complicated, *and* normals in that kind
of smooth fan do not make much sense anyway. So simpler and nicer results with
assuming sharp edges between such 'opposed' faces!
Note that there is some face (loop) ordering black magic at work here, added more comments
to try to explain how and why all this works.
As a bonus, we do not need to check for already computed loop normals anymore, since we
know each 'smooth fan' will be walked once, and only once.
Turned out there was still quite a few cases were indices were set dirty,
but elem_index_dirty was not tagged accordingly (mostly for BM_LOOP,
but a few others as well). So probably this crash was not the only one
hidden here.
Hopefully all possible cases were catched this time!
This updates the fix in rB27db75363, which had to be undone
because it broke other bevels.
It also fixes cases where edges went away went doing vertex
bevel on vertices with some wire edges.
Undoing nodes that do not belong to the current object will cause the
saved bmesh log entry to be reverted instead. This entry can belong to
another object though.
This is easy to fix by enforcing name matching (this was borrowed by
edit mode but can definitely be improved) between current object name
and undo node name and deleting older entries.
However there are complications. Deleting dyntopo entries in this way
can leave a brush stroke as first dyntopo log entry. This can present
issues if we attempt to delete that entry since it's deleted mesh
elements may now have had their ids (which would still be valid at the
time) cleaned up. This can result in crashing if we attempt to resculpt
on the mesh. To fix this I have disabled releasing the deleted entries.
This entanglement between bm_log and undo is quite volatile but I hope
the system works better now.
Also minor cleanup, fix unneeded check warning
We need to support cutting degenerate ngons, see: T39418
This commit disallows cuts across faces where the same vertices can create better cuts on different faces.
The test for wire edges when reattaching was wrong, because
some newly made edges are wire at the point of the test.
This made some duplicate edges.
Need to track the original wire edges a different way.
Now code explicity excludes wire edges from beveling
and reattaches the wire edges to one of the newly
created vertices after beveling.
Also fixes a bug where vertex-beveling a wire-edge-only
vertex would not reattach the wire edges.
It shouldn't create issues in practice because modified face ids should
have been reclaimed from an added face on a previous entry, but add for
completeness.
- BLI_ghashutil_strhash_n takes string length, to avoid terminating the string before hashing.
- BLI_ghashutil_inthash/uinthash take ints, to avoid casting to (void *)
This also showed up incorrect use of inthash, which was using a pointer.
* Merely a re-implementation of core split algorithm for BMesh, taking advantage of topological data available.
* This code needs valid loop indices, so added BM_LOOP support to BM_mesh_elem_index_ensure() & co.
Reviewers: campbellbarton
Reviewed By: campbellbarton
CC: brecht
Differential Revision: https://developer.blender.org/D366