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.
When ORIGSPACE is added, it is now a loop data, so we need to mark tessdata as dirty too. Also fixed DM_ensure_tessface to check DM_DIRTY_TESS_CDLAYERS flag!
This fixes problems with subsurf + dynapaint + particles, however, some modifiers, like remesh, seems to create a new dm from scratch, hence loosing completely those CD layers… Note this bug already existed in 2.62, so this is not a regression.
--debug
--debug-ffmpeg
--debug-python
--debug-events
--debug-wm
This makes debug output easier to read - event debug prints would flood output too much before.
For convenience:
--debug-all turns all debug flags on (works as --debug did before).
also removed some redundant whitespace in debug prints and prefix some prints with __func__ to give some context.
Should also fix [#30266], [#29451], and partly [#30316].
Here are the changes made by this commit:
* It adds a "dirty" flag to DerivedMesh struct (for now, only DM_DIRTY_TESS_CDLAYERS, but more might be added as needed).
* It adds a new func, DM_update_tessface_data, which assumes tessfaces themselves are valid, but updates tessellated customdata from their poly/loop counter parts.
* At end of modstack, when valid tessellated faces are present in finaldm , but the cdlayers dirty flag is set, call that function (instead of recomputing the whole tessellation).
* Edits to the codes concerned (UVProject, DynamicPaint, and Subsurf modifiers).
* Also add to subsurf dm generation code the creation of a CD_POLYINDEX layer (mandatory for DM_update_tessface_data to work well, and imho all tessellated dm should have one).
Note: some pieces of old code are just #if 0’ed, will clean them later.
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.
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.
