[Bf-committers] Proxy system upgrade ideas

[Daniel Salazar - 3Developer.com]

Good coverage of points there. I would add that duplis inside linked
chars should be kept as duplis in order to save on ram. ie an army of
100 tanks could look like this

https://docs.google.com/drawings/d/1m_APQWnzs3lgNtZ4UxRmhTMJR0AMome8j59qMIZndp4/edit?hl=en_US

only the deformed meshes (simple mesh type obs, not duplis) get
duplicated in memory since their animation can potentially be
different on each proxy

cheers

Daniel Salazar
patazstudio.com



On Mon, Dec 12, 2011 at 7:27 PM, Nathan Vegdahl <cessen at cessen.com> wrote:
> 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 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers