| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Makes it easier to add or remove fields needed to update relations.
|
|
This allows us to:
- Not mock around with tags stored in a global space,
and not to iterate over all datablocks in the database
to clear the tags.
- Properly deal with datablocks which might not be in main database.
While it sounds crazy, it might be handy when dealing with preview,
or some partial scene updates, such as motion paths.
- Avoids majority of places where depsgraph construction needed bmain.
This is something what could help in blender2.8 branch.
From tests with production file here did not see any measurable slowdown.
Hopefully, there is no functional changes :)
|
|
Currently unused, actual logic change will come in the next commit.
|
|
Was printing some tagging/evaluation prints when only building
messages were requested.
|
|
|
|
|
|
Not sure why we need a relation from solver to a tip local transform, this
will be handled via parent relation.
Fixes remaining dependency cycles reported in T54083.
|
|
It is not possible to address transform at particular position of constraint
stack, and when constraint is being addressed is usually from driver variable.
This fixes some of dependency cycles reported in T54083.
|
|
Now it's possible to have debug messages for following things:
- Graph construction
- Graph evaluation
- Graph tagging
|
|
Handy to quickly see if a fix fixed any of the cycles in a real rig,
or whether it's introduced new ones.
|
|
- When returning the number of items in a collection use BLI_*_len()
- Keep _size() for size in bytes.
- Keep _count() for data structures that don't store length
(hint this isn't a simple getter).
See P611 to apply instead of manually resolving conflicts.
|
|
This is kind of doesn't matter where macro itself is defined.
We should stick to the following:
- If some macro is actually more an inline function, follow regular
function name conventions.
- If macro is a macro, type it in capitals. Use module prefix if that
helps readability or it if helps avoiding accidents.
|
|
Synchronize code in on_visible_update with depsgraph building.
Need to update all cameras, since they might be hooked up to marker.
|
|
|
|
The reason it appeared working was due to left-over debug code to force
time dependency.
Real fix seems to include force tagging objects used by duplication,
similar to what we do for some other modifiers already.
|
|
Was happening when viewport visibility on the particle system is disabled.
This became an issue after c45afcf, but the actual issue goes a bit deeper
and the following aspects were involved:
- Relations builder for particle system was ignoring particle system if
it's visibility is not enabled for viewport. This is something what
shouldn't have been done -- depsgraph relations are supposed to be the
same no matter if it's viewport or render.
- Relation builder was only dealing with duplication set to object, but
was ignoring group duplication.
This is technically a regression in 2.79a-RC as well, so would need to
backport this fix to the branch after extra testing is done here in the
studio.
|
|
Original fix only worked when there is one custom property.
|
|
|
|
This code was disable a while back and got re-enabled by some previous debug
process. Having relation names in dot file helps understanding what's going
on in one cases, but makes things spread too far away in others.
|
|
|
|
The new depsgraph was only considering the active action
when attaching relations from the AnimData component/operation
to the properties that are affected by the animation data.
As a result, only properties animated by the active action
were working, while those animated by NLA strips did not change
when playing back/scrubbing the timeline.
This commit fixes this introducing a recursive method to properly
visit all NLA strips, and calling DepsRelBuilder::build_animdata_curves_targets()
on each of those strips.
|
|
LinkList's are a different API, no need to confuse things.
|
|
One thing i'm not fully happy with is all this is_same_* functions. Need to
get rid of this by probably adding explicit entry/init/whatever nodes and
maybe making node criteria aware of whether key will be used as "from" or
as "to" node.
|
|
There was a fake cyclic dependency happening when node of node tree is driving
another node of the same tree.
This is related to T53794, but more fixes is needed here.
|
|
|
|
same bone
|
|
|
|
|
|
Helps in cases of not very complex scenes and lots of system threads available.
A bit hard to measure change on it's own, it works best with the upcoming
changes and gives measurable improvements.
|
|
|
|
Those pointers are never to be aliased, so let's be explicit about this and hope
compiler does save some CPU ticks.
|
|
Now all the fine-tuning is happening using parallel range settings structure,
which avoid passing long lists of arguments, allows extend fine-tuning further,
avoid having lots of various functions which basically does the same thing.
|
|
Wrap all arguments into TLS type of argument. Avoids some branching and also
makes it easier to extend things in the future.
|
|
|
|
Makes log easier to read.
|
|
This statistics is only collected when debug_value is different from 0.
Stored in depsgraph node itself, so we can always have access to average data
and other stats which requires persistent storage. This way we also don't waste
time trying to find stats from a separately stored hash map.
|
|
We might implement other things to dump into graphviz, so better to
start having explicit names.
|
|
|
|
|
|
|
|
it is only to be implemented for operation node.
|
|
No real reason to have that, better to free up space for something much more
awesome!
|
|
|
|
|
|
This needs to be redone anyway, to correspond to possibly new priorities
calculated for evaluaiton.
|
|
|
|
This is something deliver form node type, there is no reason to try cache it
anywhere, especially since it's not used in any performance critical code.
Lighter weight dependency graph is what we want.
|
