| 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 :)
|
|
matching convention for fixed length api, eg: copy_v3_fl
|
|
'tot_length / step_length' gives the number of 'segments', not the number of
copies - we have to add 1 here.
|
|
This is mainly to make physics modifiers being able to work
with it. For other cases this main is not needed.
|
|
|
|
|
|
|
|
Thanks to @PatB for the fix.
|
|
We messed up previous fix, in 'simplified' translated merge case... :(
|
|
Gah... Dirty normal flag should be set on *real* final dm, after merge is done. :/
|
|
Array with rotation and a central pivot would fail.
Thanks to Bastien Montagne for the initial fix.
|
|
offset-corrected.
This is not needed when we tag normals as dirty, but in simple cases, if offset has some
rotation (or non-uniform scaling) component, vertex normals has to be corrected.
|
|
after the Edge Split Modifier added.
Dirty normals flag has to be passed to new dm...
|
|
Patch by PatB with own edits
- replace BMesh with CDDM functions.
- faster remove-vertex merging.
- extend CDDM_merge_verts to be more flexible.
|
|
Importantly, reversed mul_serie_m3 argument order (so it matches the m4 function)
|
|
NULL's)
|
|
Opted to keep includes if they are used indirectly (even if removing is possible).
|
|
* Merely a re-implementation of core split algorithm for BMesh, taking advantage of topological data available.
* This code needs valid loop indices, so added BM_LOOP support to BM_mesh_elem_index_ensure() & co.
Reviewers: campbellbarton
Reviewed By: campbellbarton
CC: brecht
Differential Revision: https://developer.blender.org/D366
|
|
|
|
Issue was caused by undefined object update order and in some
cases NULL pointer will be de-referenced.
Added on-demand curve path calculation, just the same creepy call
of BKE_displist_make_curveTypes(). This violates DAG and might
end up in a difficult to troubleshoot race condition if there'll
be some issues with how dependencies are calculated in DAG, but
this is the easiest and safest way to solve the bug at this stage,
|
|
|
|
to true/false in code using them).
|
|
First of all, it was needed to have that set scenes fix which
was done recently so curve is being evaluated properly on file
load.
And last but not least, also needed to tag DAG node to evaluate
path regardless to curve datablock settings so curve length is
always known.
|
|
Summary:
Made objects update happening from multiple threads. It is a task-based
scheduling system which uses current dependency graph for spawning new
tasks. This means threading happens on object level, but the system is
flexible enough for higher granularity.
Technical details:
- Uses task scheduler which was recently committed to trunk
(that one which Brecht ported from Cycles).
- Added two utility functions to dependency graph:
* DAG_threaded_update_begin, which is called to initialize threaded
objects update. It will also schedule root DAG node to the queue,
hence starting evaluation process.
Initialization will calculate how much parents are to be evaluation
before current DAG node can be scheduled. This value is used by task
threads for faster detecting which nodes might be scheduled.
* DAG_threaded_update_handle_node_updated which is called from task
thread function when node was fully handled.
This function decreases num_pending_parents of node children and
schedules children with zero valency.
As it might have become clear, task thread receives DAG nodes and
decides which callback to call for it.
Currently only BKE_object_handle_update is called for object nodes.
In the future it'll call node->callback() from Ali's new DAG.
- This required adding some workarounds to the render pipeline.
Mainly to stop using get_object_dm() from modifiers' apply callback.
Such a call was only a workaround for dependency graph glitch when
rendering scene with, say, boolean modifiers before displaying
this scene.
Such change moves workaround from one place to another, so overall
hackentropy remains the same.
- Added paradigm of EvaluaitonContext. Currently it's more like just a
more reliable replacement for G.is_rendering which fails in some
circumstances.
Future idea of this context is to also store all the local data needed
for objects evaluation such as local time, Copy-on-Write data and so.
There're two types of EvaluationContext:
* Context used for viewport updated and owned by Main. In the future
this context might be easily moved to Window or Screen to allo
per-window/per-screen local time.
* Context used by render engines to evaluate objects for render purposes.
Render engine is an owner of this context.
This context is passed to all object update routines.
Reviewers: brecht, campbellbarton
Reviewed By: brecht
CC: lukastoenne
Differential Revision: https://developer.blender.org/D94
|
|
|
|
|
|
Unless I'm missing something here (probably with regards to parenting),
it makes more sense that constraint results are considered here as well
(for example, if Limit Scale constraints get applied on the object),
as this allows for greater flexibility when creating setups with this.
|
|
|
|
values can be stored in the ghash directly.
saves 24 bytes per element (per vertex/edge/face on a 64bit system), for bmesh operators.
|
|
this is supported by weldop but would prefer not to allow multiple keys in the map.
|
|
I know this is not so much nice to have this guys hanging
around in a general Object datablock and ideally they better
be wrapped around into a structure like DerivedMesh or
something like this. But this is pure runtime only stuff and
we could re-wrap them around later.
Main purpose of this is making curves more thread safe,
so no separate threads will ever start freeing the same path
or the same bevel list.
It also makes sense because path and bevel shall include
deformation coming from modifiers which are applying on
pre-tesselation point and different objects could have
different set of modifiers. This used to be really confusing
in the past and now data which depends on object is stored
in an object, making things clear for understanding even.
This doesn't make curve code fully thread-safe due to
pre-tesselation modifiers still modifies actual nurbs and
lock is still needed in makeDispListsCurveTypes, but this
change makes usage of paths safe for threading.
Once modifiers will stop modifying actual nurbs, curves
will be fully safe for threading.
Actually, this commit also contains wrapping runtime curve
members into own structure
This allows easier assignment on file loading, keeps curve-
specific runtime data grouped and saves couple of bytes in
Object for non-curve types.
--
svn merge -r57938:57939 ^/branches/soc-2013-depsgraph_mt
svn merge -r57957:57958^/branches/soc-2013-depsgraph_mt
|
|
add arguments to calculate normals when converting to bmesh:
BM_mesh_bm_from_me, DM_to_bmesh
This gives some speedup to undo (which didnt need to re-calculate vertex normals), and array modifier which doesnt need to calculate face normals at all
|
|
pass the dirty-normal-state from the input dm to the output.
|
|
many modifiers were calculating normals, when those normals were ignored by the next modifier.
now flag normals as dirty and recalculate for modifiers that set use `dependsOnNormals()` callback.
Quick test on mesh with 12 modifiers (mostly build type), calculated normals 6 times, now it only runs once - so this will give some speedup too.
|
|
- mult_m4_m4m4 -> mul_m4_m4m4
- mult_m3_m3m4 -> mul_m3_m3m4
these temporary names were used to avoid problems when argument order was switched.
|
|
mesh datablock went missing.
|
|
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.
|
|
|
|
|
|
|
|
avoid per vert/edge/face string lookups in BMO_slot_map_* functions --- used in array modifier, subdivide, remove doubles and other tools.
|
|
access to these as input arguments and return values.
all output values currently have ".out" suffix, this may go in the future, but for now it makes it clear in C code what are inputs and outputs.
|
|
get return values.
|
|
modifiers that dont use bmesh operators can skip allocating it.
|
|
|
|
|
|
is to respect hidden geometry.
this is useful for bmesh tools that operate in object mode or for modifiers which would previously use hidden faces in some cases.
|
|
|
|
|
|
|
