- Read-only access can often use EvaluationContext.object_mode
- Write access to go to WorkSpace.object_mode.
- Some TODO's remain (marked as "TODO/OBMODE")
- Add-ons will need updating
(context.active_object.mode -> context.workspace.object_mode)
- There will be small/medium issues that still need resolving
this does work on a basic level though.
See D3037
Made shape keys to work for meshes. Also added missing code for curves.
Curves and lattices will not have shape keys visible, since modifiers support
is still to be done for them.
It is possible to have non-NULL scene in graph which was never built yet,
this happens when ID is tagged for update for non-built graph.
Was causing crash opening deg_anim_pose_bones.
Reported by Mai in IRC, thanks!
This fixes an issue where old cache data was used after an object has been moved.
Particles were coming from very wrong positions. Reproduction case is to move an
object while animation is running and then let the animation loop back and
play again.
Differential Revision: https://developer.blender.org/D3044
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.
Cycles old behaviour is to hide the duplicator on rendering at all times.
We have since a few months an option in 2.8 to control the duplicator
visibility on its own. However when the duplicator is also duplicated, things
were not working properly.
What we do now is, in addition to the duplicator visibility control, is to not
have the source collection of the duplicator object to ever influence its
visibility when the object is been duplicated.
So if the user wants to reproduce Cycles old behaviour all that is required is
to have different collections, one for the original to-be duplicated objects
that you hide in for the view layer used in the final render. And another
collection with only the first duplicator (which in turn duplicates other
duplicators).
I know this all may sound confusing, so please just give it a try, it's simpler
than it sounds.
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.
General idea of the fix: skip the whole draw manager callback madness which
was used to tag object's engine specific data as dirty. Use generic recalc
flag in ObjectEngineData structure instead. This gives us the following
benefits;
- Sovles mentioned bug report.
- Avoids whole interface lookup for opened viewports for EVERY changed ID.
- Fixes missing updates when viewport is temporarily invisible.
Reviewers: dfelinto, fclem
Differential Revision: https://developer.blender.org/D3028
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.
The issue was caused by Cycles allocating ID property in a temporary object
which gets overwritten and thrown away every so often.
Now dependency graph will try to reliably check whether ID properties from
a temp object are to be freed.
The issue here is that we can not duplicate the whole datablock since we
use view layer pointers in depsgraph callbacks.
Maybe this whole chunk of code belongs to somewhere else, or maybe we
can find a smart solution to avoid need of CoW pointers passed to the
evaluation functions.
This fixes lack of viewport update when toggling collection enabled flag.
Make sure scene and view_layer set for depsgraph before running editors
update. This is required since tagging might happen before we created depsgraph.
The issue was caused by some incompatibility of new API which expects ID block
to be specified explicitly, while old code is tagging object's data using
object's ID with OB_RECALC_DATA flag.
We need to switch all areas to give proper ID and everything, but for until
then we'd better stop crashing.
It is possible to have animation (or driver) to modify nested datablock, such
as shape key value for example (where animation is on Mesh level, but shape key
is it's own datablock). To deal with such cases we need to create relation
from nested datablock CoW to animaiton/driver operation.
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.
The issue was happening because dependency graph did not inform particle
settings as modified. This is a regression caused by tagging and flushing
mechanism refactor.
The real fix would be to make particle settings to use ID level recalc flags
rather than own flags, which will also simplify relations around particle system,
and particle settings evaluation.
Reported by Mai in IRC.
Before we were re-using newid pointer inside of ID structure where we were
storing pointer to an original datablock.
It seems there is no way we can avoid requirement of having pointer to an
original datablock, so let's stop obusing system which was only designed to
be a runtime only thingie. Will be more safe this way, without need to worry
about using any API which modifies newid.
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.
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.
