now blenlib/BLI doesn't depend on any blenkern/BKE functions,
there are still some bad level includes but these are only to access G.background and the blender version define.
update the function to calculate the derived mesh with bmesh data-mask each time.
resolves bug [#33205] Bmesh "from_object" gives "no usable mesh data".
also found 'mesh_build_data' could run with non mesh objects and fail silently - add an assert.
reported as [#29376] BMESH_TODO: remove tessface CD_ORIGINDEX layer
for a single mesh there could be 3 origindex mappings stored, one on the polygons and 2 on the tessfaces.
(CD_POLYINDEX and CD_ORIGINDEX).
as Andrew suggests, now tessfaces (which are really a cache of polygons), using origindex to point to polygons on
the same derived mesh, and polygons only store the original index values.
It also changes multi-paint's "zero weight color" to black again--it was unintentionally changed to red some time late last year when an aspect of the colors were changed.
When in material display mode, mesh_calc_modifiers() calculates the
orco DerivedMesh, which uses a different CustomDataMask. In
particular, it does not necessarily include the current modifier's
requiredDataMask, so those layers might get set to NO_COPY. For the
skin modifier, this resulted in a crash when the modifier internally
copies the DerivedMesh and the output does not contain the expected
MVertSkin layer.
Fixed by adding the requiredDataMask to the orco DM's CustomDataMask.
Also added a debugging function to customdata.c:
customData_mask_layers__print(CustomDataMask mask);
This will print out the names of all the CD layer types in the mask.
Any identifier that looks like an OpenGL identifier, but isn't, causes a false alarm by the glreport.py tool. Most of these were in comments so I just rephrased the comments. There were a couple of static functions/macros that were easy enough to rename. Only the glTexco and glIndex fields of the DMVertexAttribs struct was public and had non-local uses.
Don't create empty tesselated faces layers in edit derivedmesh, these are
being created on the fly so this will conflicted, and use loop data for
opengl attributes for edit derivedmesh drawing.
In fact there were several issues fixed (all of them regressions since bmesh merge):
- Creating navmesh crashed because creating new faces for mesh was trying to set
default values for all customdata layers in this face. This requires memory
pool created for this datablock.
Usually this pool is creating on creating datablock if there're some elements
to be stored in this block. In cases of regular primitive creating it wasn't
an issue because they doesn't create customdata layers, they only creates
geometry.
Navigation mesh creates geometry and customdata layers (CD_RECAST layer)
which used to confuse a bit custom data functions. Solved by ensuring there's
memory pool created for polygons datablock after adding new custom data layer.
Most probably it's better to be resolved on CD level (like smarter track on
changed amount of stored data and so) but prefer not to make such global changes
so close to the release.
- Toggling edit mode lead to loosing recast datalayer. Solved by adding recast
layer to bmesh mask so it'll be copied to/from edit mesh.
- Some part of code assumed raycast layer is in face datablock, some that it's in
polygon datablock. Made it to be in polygons datablock.
Kind of temporary solution to make navmesh working, probably it'll fail if one
will want to edit navmesh by hand after it was generated.
Proper way would be to ensure the whole navmesh things are using ngons.
