This simply adds a third "translation type" (in addition to iface and tip), "new data", with relevant user settings flag and helper funcs/macros (and py api).
Currently implemented name translation when adding new objects, as well as modifiers and constraints, will add the others (cd layers, scenes, perhaps nodes [though I think they do not need this], etc.) later.
check if the object is already parented to said deformer before trying to add a
new modifier
This should help reduce the number of cases where users inadvertantly end up
creating multiple deform modifiers pointing to the same object, which has been
known to be a cause of "double-transform" artifacts.
Note that this is only able to detect these cases by checking if the parent
object is selected, so this will only really work for the Ctrl-P shortcut where
you have to select both objects first. However, it shouldn't be a problem either
in the Outliner (drag and drop), as the object probably won't be a child of its
parent already if you're doing this.
Change modifier_sameTopology() to not not treat Nonconstructive
modifiers as having same topology. This function is only used to test
whether Apply as Shape is allowed.
The exact nature of "nonconstructive" modifiers is not documented, but
current list is remesh, fluidsim, decimate, mask, build, and
boolean. All of these modify topology, and should not be making making
shape keys.
As far as I could tell, these were really only still used for "virtual
modifiers", though we really don't use these anymore. Instead, most of the time,
people need to set these settings in armature modifiers directly (these didn't
even get copied over in that case). This was a source of confusion and
redundancy, so removing these now.
This change can be reverted if these were actually of some use out there...
User side:
* Preview for DynamicPaint should keep the same behavior (for now). Weight preview should be somawhat quicker, though.
* Preview for WeightVG modifiers is only active in WeightPaint mode, and if the affected vgroup is the active one.
* Last active preview modifier in stack wins!
Note: that modifier preview topic is yet to be further refined, quite raw/incomplete for now.
Dev side:
* In draw code, renamed DRAW_DYNAMIC_PAINT_PREVIEW flag to DRAW_MODIFIERS_PREVIEW
* Removed use of MOD_DPAINT_PREVIEW_READY in DynamicPaint code (seems unecessary, and if it was, should be of more general scope).
* Added eModifierTypeFlag_UsesPreview to ModifierTypeFlag, for modifiers that can generate some preview data.
* Added three new modifier funcs, to handle preview modifiers in draw code / mod stack.
* For weights preview: added the generic DM_update_weight_mcol func, which can update WEIGHT_MCOL layer with either a given array of weights (currently used by DynamicPaint only), or from current active vgroup(s).
So now, draw code is fully generic (i.e. no more modifier-type checking in it). Mod stack code is generic to some extent, but will need more work.
Also, allow applying to obdata those modifiers, even with shapekeys, but do not allow applying them *as* shapekey (as shapekeys do not have CD layers).
Fix [#29636] Vertex Weight Mix modifier "apply" button don't work.
Note: applying whit shape keys currently always uses base shape, not current one (for apply to obdata as well as apply to shapekey), but this is another topic...
- use NULL rather then 0 where possible (makes code & function calls more readable IMHO).
- set static variables and functions (exposed some unused vars/funcs).
- use func(void) rather then func() for definitions.
- modifier code was using sizeof() without knowing the sizeof the array when clearing the modifier type array.
- use BLI_snprintf rather then sprintf where the size of the string is known.
- particle drawing code kept a reference to stack float values (not a problem at the moment but would crash if accessed later).
An operator Error throws up a menu, a Warning only a flashy header print.
In mesh editmode the menus for simple failures got very annoying, like
"Already a face" for Fkey on a face.
Proposal is to use warning for contextual failures, like:
- wrong selection
- unsupported combination
- wrong modes
And use errors for cases you really need user attention, for example when
issues are invisble or potentially damaging work.
- Memory failures
- Files not found
List can grow in future :) let's test this for mesh now.
I'll tackle this for other ops later after review.
(Also changed: loopcut disabled when editmode shows deformed result)
Fixed bug #23657, "Modifiers dosen't work when you select diffrent mesh for object"
Multires modifier now adds empty mdisps if they're missing, rather than displaying a warning
Switching an object's mesh will now check for a multires modifier; if found the modifier's total number of levels are reset to match the mesh's mdisps
Switching the mesh also forces a multires update so that sculpted changes aren't lost
Previously all modifier operators relied on the buttons layout data context pointer to
decide which modifier to work on. This meant that these operators would only work
from from the properties panel, and not from scripting/macros or for operator redo.
This commit makes all modifier operators take the modifier name as an operator
property, so the operators can be re-done or executed outside of the modifier panel.
When invoking the operators from the modifier panel, they automatically fill in the
operator property from context.
This isn't a perfect API design, but it does bring these operators in line with the design
of being able to access all UI functionality via other means like scripts.
