The old layout of `PointerRNA` was confusing for historic reasons:
```
typedef struct PointerRNA {
struct {
void *data;
} id;
struct StructRNA *type;
void *data;
} PointerRNA;
```
This patch updates it to:
```
typedef struct PointerRNA {
struct ID *owner_id;
struct StructRNA *type;
void *data;
} PointerRNA;
```
Throughout the code base `id.data` was replaced with `owner_id`.
Furthermore, many explicit pointer type casts were added which
were implicit before. Some type casts to `ID *` were removed.
Reviewers: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D5558
In some rare cases it is convenient to store a short array value
as a custom property, e.g. a vector or color. For example, it may
be helpful when importing/exporting certain formats that support
custom or nonstandard attributes on objects.
The custom property storage already can handle arrays in order to
support properties defined via python. The only thing missing is
UI support (and some bugs), and this patch fixes that:
- Allow editing short array properties via Custom Properties panel.
- Fix a UI layout sizing bug triggered by the previous item.
- Fix a dependency graph bug with drivers using such properties.
- Make RNA_*_get_default_array code robust in case of size mismatch.
- Support custom default values for array properties, allowing
both an array and a scalar value.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D5457
There are two aspects to the problem:
- Dependency graph update for compositor preview was missing
updates flush.
Apparently, update for new frame style of update will take
care of flushing, but not the update tagged style of update.
This goes to a legacy dependency graph and is to be changed
at some point, but not so close to the release.
- Movie clips were missing from the compositor dependency graph.
This fixes part of T66519.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5256
The root of the issue comes to the fact that part of dependency graph
is being removed, without doing any further remapping.
This was happening because only materials used by objects were pulled
in, so when material mode is changed some material became unused and
removed from the dependency graph and freed, causing object or its
data to point to a freed memory in its materials array.
Simplest and safest way to solve this is to pull materials referenced
by both object and object data. This causes somewhat higher memory
usage but keeps evaluated state of scene in an always consistent state,
without any need to tag/update object's data on material mode change.
Don't think it is a problem in practice.
Reviewers: brecht, fclem
Reviewed By: brecht, fclem
Differential Revision: https://developer.blender.org/D5172
Two issues here:
- Evaluated object data is to only be updated for selection only after modifier
stack is done its job. Otherwise it's possible to have selection batch update
called on an input data, at the same time as original object data is being
evaluated.
- If object's modifier stack did not create its own evaluated mesh (in case
when there is no effective modifiers, for example) can not update selection
on object's data, as it might cause threading issues between objects sharing
same data.
This change makes it so sound handles are created for evaluated scene,
sequencer and speakers. This allows to have properly evaluated animation
on them.
For the viewport playback sound uses regular dependency graph.
For the final render sound uses dependency graph created for render pipeline,
which now also contains sequencer and sound datablocks.
All the direct sound update calls are replaced with corresponding dependency
graph recalc tag.
- Need to assign current scene in the builder: it is used to
route relations for object's customdata.
- Tweak relation from scene to object for the customdaat: this
didn't work before because the render pipeline scene has no
view layer component.
Fixes T65044: Crash when Rendering (F12)
This change makes it so a minimal dependency graph which only includes
compositor and sequencer is built for the render pipeline purposes.
Tricky part here is that it's only compositor itself and sequencer who
to use this dependency graph and IDs from it. Render engines are still
to be provided original IDs because:
- They will create dependency graph for the given scene, and currently
it is not possible to create dependency graph from CoW scene.
- IDs from the compositor/sequencer dependency graph are "stripped",
as in, they wouldn't have all view layers, collections or objects
required for proper final render.
This creates annoying mess of mixing evaluated and original scene
access in various parts of the pipeline.
Fixes T63927: Compositing nodes - drivers don't really work
Reviewers: brecht
Maniphest Tasks: T63927
Differential Revision: https://developer.blender.org/D4911
This is used by driers and this is a first step towards support of
scenes used for only compositor or sequencer.
Fixes T61014: Assert adding a driver that uses a single property of a scene ID
Noticed when was looking into T64764, F7043663.
This is a weird case when proxy group is not a group, but is the
same as linked object.
Remove useless relation which was causing cycle, but had no functional
meaning.
Pair programming session with Brecht.
Reviewers: angavrilov, brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D4928
At some point when the transform evaluation was split into EVAL and FINAL
the b350edc was re-introduced by EVAL being run prior to proxy_group's
matrix is evaluated.
There is now a checkbox to enable/disable depth of field per camera. For Eevee
this replace the scene level setting. For Cycles there is now only an F-Stop
value, no longer a Radius.
Existing files are converted based on Cycles or Eevee being set in the scene.
Differential Revision: https://developer.blender.org/D4882
This happened to be a bigger rabbit hole to hell than it originally seemed,
and there are higher priority design tasks to be handled (at this point high
priority design task is more important than high priority bug fix).
After talking to Brecht the decision was made to revert to the known isolated
issue, which will allow everyone in the studio work same as prior to last
Friday.
The remaining bits will be worked on after all the design tasks are out of
the way.
This commit reverts:
4cdb4b9532 Fix T64161: Crashing using undo and multiple windows
064273a4ae Sound: Port more cases to be a part of dependency graph
2e582f8ab5 Sound: Fix access wrong dependency graph
5fc49d9c91 Sound: add stubs to build without audaspace
c68c81a870 Sound: Make sure spin lock is initialized for new sound datablocks
c02534469a Sound: Delay creating sound scene handle for until is needed
9f681bea68 Fix T64144: Crash when displaying audio waveforms in VSE
2f79286453 Cleanup: unused vars
bed8ad6f95 Fix crash in background rendering after recent sound changes
773691310f Fix T64143: Crash when scrubbing in the graph editor
888852055c Sound: Fix for being unable to jump to a frame during playback with A/V sync
6ab7b38464 Sound: More fixes for access of original scene
35db119545 Sound: Fix access original scene during playback
211c4fd2e9 Depsgraph: Make comment about evaluation more obvious
c5fe16e121 Sound: Make sound handles only be in evaluated datablocks
b4e1e0946b Depsgraph: Preserve sound and audio pointers through copy-on-write
4eedf784b0 Depsgraph: Store original sequencer strip pointer
6990ef151c Sound: Move evaluation to dependency graph
d02da8de23 Sound: Delay opening handlers for until really needed
3369b82891 Depsgraph: Add scene audio component
e8f10d6475 Depsgraph: Tag sequencer for update on changes
6e4b7a6e4d Depsgraph: Initial work to cover sequencer
17447ac5a6 Depsgraph: Make sound ID part of the graph
This can easily happen if adding drivers through Python via
pose.bones[...].bone.driver_add(), e.g. in Rigify code: the
bone field doesn't change id_data, so the driver is associated
with the object ID.
To handle this it's necessary to skip from Object to data in
RNA_Bone-specific code both for generic RNA and in the custom
code for drivers. The latter also had to be changed to use the
proper parsed RNA pointer instead of string matching on paths.
Quite straightforward change, which makes it so audio handles are
only created inside of evaluated datablocks.
Exception is adding sound strip to the sequencer, which needs an
audio handle to query length and number of channels. This is done
by temporarily loading sound file into an original datablock, and
then tossing it away.
There is an assert in sound.c which verifies that audio system is
used from an evaluated domain, which should help porting all the
cases which are likely missed by this commit.
Some annoying parts:
- `BKE_sound_update_scene()` is iterating over all bases, and does
special ID tags to see whether sound has been handled or not
already. This can not be done the old fashion now.
Ideally, this will be done as a speaker datablock evaluation,
but seems that would require a lock since audio API is not safe
for threading. So this is not a desired way i'd say.
Possible solution here would be to iterate over ID datablocks
using dependency graph query API.
- Frame jump needs to call `BKE_sound_seek_scene()` directly
because there might be some flags assigned to the scene which
could be clear after operator execution is over.
Need to verify if that's the case though. This is a bit hairy
code, so sticking to a safest and known to work approach for
now.
- Removed check for format when opening new sound file.
Maybe we can have some utility function which queries channel
and duration information, leaving the caller's code clean and
tidy.
Tested following cases:
- Adding/removing/moving sequencer's sound strips.
- Adding/moving speakers in viewport.
- Rendering audio.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4779
Just adds sequencer operation and links possible sound ID to it.
No functional changes, just moving towards sound system integration
into the dependency graph.
Currently those IDs are not covered by copy-on-write mechanism since
that ruins the current design of BKE_sound, But this change allows to
move towards system where sound handlers are only valid for an evaluated
ID datablocks.
* The cache file datablock is now evaluated as part of the dependency graph,
creating/freeing the Alembic file handle matching the current frame.
Modifiers and constraints depend on this evaluation.
* Cache file handles and readers now only exist on COW datablocks, never the
original ones.
* Object data paths are flushed back to the original for the user interface.
* The cache file keeps a list of all readers associated with its handle, and
automatically frees them when the handle is freed. This kind of sharing of
data across datablocks is weak but we have no better mechanism for it.
Fix T62720: Alembic sequences not working and crashing
Differential Revision: https://developer.blender.org/D4774
This is a part of T61296: Crash with animated b-bone segments.
Consider animated/driven bendy bones segments as something what requires
special bendy-bones operation and relation in the dependency graph.
This is because it is more beneficial from a performance point of view
to not build operations if they are not needed. But if the property is
animated it is not possible to make any reliable decision based on just
a property value.
Differential Revision: https://developer.blender.org/D4739
Allows to speed up lookups like "is property FOO of data BAR animated".
Can be used to optimize object's visibility check, but also allows to
check animation on bones without too much of time penalty.
The cache is shared between both nodes and relations builder.
Currently is not used, just a boilerplate for an upcoming changes in
an actual logic.
The driver code was almost there, but didn't work because ID nodes
have no outlinks - and using links won't be safe anyway because of
ordering issues. Instead, just loop over all IDNodes.
Animation is fixed simply by referring to ARMATURE_EVAL instead of
BONE in construct_node_identifier - the bArmature ID doesn't have
BONE components in any case, so the old identifier can't work.
During driver var evaluation, the code directly skips to the proxy
object if present, so the dependencies should reflect that, instead
of inventing extra relations to pretend as if the values were
first copied from the proxy - they actually aren't.
The invented dependencies can't work without cycles in complex but
meaningful cases, e.g. drivers on armature data that depend on pose.
This alters the changes from 72cbf966fb to be more correct.
BKE_mesh_new_nomain automatically added a CD_ORIGINDEX layer initialized to 0,
which was never filled in correctly. In 2.7 the equivalent function used to
modify the source derivedmesh and add valid original indices to it, but this
is no longer possible in the new design and was quite unpredictable anyway.
Now instead rely on mesh_calc_modifiers and the depsgraph to determine when
CD_ORIGINDEX should be added.
Was a mistake in the recent change.
The idea here is: manual should invalidate point cache, but
rigid body simulation should only happen after point cache
was ensured to be in the correct state.
There was missing flush from transform update to the point cache
reset. Caused by the fact that when update happens in the "middle"
of component all the component operations will be tagged for update
(since the intermediate state is not stored), but that will not
flush updates to other operations since that would cause too much
of updates.
This now we tag point cache for reset after evaluation operation
but before final transform and before rigid body world.
The issue is a feedback loop with point cache reset operation.
Solved by introducing extra node which ensures object's transformation
is ready for simulator input. Allows to route relations without causing
a fake dependency cycle now.
