This is a change I pulled from the property-search-ui branch,
where I have to use the list of tabs to search the inactive tabs
and it makes more sense to use the array directly.
It is also an improvement to have this fundamental code to the
properties editor in the editor code rather than an RNA callback.
There are no functional changes.
Differential Revision: https://developer.blender.org/D8368
The extra depsgraph relations that were added to prevent threading
issues during evaluation (rB4c30dc343165) caused a considerable slowdown
on complex scenes with many drivers (T77277, T78615). This commit
improves this as follows.
Only the following drivers are considered for execution serialisation:
- Drivers on Array elements, and
- Drivers on Boolean or Enum properties.
Relations between drivers of the same arrays are added blindly, i.e.
without checking for transitive or cyclic relations. This is possible as
other relations will just target the `PROPERTIES_ENTRY` or
`PROPERTIES_EXIT` nodes.
Checking whether a driver is on an array is first done by checking
`array_index > 0`, and then falling back to resolving the RNA path to an
RNA property and inspecting that.
The code also avoids circular dependencies when there are multiple
drivers on the same property. This not something that is expected to
happen (both the UI and the Python API prevent duplicate drivers), it
did happen in a file (F8669945, example file of T78615) and it is easy
to deal with here.
Reviewers: sergey
Subscribers: mont29
Comment update
This means that we delete all override properties except for those over
ID pointers *if* the assigned pointer matches the linked data hierarchy.
Then we reload affected datablocks.
Regression from d6cefef98f
This also fixes an unreported issue where finding an exact match
wasn't being detected for items that contained an ID prefix.
A simulation data block has an embedded node tree, which requires
special handling in a couple of places. Some of those places were
missing beforehand.
This also adds a relation to make sure that the simulation is evaluated
after animations on the embedded node tree are evaluated.
High quality emitters need to maintain state themselves. For example,
this it needs to remember when it spawned the last particle.
This is especially important when the birth rate is changing over time.
Otherwise, there will be very visible artifacts.
It is quite likely that other components of the simulation need their own
state as well. Therefore, I refactored the `SimulationState` type a bit,
to make it more extensible. Instead of using hardcoded type numbers, a
string is used to identify the state type. Also, instead of having switch
statements in many places, there is a new `SimulationStateType` that
encapsulates information about how a specific state is created/freed/copied/...
I removed the integration with the point cache for now, because it was
not used anyway in it's current state.
