Computation of hold blocks was done by storing ranges (with start and
an end, and likely overlapping) in a tree keyed only by the block start.
This cannot work well, and there even were comments that it is not
reliable in complex cases.
A much better way to deal with it is to split all ranges so they don't
overlap. The most thorough way of doing this is to split at all and every
known keyframe, and in this case the data can actually be stored in the
key column data structures, avoiding the need for a second tree.
In practice, splitting requires a pass to copy this data to newly added
keys, and the necessity to loop over all keyframes in the range being
added. Both are linear and don't add excess algorithmic complexity.
The new implementation also calls BLI_dlrbTree_linkedlist_sync for
its own needs, so the users of the *_to_keylist functions don't have
to do it themselves anymore.
Differential Revision: https://developer.blender.org/D3790
* Don't print on every frame evaluated. This was only needed
earlier to track the progress (and why things were taking so
long - answer, it was the Scene COW issue). Saves 50-100 ms
* Remove the extra calculation of the scene after evaluating
motion paths. This shouldn't be needed now with COW.
Saves about 20-30 ms
This commit makes the motion path calculations use the
new Depsgraph Filtering API to obtain a more streamlined
copy of the full scene dependency graph, allowing for
faster calculations (as less data needs to be evaluated
for each frame being baked).
For example, in 01_020_A.anim.blend from the Spring production
files, the time needed to calculate paths on several bones
on Autumn went from 39.84 seconds (!) down to 9.90 seconds!
Currently, this works by just replacing the depsgraph instance
passed to the motion path calculation function. This filtered
instance contains just the ID's needed to evaluate the graph
to evaluate a specified target (i.e. the Object owning the pose).
Notes:
* By default, the filtering is not performed unless debug mode 555
is activated. Having a debug switch here allows comparing
performance and disabling it should thing it start crashing.
* It is necessary to pass in the original Scene instance (not the
COW one owned by the filtered depsgraph), otherwise changing the
current frame had no effect, due to the COW flushing from original
Scene to the new Scene overwriting the CFRA changes we make.
* The code here still needs cleaning up to debugging instrumentation, etc.
and also to optimise further (e.g. caching the filtered depsgraph
for faster updates when animating on existing paths, or fine-tuning
the exact set of nodes needed). I'm just committing this first,
since this was the quickly hacked-together test code I've been using
to check that this is all working.
* Further improvements could also be made to the time needed to
build the full graph instance (about 3.3 sec), by allowing partial
builds (e.g. by making a filtering proxy/wrapper around existing builders)
This puts the motion path in the same location as the transform gizmo,
which is less confusing especially if you have a custom bone shape where
the tail is not visible.
Sometimes the evaluated pose channel pointers can change during depsgraph
evaluation, so we can't store them ahead of time. The object pointer
should be ok since evaluated ID memory is reused.
This commit restores support for Motion Path drawing in 2.8 (as it wasn't ported over
to the new draw engines earlier, and the existing space_view3d/drawanimviz.c code was
removed during the Blender Internal removal).
Notes:
* Motion Paths are now implemented as an overlay (enabled by default).
Therefore, you can turn all of them on/off from the "Overlays" popover
* By and large, we have kept the same draw style as was used in 2.7
Further changes can happen later following further design work.
* One change from 2.7 is that thicker lines are used by default (2px vs 1px)
Todo's:
* There are some bad-level calls introduced here (i.e. the actgroup_to_keylist() stuff).
These were introduced to optimise drawing performance (by avoiding full keyframes -> keylist
conversion step on each drawcall). Instead, this has been moved to the calculation step
(in blenkernel). Soon, there will be some cleanups/improvements with those functions,
so until then, we'll keep the bad level calls.
Credits:
* Clément Foucault (fclem) - Draw Engine magic + Shader Conversion/Optimisation
* Joshua Leung (Aligorith) - COW fixes, UI integration, etc.
Revision History:
See "tmp-b28-motionpath_drawing" branch (rBa12ab5b2ef49ccacae091ccb54d72de0d63f990d)
This commit brings back motion path calculations working on same level
as 2.7x. Caveats:
* You cannot actually see anything, as all the drawing code for motion
paths was removed and not reimplmented in 2.8 draw engines yet
* This doesn't actually use a separate depsgraph instance for fast
background calculations yet. That's a separate topic, and will require
further investigation (probably after code quest, according to original
planning).
* The work here *does* however pave the path forwards towards fully separate
COW evaluation though. We only need to stub in a different depsgraph instance
here to get things working.
The depsgraph was always created within a fixed evaluation context. Passing
both risks the depsgraph and evaluation context not matching, and it
complicates the Python API where we'd have to expose both which is not so
easy to understand.
This also removes the global evaluation context in main, which assumed there
to be a single active scene and view layer.
Differential Revision: https://developer.blender.org/D3152
The RenderResult struct still has a listbase of RenderLayer, but that's ok
since this is strictly for rendering.
* Subversion bump (to 2.80.2)
* DNA low level doversion (renames) - only for .blend created since 2.80 started
Note: We can't use DNA_struct_elem_find or get file version in init_structDNA,
so we are manually iterating over the array of the SDNA elements instead.
Note 2: This doversion change with renames can be reverted in a few months. But
so far it's required for 2.8 files created between October 2016 and now.
Reviewers: campbellbarton, sergey
Differential Revision: https://developer.blender.org/D2927
This is a final step of having proper ownership. Now selecting different
layers in the "top bar" will actually do what this is expected to do.
Surely, there are still things to be done under the hood, that will happen
in a less intrusive way.
This is a lots of changes, but they are boiling down to a simple API
changes where we are no longer relying on implicit usage of scene's
depsgraph and pass depsgraph explicitly.
There should be no user measurable difference, render_layer* tests
are also passing.
This needs to be re-implemented in a new fashion, without touching global list
of bases and become compatible with the new dependency graph.
The idea to go here would be to create new dependency graph for motion path
evaluation, bring a single object in there (which will pull all dependencies
at a construction) and use that.
Needs working copy-on-write first tho.
Note that some little parts of code have been dissabled because eval_ctx
was not available there. This should be resolved once DerivedMesh is
replaced.
These bits became obsolete with the new layer system, so we can
simplify some code around them or avoid existing workarounds which
were trying to keep things working for them.
There are still work needed to be done for on_visible_change to
avoid unnecessary updates, but that can also happen later.
Design Documents
----------------
* https://wiki.blender.org/index.php/Dev:2.8/Source/Layers
* https://wiki.blender.org/index.php/Dev:2.8/Source/DataDesignRevised
User Commit Log
---------------
* New Layer and Collection system to replace render layers and viewport layers.
* A layer is a set of collections of objects (and their drawing options) required for specific tasks.
* A collection is a set of objects, equivalent of the old layers in Blender. A collection can be shared across multiple layers.
* All Scenes have a master collection that all other collections are children of.
* New collection "context" tab (in Properties Editor)
* New temporary viewport "collections" panel to control per-collection
visibility
Missing User Features
---------------------
* Collection "Filter"
Option to add objects based on their names
* Collection Manager operators
The existing buttons are placeholders
* Collection Manager drawing
The editor main region is empty
* Collection Override
* Per-Collection engine settings
This will come as a separate commit, as part of the clay-engine branch
Dev Commit Log
--------------
* New DNA file (DNA_layer_types.h) with the new structs
We are replacing Base by a new extended Base while keeping it backward
compatible with some legacy settings (i.e., lay, flag_legacy).
Renamed all Base to BaseLegacy to make it clear the areas of code that
still need to be converted
Note: manual changes were required on - deg_builder_nodes.h, rna_object.c, KX_Light.cpp
* Unittesting for main syncronization requirements
- read, write, add/copy/remove objects, copy scene, collection
link/unlinking, context)
* New Editor: Collection Manager
Based on patch by Julian Eisel
This is extracted from the layer-manager branch. With the following changes:
- Renamed references of layer manager to collections manager
- I doesn't include the editors/space_collections/ draw and util files
- The drawing code itself will be implemented separately by Julian
* Base / Object:
A little note about them. Original Blender code would try to keep them
in sync through the code, juggling flags back and forth. This will now
be handled by Depsgraph, keeping Object and Bases more separated
throughout the non-rendering code.
Scene.base is being cleared in doversion, and the old viewport drawing
code was poorly converted to use the new bases while the new viewport
code doesn't get merged and replace the old one.
Python API Changes
------------------
```
- scene.layers
+ # no longer exists
- scene.objects
+ scene.scene_layers.active.objects
- scene.objects.active
+ scene.render_layers.active.objects.active
- bpy.context.scene.objects.link()
+ bpy.context.scene_collection.objects.link()
- bpy_extras.object_utils.object_data_add(context, obdata, operator=None, use_active_layer=True, name=None)
+ bpy_extras.object_utils.object_data_add(context, obdata, operator=None, name=None)
- bpy.context.object.select
+ bpy.context.object.select = True
+ bpy.context.object.select = False
+ bpy.context.object.select_get()
+ bpy.context.object.select_set(action='SELECT')
+ bpy.context.object.select_set(action='DESELECT')
-AddObjectHelper.layers
+ # no longer exists
```
New options to define the style of the animation paths in order to get
better visibility in complex scenes.
Now is possible define the color, thickness and several options relative
to the style of the lines used to draw motion path.
- Add blentranslation `BLT_*` module.
- moved & split `BLF_translation.h` into (`BLT_translation.h`, `BLT_lang.h`).
- moved `BLF_*_unifont` functions from `blf_translation.c` to new source file `blf_font_i18n.c`.
Issue was caused by cycles setting scene frame which will update scene for
all the layers (not just visible ones) which confuses depsgraph making
objects which are needed as dependency are not really evaluated.
Made it so setting frame via scene.frame_set() which check whether update
need to be flushed to an invisible objects and do this if so.
Not ideal solution but seems to be safest at this point.
This is a first step toward improving our dupli system. It implements a more
generic way of treating the various methods of dupli generation by adding a few
structs:
* DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists.
* DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c)
Beside making the code more easily understandable this implementation should
also help to avoid weird side effects from custom matrix hacks by defining
clearly what a generator does. The DupliContext is deliberately made const, so a
generator can not simply add hidden matrix or flag modifications that are hard
to track down.
The result container for the generated duplis is stored in the context instead
of being passed explicitly. This means the generators are oblivious to the
storage of duplis, all they need to do is call the make_dupli function. This
will allow us to implement more efficient ways of storing DupliObject instances,
such as MemPools or batches. These can be implemented alongside the current
ListBase so we can improve dupli bottlenecks without having to replace each and
every dupli use case at once.
Differential Revision: https://developer.blender.org/D189
This solves threading conflict which happens when having
multiple objects using Curve Deform modifier with the same
curve datablock. This conflict was caused by the fact that
curve_deform_verts() used to temporary override curve's
flags to make it path is there.
Actually, it was setting CU_FOLLOW flag temporary which
was only used where_on_path() (only in terms that this
temporary assignment only affected this function) but it
is now commented out for a while, so no reason to set
this flag temporary, If it's ever to be done, we'll need
to pass flags as an additional function argument.
For the path creation i've extended DegNode structure
which now holds extra bits which indicates what additional
data depending on the graph topology is to be evaluated.
Currently this is only used to indicate that curve needs
path to be evaluated regardless to cu->flag state. This
is so Curve Deform modifier is always happy.
In the future this flag might also be used to indicate
whether bmesh verts are to update (see recent commit to
3-vertex parent crash fix) or to indicate that the object
is the motherball etc.
This goes back to ancient era again and such a call isn't
safe for threading and really DAG is to make it sure display
list for dependencies is always there.
