| Age | Commit message (Collapse) | Author |
|---|
|
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 :)
|
|
This is mainly to make physics modifiers being able to work
with it. For other cases this main is not needed.
|
|
|
|
Opted to keep includes if they are used indirectly (even if removing is possible).
|
|
|
|
|
|
|
|
a hash from the object name.
|
|
refcount ;)
|
|
|
|
|
|
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.
|
|
checking >= 0.
also remove unused bmesh decimator code.
|
|
to pass options, instead of having one parameter per boolean flag (i.e. replaces current useRenderParams and isFinalCalc by a single ModifierApplyFlag flag. ModifierApplyFlag is an enum defined in BKE_modifier.h). This way we won't anymore have to edit all modifier files when e.g. adding a new control flag!
Should have no effect over modifier behavior.
|
|
|
|
|
|
properly in animation rendering.
|
|
else if's
|
|
this layer is now also used for various preview tasks in Object mode.
“Cleanup” commit, no functional changes.
|
|
Noted preview code for DynamicPaint is currently disabled, will see if I can re-enable it…
|
|
|
|
of how modifiers can generate preview.
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!
|
|
|
|
CustomData layers only (e.g. UVProject and WeightVG ones).
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...
|
|
|
|
the CD_DEFORMVERT data layer (if it's the org one), and not the whole DerivedMesh!
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)...).
|
|
|
|
http://markmail.org/message/fp7ozcywxum3ar7n
|
|
|
|
|
|
|
|
MDeformWeight** parameter (to avoid another vgroup searching).
Also added to Proximity a check in case vgroup would have no vertices in it.
Plus a few minor edits...
|
|
* 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!).
|
|
MDeformWeights be searched only once.
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!
|
|
|
|
|
|
|
|
|
|
- WeightVG -> Vertex Weight
- mapping_mode -> falloff_type
- nicer layout for VertexWeightModifiers add/remove options
|
|
|
|
*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.
|
|
if the string is set: == NULL will never be true.
- 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.
|
|
- dont allow negative min distances
|
|
- init proximity to 1.0f
- min/max proximity dist were not being copied.
- minor edits to comments - use ascii chars in a few places.
|
|
in WeightVGEdit mod, including from DNA struct.
|
|
mapping/clamping options in WeightVGEdit mod, leaving the only curve mapping stuff.
Also, updated all three modifiers with new foreachTexLink walking func.
|
|
weightvg_util.c.
It seems WeightVG modifiers can’t enable the eModifierTypeFlag_SupportsMapping flag...
|
|
- use an rna enum-set for proximity vert/edge/face options.
- rename some flags.
- better conform to rna naming conventions.
|
