[Bf-committers] Proxy system upgrade ideas

[Nathan Vegdahl]

Hey guys,
Since there's a depgraph overhaul up-and-coming, I thought now would
be a good time to start talking about designs for a new-and-improved
"proxy" system as well.  Campbell, Brecht, and I discussed this some
while working on Sintel, but it wasn't feasible to actually do any
coding work on it at the time.

To quickly recap the purpose of the proxy system:
The intent behind Blender's proxy system as it currently stands is to
allow Blender productions to animate library-linked characters.  This
allows all of a character's static data to be kept in one file that is
easy to modify and update, whilst still allowing the character to be
used in other files and animated.

In the time since the proxy system was first implemented, however, it
has become clear that the existing implementation of this is limited
in several undesirable ways:

1. You cannot create multiple instances of the same character with
different animation.  This is a big problem for things like e.g. a
crowd of people or a flock of birds.

2. The proxy system is only useful for armatures.  While armatures are
likely to be a Blender staple for quite some time yet, there are many
cases where proxy-like functionality (i.e. partially local/partially
linked assets) is useful outside of hand-keyed character animation.
We ran into this on Sintel, for example, when doing hair and cloth
simulation.  Even something as simple as specifying different cache
files for different shots was a pain, not to mention adjusting
simulation parameters per-shot.  We hacked it via Python, which worked
okay, but that's a nasty solution that isn't accessible to most users.

3. The proxy system is only useful for group instances.  This
precludes some potential uses which might be quite useful, e.g.
linking and tweaking materials (linking for production-wide
consistency, occasional minor tweaks for specific shots) or linking
and tweaking a background scene (again, linking for consistency,
tweaking for an occasional shot).  And who knows what cool uses users
will find for the proxy system if it's more widely applicable?
Discoverability is a good thing.

The bottom line is that Blender's library linking system is really
powerful and awesome, but the proxy system is pretty anemic, which
limits the application of library linking in real productions.

Point #1 is a primary target of the depgraph overhaul, so I'm not
terribly concerned about that.  But points #2 and #3 are worth
discussing, I think.

Fundamentally, the proxy system is really about fine-grained control
over the locality of data.  For example, when making an armature
proxy, we're saying we want the pose channels local, but everything
else remote in another file.  This is a fine-grained statement about
locality.  Instead of the entire armature either being local or not,
we get to specify which parts of it we want to be local, and which
parts we want to leave as remote.

As I mentioned before, on Sintel we used Python to tweak simulation
parameters on linked data.  Linked data only gets updated on file
load, so once the file was loaded, python could modify rna properties
to its heart's content.  We simply had python scripts in each file
that ran upon loading, and which made the local changes we needed.

I think a similar approach could be taken as the basis for a more
generalizable "proxy" system.  The idea would be that for any basic
rna property (e.g. bool, int, float, vector, string, enum...) of a
linked asset, it can be marked as locally modified, with the local
data.  Upon file loading (and perhaps some other cases, where needed)
that local version overwrites the remote version.  In the case where a
linked property is removed in the remote file, or the type is changed,
the local version could eventually be garbage collected.

In essence, the basis for a more general proxy system would be a
locally stored "diff" of modified rna properties, except it's a simple
"over-write if the rna path exists and is of the same type".  No
complicated merging strategies needed. ;-)

This would immediately deal with most use-cases for the proxy system,
and it would do so in a fairly straight-forward, consistent, RNA-based
way.

However, there are still other use cases that this does not fully
address.  For example, it is useful for animators and riggers to be
able to add constraints to proxy bones, etc.  So we may need some
additional supplementary systems for cases like locally modifying the
constraint stack, or adding shape keys to a mesh (I could have used
this so many times...), etc.  But I think it could still be based on
the same basic idea: a simple diffing model that errs toward "don't do
anything".  But the specific "merge" strategies could be
domain-specific.  And we don't have to have everything be proxy-able,
of course.  The most useful ones can simply be added over time, and as
it becomes clearer how best to do it.

There is also the matter of accessing objects within groups.
Currently characters are dealt with by making a local duplicate or
"proxy" of the armature object from a group instance.  This allows the
animator to access the armature, which would otherwise be hidden away
in the group.  But with this system there would be no proxy of the
whole armature object, only of individual rna properties within it.
So we would need a clean and easy way for users to access objects
inside group instances, so they could get to the armature.  Though
this goes for simulation stuff as well anyway (the user needs to be
able to select the clothing or hair object in the group to do
simulation stuff).

With a system like this, it would also be useful to be able to specify
"locked" rna properties in the remote file, that are not allowed to be
proxied.  And perhaps we can then get rid of the rather hodge-podge
transform locking system currently in Blender.  Though, of course,
this does not have to be done all at once.

Lastly, it might be good to have some kind of color-coding or icon
scheme in the UI, so that users can see what properties are proxied.

Anyhoo, these are my thoughts at the moment.  My hope is for this to
be the beginning of a discussion, and that we can eventually put
together a solid proposal.  Thoughts?  Ideas?  Criticisms?

Perhaps I should start a wiki page for this, too(?).

--Nathan