This commit integrates the work done so far on the new dependency graph system,
where goal was to replace legacy depsgraph with the new one, supporting loads of
neat features like:
- More granular dependency relation nature, which solves issues with fake cycles
in the dependencies.
- Move towards all-animatable, by better integration of drivers into the system.
- Lay down some basis for upcoming copy-on-write, overrides and so on.
The new system is living side-by-side with the previous one and disabled by
default, so nothing will become suddenly broken. The way to enable new depsgraph
is to pass `--new-depsgraph` command line argument.
It's a bit early to consider the system production-ready, there are some TODOs
and issues were discovered during the merge period, they'll be addressed ASAP.
But it's important to merge, because it's the only way to attract artists to
really start testing this system.
There are number of assorted documents related on the design of the new system:
* http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents
* http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph
There are also some user-related information online:
* http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/
* http://code.blender.org/2015/03/more-dependency-graph-tricks/
Kudos to everyone who was involved into the project:
- Joshua "Aligorith" Leung -- design specification, initial code
- Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes
- Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the
project and so
- Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the
issues and recording/writing documentation.
- Everyone else who i forgot to mention here :)
A previous bugfix disabled the dynamic paint modifier for orco texture
coordinate evaluation of the modifier stack. However the MOD_APPLY_USECACHE
flag is not a good way to check if the modifier is evaluated for orcos.
Instead I've added a MOD_APPLY_ORCO flag. Also removed a bunch of
applyModifierEM callbacks, none of them served a purpose except for the
subsurf modifier.
generator with a local one. It's not thread safe and will not give repeatable
results, so in most cases it should not be used.
Also fixes#34992 where the noise texture of a displacement modifier was not
properly random in opengl animation render, because the seed got reset to a
fixed value by an unrelated function while for final render it changed each
frame.
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.
Problem was, if no vertices were ever added to one of the obect's vgroups, there is no CD_DEFORMVERT layer, even though there might be several valid vgroup indices... Odd no one noticed that earlier.
Many thanks to miikah for finding that bug!
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...
Quite oddly, for Proximity mod, this increases the performances of the apply func (about 20-25%, e.g. from 0.04 to 0.03 sec), but decreases the global framerate (e.g. in TEST_5 scene of testing file, I lose about 7%, from 4.6 to 4.3fps (open ATI driver)...).
* Added an optional array of MDeformModifier pointers, to avoid another search based on defgrp_idx.
* Split out "add/remove verts from vgroup" functions, preparing their move to deform.c (if their current form is validated!).
Also fixed a bug: when another set mode than "All Vertices" was used and resulting set of verts was empty, all vertices was used, instead of just returning org, unmodified data!
*Added Smooth/Sharp/Root/etc. mappings to WeightVGEdit modifier, in addition to custom curve one.
*Added Smooth/Sharp/Root/etc. mappings to WeightVGProximity modifier, without the custom curve one!
*Factorized the common mapping code into MOD_weightvg_util.
- was doing NULL checks on freeing memory in cases where the values were already accessed (blender would have crashed anyway), so remove the NULL checks.
- use deform.c api weight functions to replace inline weight lookups in some cases.
- change if checks in weightvg_do_mask() so its more obvious whats going on.
