| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
While it sounds useful, in practice it was rather causing
extra overhead and was slowing things down.
|
|
|
|
Original fix was assuming that particle init operation is updated on every
frame, which is wrong behavior and that was fixed in previous commit to the
original bugfix.
|
|
The idea is to de-duplicate logic in DEG_id_tag_update() and flushing where we
need to translate depsgraph tag or component type to ID level recalc flag.
Currently unused, but is required for Blender 2.8.
|
|
Not only this helps merges form master to the branch, but also:
- Allows us to production-check changes as soon as possible.
- Avoids some unnecessary editors update about ID changes.
- Adds small optimization on queue size by always keeping one of the pointers
outside of the queue.
|
|
|
|
|
|
The idea is to allow iterating over ID nodes in exact order of their
construction, and in order which will not change dependent on memory
pointers or anything.
|
|
|
