From recent experience, turns out we often do want to use something else than basic
range of parallelized forloop as control parameter over threads usage, so now BLI func
only takes a boolean, and caller defines best check for its own case.
Also, fix own stupidity, no need to define ID callback in case we only have objects,
calling code knows to fallback to `foreachObjectLink()` when `foreachIDLink()` is missing...
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!
- in the case of deform modifiers this is very safe (assuming the mods themselves dont need tessface data), since the DM is freed right after, so this is an easy speedup.
- in the case of bevel and split edge modifiers this should still work out fine since mods that need tessface data will generate it.
