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 _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers