Issue was caused by MFACE layer adding for even DM without tessellated faces
which lead to adding new layer but with NULL data. This causes issues when layer
with faces (after extrude) was attempting to add because currently CD only checks
if layer type exists but does not check for size of the layer.
Solved by not adding MFACE layer if there's no tessellated faces.
which resolves some possible issues with operating files with quotes and backslashes.
Also this might resolve (or at least help) resolving compilation error on GNU Hurd platform
which will help a lot maintaining Blender for Debian.
This idea is borrowed from the multires modifier, which already
checked if the object was in sculpt mode and, if so, created the
PBVH. That check is now moved higher up the chain into
mesh_build_data(), so that it occurs for CDDerivedMesh too.
This also replaces an assert in cdDM_getPBVH for tesselated mesh faces
with a call to create them if missing.
Vector.angle_signed(other)
for 2D vectors to get the clockwise angle between them.
in BLI math its called - angle_signed_v2v2()
shorthand for...
atan2f((v1[1] * v2[0]) - (v1[0] * v2[1]), dot_v2v2(v1, v2))
also corrects compile error in last commit.
Fix this by storing if the border is set - before this was only done for the window dimensions.
also move these variables into a static struct so this logic is easier to follow.
the problem was numeric precision when in ortho mode the start/end points for the view vector would be 2000 apart which caused trouble for the intersection test.
No functional changes, this is just a bit easier to read I think (and
nicer if we add more PBVH types in the future, e.g. for dynamic
topology sculpting.)
Renamed the multiresModifier_update() function to
multires_modifier_update_mdisps() and made it visible to subsurf_ccg.c
so it can be called directly. No functional change, just a bit simpler.
problem was bow-tie quads would add opposite normals together and result in zero vector which was used for projection.
Now is_quad_convex_v3() checks if quad contains 2 faces which point away from eachother when split by either direction.
Theres another fix for this bug which can be done since creating the face can use existing edges in the example given so it wont have to guess which order of verts to use.
Update handles positions after applying modifiers which seems to be expected behavior.
The only currently unsolved issue is about updating aligned handles because this needs
to determine in which order handles need to be recalculated which currently depends on
selection flags and which is quite tricky to do when running modifiers and animation data,
so currently just not update their positions for now.
Was missed check for if modifier is available for particular object type
which ended up with unpredictable results when modifier which isn't supported
yet for some object type as linked to that object type.
This is in preparation for bug fixing and cleanup related to tracking
of bmface and is_space state variables. And makes it more likely
to avoid bugs in future where some part of state is copied but not all.
Sometimes split would fail to make a face - make sure it doesn't
crash if that happens.
Chain finding code for holes would sometimes go back to same
vertex on the face, which causes problems, so fixe that.
Also, disallowed a cut that starts at a vertex or edge and
cycles back to that same point in a face - this would make
a face with a repeated vertex, which may not be handled by
the rest of the system properly.
- edgebisect bmesh operator used uninialized beauty field.
- BLI_join_dirfile could read from before the string bounds when passed an empty dir string.
- pransform could use an uninitialized projected coordinate (unlikely but possible)
- RNA_property_path_from_ID_check would compare against an uninitialized pointer when the path wasn't found.
also have bmesh walker use BM_edge_other_vert() utility function.
