Massive Movie Collaboration Theory: My experiments with Blender...

Pipeline · November 8, 2010, 8:50am

(I considered putting this in Basics & Interface, but it is in no way basic, so until someone disagrees, I simply put it in here. It is meant for discussion, anyway…)

Some may know I have a bit of an obsession with Linking in Blender. This has worsened greatly after I found out that Dropbox lets you keep online files linked together. I have now seen this as a potential core for my personal holy grail of Blender: A way to make massive collaboration projects easy to set up!

To this end, I have spent several days, once again, experimenting with links. Not appending, mind you, but linking things into files. My goal is to design a way to have scenes split into dozens of files, which can all be altered simultaneously by a team, and the results then automatically be obtainable in one ‘parent’ file. So maybe you have a scene in the works that shows five soldiers running down hill towards their base, which is being fired upon by helicopter gunships. The parent file is just a bunch of links to ‘children’ files. One child file has the basic texture of the uniforms, one has individual color designs (officers and privates have different camo specs), one has the general armature design, each soldier has a file for their particular setup, weapons have theirs, gunships theirs, base buildings theirs, etc. Hell, even the way the soldiers move and gunships attack each have their own files, as do the explosions at the base.

Why? Because in a large team, you need someone to be able to work on how the soldiers move, while another is designing their weapons, another their materials (all sharing the same texture, which another is designing), and so on. And in collaborative projects, you never know when people have the time to get their stuff done. So Craig in Ohio has to be able to model ‘Private Zuza’s helmet’, whether or not Elsa in Stockholm is still working on the texture of its camo. And it all has to be easy to fit together, preferably automatic, so that someone can at any time render out the current version of the entire scene.

Not… freaking… easy.

Big studios have lots of ‘assett management’ tools for this. Projects like ED, BBB and Sintel use it, but these all have the advantage of inhouse control and a faaaaaairly predictable workflow. Open collaboration does not, so I want to be able to split everything into atoms that can all be handled independently, yet fit together neatly for rendering. I am experimenting with ways to set up large Blender projects to handle this. I do this because our Ninja Delivery Services ad project is going well, and I want the next project to be even smoother (and bigger :D). Linking seems to be key. I will describe my experiments here, hoping someone can point out things I missed or ideas I never considered.

Pipeline · November 8, 2010, 8:58am

Before going into my linking experiments as such, I would just like to clarify how Dropbox.com fits into this.

I came by Dropbox not long ago (less than a month). I never expected it to be more than an online storage bin. But it turns out that, just like the directories on my laptop, I can link things together in Dropbox, and they work together without ever needing to be assembled in my actual computer. That means that I can

A) render directly from a file in Dropbox
B) let a number of people change parts of the project constantly, and it will automatically show in the next render.

So basically, I can set up a system where I render a scene, then wait X days and render it again, and voila! Things look better without me doing anything (assuming, of course, people are uploading improved models). If five people change five different linked files, the whole scene might be improved to be unrecognizable! All this, collaborative, without anyone needing to do any extra work. I like not having to do extra work

I still need to do advanced experiments in Dropbox. Can a user only see linked content from files he/she has access to (could Brenda in London render all content linked into a scene, even if she cannot access link source files directly)?? If so, some shared directories can be broadly shared and allow indirect manipulation (or just the rendering) of scenes without giving everyone access to everything. If a project is split up (Team A handles the space battle, Team B handles the dragon eating the princess), this is a good way to keep things seperate and focused. If there are debates on content that not everyone is privy to (perhaps to avoid plot-spoiling), also a benefit!

Anyone with advanced experience in Dropbox is welcome to describe their experiments

Pipeline · November 8, 2010, 9:27am

So, as for my latest experiments with linking…

I have found that Blender’s linking has some significant limitations. This is probably because my experiments are borderline insane, but nonetheless, I have had to do some work-arounds. The first I discovered (deliberately) was that linking in an object means you link in everything in it! If I link in a simple box, it has its material with it, and it’ll be damned before it lets me change that material. that is the problem that inevitably comes with linking: Some things you can change, some you can’t. What I found, however, was that knowing the general structure of objects comes in handy. By linking in a mesh instead of an object, their is no baggage. Of course, the mesh does not appear on its own; only objects show up in scenes! But insert a single Plane, and go to the Object Data menu (the little triangle with dots at the corners) in Properties, and swap the ‘Plane’ mesh for whatever the name is of your linked mesh, and suddenly you have that mesh in the scene; it has become an object, by becoming the mesh of an object!

What do you get from that, you ask? Well, suppose you have this really nice Porsche model, or spaceship, or sword, or whatever. It is not done yet, but you want three of them in a scene, all in different colors. Well, make three Plane objects, link in the mesh, and swap it into each Plane. Now you have three Porsches, and every time someone improves that mesh in the external file, they look better. Better yet, you now get to set their materials, meaning they can be any color you like, or even have textures (like a Normal/Bump map for the one that’s dented, or a Specular map for the one that is wet). One note, though: In the Material tab in Properties, there is a box that says “Data”. You have to switch it to “Object”, or Blender saves the attached material strangely (probably to the object you attached the mesh to, instead of to the mesh, but I’m not sure. Anyone know this?). do that, Bob’s your uncle, and you have splendid Porsche scenes that update everything easily!

Of course, materials and textures are a funny couple. They belong together, but are not the same. If you check out the options when linking, you will see them listed seperately. Yes, you can link one without the other. But not just anyone… You see, there seems to be a hierachy in Blender data blocks. It makes perfect sense when you look at it, but it is also annoying when you want to go gonzo on a scene. In this case, linking a material means linking everything about it, just like linking an object does. So if your material has a texture, you get that along, and you don’t get to say anything about it. So let’s go back to the Porsches… If you make a material that makes the Porsche red, with a texture that adds rust stains and a texture that adds dents, that material gets you a red, rusty and dented Porsche every time. You can’t ‘un-rust’ or ‘un-dent’ it. What you can do is link the textures into the material file from another file of your choice. That means the textures can be changed seperately. Done right, that lets you copy the material to a seperate folder (it is assumed that all paths are relative) and copy the textures along with it. then you can change those new textures that (should) become the ones used by the material. Why do this, you ask, instead of just having the textures in the material directly and changing them there? Well, this way, you can have a number of different materials copied, all using the same textures. So now you have one folder with 54 materials that are all heavily rusted, and one folder with the same 54 materials, but only slightly rusted, because you altered the copied textures.

If you play with node materials, you can do this even more wildly, creating completely composited materials with interchangeable parts that others can improve or make variations on. Suddenly, the basic node setup for a rusty army camo material can become the rusty hotrod flame-red design for the old car in the junkyard scene, while someone is still designing the flame-red material. Hell, if someone makes a variant of the hotrod design, the node setup instantly offers a rusty version, too! You’ll never have to do rusty versions of your 47 materials (and counting) ever again. But you can always go back and improve the ‘Rust node setup’, and the changes will permeate to every rusty material you used it on.

Hell, the changes will permeate to every rusty model you made, in every scene you used them in, if you linked materials and meshes up as described earlier! One guy making a tweak to vastly improve the rust texture could thus change the look of your entire movie about old military artillery and veteran hotrod racing, and you would only have to push Render to get the results! Talk about work-hours saved…

Next time, some surprising experiences with links and armatures!

Pipeline · November 8, 2010, 11:12am

Armatures. The lifeblood of advanced animation, and especially character animation. I have tried a lot of things with them, but I must say that I do not feel I have nearly pushed the envelope as much as I could or should.

You have two basic options for linking armatures into your scene: Linking them as armatures (duh), and linking them as objects. As armatures, they work much like meshes, in that they do not show up in the scene, but you can create a new armature and switch its actual bone structure to that of the linked armature (go to the Object Data tab in Properties, which is for armatures defined by a little guy with his arms stretched out). The linked armature will take the place of the newly created one (which was presumably just a single bone).

The alternative is to link in the armature as an object, i.e. going into the Object option in the linking ‘folders’ and picking the armature. This is a slightly different experience, part of which remains odd to me. The thing is, this method brings in the armature with everything in it. That means it shows up in the scene right away, but it also means that all the animation comes along. So if the armature had poses and animation in the source file, it has that same animation when linked in. One problem is, that it will not let you parent anything to it; click Ctrl-P as much as you like, you don’t get the parenting options. To do that, you have to make the armature a proxy. And if you make it a proxy, it loses the animation. So basically, whether you create a new armature and link in an external armature that you then insert as the actual armature for the newly created one (I know, the phrasing is Hell), or you link in an armature as an object and make it a proxy, what you end up with is pretty much the same: An armature without any animation in it, which you can then parent a mesh object to. Funny fact: You can remove the animation from an armature imported as an object but not yet made proxy, simply by going to the NLA editor, making the animation data an NLA track, and deleting the track (that seems the only way to do it, btw. You can’t just delete the animation in the dope sheet). That leaves you with the armature in whatever pose it had in the scene when you deleted the NLA track. Of course, that has no real consequence, since making it a proxy (in order to, you know, use it for something) will reset it to rest pose no matter what.

So you have an armature that you can deform-parent a mesh to. Here comes the trip: If you create an object (with mesh) as per usual in Blender and deform-parent it to the linked-in armature, everything is fine. You can save it, shut down Blender, go for coffee, come back, load it and everything looks as it should. However, if you link in an object (complete with mesh), it won’t deform-parent to the armature. In fact, it won’t parent, period! One thing never mentioned earlier about linked object meshes is that they are kind of pricks, they don’t really feel like doing much of anything except standing there; they don’t move, they don’t rotate, nothing. So you go ahead and usse my earlier suggestion and make an object, link in a mesh, swap the object’s mesh with the linked one, and you have a compliant playmate. Hell, it even deform-parents and everything. The kicker? Try and save it. Go ahead, I’ll wait. Now, open a new file. Now, load up the one with the linked in armature and mesh. Everything in the Properties tabs still claims that the mesh object is parented to the armature, but it only acts as an object parent, not a deform-parent. Meaning if you move the armature around in object mode, the mesh object follows along nicely. But rotate bones, and nothing happens. The deformations it so nicely showed you back when you first parented it to the armature? Gone. The armature might keep any animation you gave it, but the mesh object seems to have forgotten it was supposed to care. Good news is, break the link (delete the Armature modifier, for example), then parent it again, and it goes back to before, deforming and everything. But for some reason, when you load the file, an object with a linked mesh ‘forgets’ it is supposed to deform, while an object with a local mesh (one that is not linked from somewhere else) remembers. I have no explanation why. And it ticks me off, to be honest, so anyone with a fix, I will bear your children (I am male, be warned).

Back to the animation. As mentioned, anything that allows you to actually parent a mesh object to the armature will erase any animation in it. I have found no way to stop this from happening. I have found two ways to work around it, though: Either copy the animation to clipboard in the dopesheet before making the armature a proxy (if that is your poison) and copy it back in from clipboard afterwards… or start linking to Actions. Needless to say, the latter is more in tune with the idea of my experiments, since copying the animation back and forth appears to simply give it a local, unchanging copy of the animations it came in with. No, linking in Actions is the way to go for me, because that means that someone can work with the animation of the armature even while you have the armature in use in another file. So you may have your soldier rigged with an armature that dumbly waves arms and legs around to insinuate that he is ‘running’. you can have him in a scene and render it, you can move things around him. Hell, depending on what your animator is doing elsewhere with the actions, you can even animate things in the soldier! Maybe you need to do facial expressions. Your animator isn’t using the guy’s eyebrows to make him run, is he? And when the Action used in the running is updated, you will see it next time you load the scene the soldier (or the linked in mesh, materials, etc.) is in!

To really make use of linked versus local Actions, you need to know your way around the NLA editor. That is beyond my current writings. But a few teasers: You can link in multiple Actions into the same armature. So those facial expressions? Maybe while your animator in Toronto is creating a sweet running Action for the soldier, someone in Senegal is doing the facial animation! And since Blender 2.5 lets you put literally anything animated into Actions, well, get creative! Also, done properly, Action animation parameters can be copied together, or seperated into different Actions. How this affects linkability is not something I have experimented with, but I fear that it produces entirely new Actions; if you want to keep the links working, I think you need to use the linked in Actions as they are But hey, if one action is running, one is facial expressions, and one is firing the rifle, those Actions can be moved around inside the NLA to change timing (“hmm, shoot before or after he passes by that big rock…?”). How good they look individually changes as your off-site(?) animators fiddle with the details of each linked Action.

Finally, a small note: Actions are a bit funky in 2.5, compared to 2.4x (although that got funny at times, too). You need to put them in NLA tracks and such. Be sure you know how to use Actions normally before using them with links, or you may just screw up your work in fascinating ways

That’s about as far as I’ve come with my current experiments. I am going to fiddle more with all of this, but it’s probably going to be a few days before I have truly new experiments to talk about. If anyone has ideas, suggestions, questions or explanations on any of this, please post. Linking is not the most prestigous part of Blender, but it is IMHO a fascinating tool, with promisses of tremendous potential for larger projects. I think it is worth exploring far more than we do now. Again, IMHO.

Edit: Silly me, I never touched on Group linking! I’ll continue my already ample experiments on that, and get back at some point with observations!

walshlg · November 8, 2010, 6:59pm

great blog, keep up the experiments. The main problem, is one I’ve had with widely distributed databases, is simultaneous activity on the same data. You must develop rules for dealing with conflicts, both real and potential. We got around that by only allowing one “Author” of a file at a time. That’s not too good, but is easiest. With this single author approach, to avoid bogging things down, you inevitably end up generating finer and finer limitations on what goes into each data file, eg. you may start with a jet fighter file and end up breaking it into jet fighter rough mesh with UV maps, another with Jet fighter textures, another with materials and shaders, another with armature and another with actions. Suddenly you have problems like making sure a change in your mesh isn’t destroying your texture layout etc. making you want to stick it all back together again into a single file. Tough to know what is the best answer.

May I suggest checking out CeltX if you haven’t done so already - designed for collaborative film making.

Pipeline · November 9, 2010, 2:23am

I agree, assett use timing is at the core of this. Had everyone been able to access the same file google wave style, I doubt linking would even be a real issue. In our project, we have a system of ‘claiming’ tasks, but the technical structure for it is provided by a seperate php script on the website, called the tasklist. I would love to find a method more native to Blender itself, but so far I am coming up short… Ideas, anyone??

Pipeline · November 9, 2010, 9:13am

It took e a long time to really get a footing with Groups. In a lot of work, Groups seem somewhat redundant, even counterproductive. Why have a bunch of things tied together when you are making a model or a picture? Or even a movie? And when you finally do use them, they automatically transform a lot of things together. It seems cumbersome. Parenting, layers or other tools seem so much more practical.

Of course, Groups have their advantages, like being able to select a ton of things from one menu, designed by yourself. But in linking, Groups gain a whole different dimension. For one, linking a Group means linking whatever is in it, at a given time. So if you make a file with two models in a Group and link that Group into another file, great, you get those two objects in your new file. But if you go back and add an object to the Group in the source file, it suddenly shows up as part of the link. At first, this was black magic to me. You can actually have your destination file contain stuff you never linked into it! Whatever is in the Group comes in. So if you have no idea how many objects are going to be in, say, the hillside that those soldier characters are running down, just link in a Group. It might be just a flat plane to begin with, but someone can take the source file and throw all kinds of objects into the Group, and they will show up! You never have to do new links again!!

And as icing on the cake, parenting works in linked Groups. Typically, having 3 objects parented to each other linked in would require you to link each, then parent them. No more. If they are in the same Group, they link in together, parented and all. This even works with deformation by armature; the armature and mesh object link in as one, if linked as parts of the same Group. Presto, instant setup.

Of course, there is a downside to all of this. Groups essentially function like the Supersized version of objects (which, in turn, was the Large version of materials, for the purposes of this metaphor). Meaning, just like an object comes in with its material all set up (which was why I ranted on the benefits of linking meshes as an alternative to entire mesh objects), a Group comes into play with all the objects in it, and there is very little you can do about it. Want to remove an object? Either make the Group local (goodbye, updates from changed source file) or go handle it in the source file. So be sure you know what you want in your scene before doing it by Groups. Same seems to go for animations in both objects and armatures, you either accept them or don’t get to use the linked Group at all.

One oddity I found, which can be considered a plus for Groups over objects, is that Groups are not as big pricks as Objects; they let you move them around! So you can put your object in a Group all of its own lonesome and link it in, and it will be exactly as if you linked in the object itself. Except you can move it, rotate it, and (I presume, never tried) scale it! Hell, you can parent it to something (technically, you can parent a linked in object, too. It just ignores you when you manipulate the parent; the Group doesn’t!). The only reason I see to link in an object rather than a Group is the 8 seconds it takes to make a Group for the object in the source file. Of course, the actual beenfits may just have slipped my mind in the excitement :o

One note I need to make: I have in the experimentation with Groups just (I mean right as of writing; I redo my experiments while writing these posts) found that, for inexplicable reasons, the stuff about mesh objects not deforming has somehow evaporated. The mesh object I just tested… deformed! After having been saved and reloaded! I have no explanation why, and I am confused. Either Blender is screwing with me, or this linking stuff has secrets I am not yet privy to. I hope this is a sign of things being more stable than I initially thought! :yes:

Pipeline · November 9, 2010, 10:00am

Okay… This is a bit odd, but potentially very useful!

I redid the experiment, and have found that whether the deformation parenting of an object with a linked in mesh to a linked in armature made proxy will survive saving or not… depends on whether they were linked in the source file. Even if you linked them in completely seperately. I checked by created an armature and a cube in a source file, and not parenting them. Then I made a new file, linked both in, and deform-parented the mesh (which I had put on a local object, as per usual) to the proxy armature. It worked when I had the file open, but when I saved it and reloaded it, the parenting did not deform - as expected after the trouble I had encountered before. Then, however, I went back to the source file and deform-parented the two in the source file. I saved it, and loaded the destination file. I did nothing in the destination file, and voila! The deform-parenting just worked, all on its own! Halleluja, I thought, salvation is here!

Then, a voice whacked me in the back, saying (with a really bad 80s imitation of a surfer voice), “dude, you gonna be hooked to that same mesh no matter what??”. So I made a round of experiments. For whatever reason, as long as the mesh’s object in the source file is deform-parented to any kind of armature, it will result in a remembered deform-parent in the file it is linked into, even after saving. Naming doesn’t matter; I tried all combinations of match/no match naming I could come across, and even tried using an armature that had nothing parented to it in its source file. Then it dawned on me: Vertex groups! A mesh uses vertex groups to define how it deforms in response to repositioning of bones in an armature! True enough, changing the form of the armature enough to make it noticeably different from what the mesh was deform-parented to, I made the mesh deform quite differently. Removing the armature modifier (and thus, the deform-parenting) and doing it again with the exact same (linked in) armature on the exact same object with the exact same (linked in) mesh produced completely different results!

Apparently (and I am very much speculating here), a mesh linked in retains its vertex groups, which determine how it will respond to deform-parenting to any armature (I am only speculating right now, and assuming this applies to non-linked armatures, as well). The vertex groups can be altered by removing the original deform-parenting (I just delete the armature modifier in the object). However, when the scene is reloaded, the mesh regains its original vertex groups, from the source file! If it had none (most likely because it was not deform-parented to anything in the source file), there will be no deform. If it had some, it will deform according to them, not giving a crap what you changed before the save.

This opens a bunch of questions on the idea behind this kind of linking in Blender. Why can I change the vertex groups, when it will not remember the changes after saving and reloading anyway? Are the vertex groups a seperate part of the mesh/object structure, like the material, and can thus somehow be linked in seperately (and the file remembers after saving)? Considering the whole weight painting thing, I would not be surprised (am I remembering right, that you can actually save weight painting as an image file, and bring it in for an object, perhaps one not exactly like the one the weights were originally designed for?). And most of all, how do/can I use this to my advantage in a large, link-using file structure? If usable and used properly, I could imagine some really cool things, like having the exact same armature rig and mesh deforming differently in two objects because of using different linked in weight maps, or a single weight map linked in for use in several similar but different models (“hey, this character, could we have him be more flexing with his muscles?” “Sure, I have a weight map right here that we used on this other character!”), and most of all, could someone continue to improve on weight painting without needing to use the full scene, effectively allowing a widely ussed weight paint map to be improved off-site and the improvements trickling down to all the affected characters without further effort, just like the improved rust texture that changed the look of an entire film in an earlier example??

My guess is, the answer to all of these questions is the same: Nobody ever used these features in this madness-inducing way, so nobody really knows. I wonder what I’ll find out…

Edit: Upon closer examination, I found no signs that weights can be treated as a seperate entity from the mesh; if you have a mesh, you have its weights, period. So to change weights, you need to change them in the mesh’s source file. A resulting note (partly for myself): Armatures used as deform-parents for linked in meshes cannot be changed in any way that affects the mesh, without someone adjusting the mesh to fit those changes. The armature source can still be changed for purposes of better controlling the bones, of course. The changes simply will not change how the mesh deforms, except that bones moved and therefore moving differently during posing will make the emsh deform differently, because they still affect the same weight painted vertices, but move differently. I may have a headache now.

Lydorn · November 9, 2010, 12:44pm

I’m quite interested in this.
For the hierarchy problem with: Textures/Materials/Mesh/Object for example, you can make a file for each, then in the material file link in the textures. In the Mesh file link in the materials (and the textures will link with that). Finally in the object file link in the mesh (and so material and textures). This respects Blender hierarchy and works fine.
I hope it wasn’t something you already said.
Actually, it would be great to be able to change an asset from any blend file that use it and it gets updated in the other files.

Pipeline · November 9, 2010, 2:38pm

Actually, regarding hieracy, I am trying to map out the linking options that I have used until now, setting them up in a “you can do this, but not this” kind of diagram/hierachy. That would be a good visual aid, I believe, including for myself :o

It wasn’t, and you are quite right, that is a way to do it. If the mesh being made is unique, I think your way might be the most practical, because it lets the modeler render with full material, even as this material is being worked on by others (and textures by even others, etc.). My version requires the modeler to work without material, or with a substitute. It does, however, have the advantage that anyone using the mesh is free to swap in any material, making possible the different Porsches example. It’s a choice, I guess, depending on what you are trying to achieve Of course, to make it a bit more complex, maybe someone could link in the mesh, and the material from that same file, seperately, providing the best of both worlds (I think, at least…:spin:). The question is, how many layers of linking can the material go through?? My current experimentation deals with multi-layer linking (linking to something in a file that was linked in from another file, etc.), and the results are not always what one would expect :eek:

Actually, it would be great to be able to change an asset from any blend file that use it and it gets updated in the other files.
Ohhhh yessss… that is exactly what I am trying to figure out how to do :evilgrin:

Lydorn · November 10, 2010, 5:04am

You are right, it depends on what you want to do.
Being able to change an asset from any blend file would be an other feature to add. I can’t see a way to do it in the current version of Blender. That is why I thought of doing an entire project with only one blend file, then use a scene for textures, an other for materials, an other for meshes, an other for objects…and link them in the scene you want to use them. That way you can change any settings and it gets updated in every scenes. One thing thought, if you set up an IPO for an object, it is the same for every scene. I don’t know if you could do “scene local” assets. But that would create a very big file and most of all only one person could “author” it. Unless several persons could edit a file.

I also thought of doing your project in one file (not a blend, something else like a .projectblend) and in it you organize your files like you would do normally with your OS (internet explorer for windows) that way, Blender controls everything. You don’t have to go thought an other program. It would be like a .blend file with its scenes but at a higher level. So you don’t load all your project, just the files you need.

For the Porsche example, where you just change the color of the material or the texture you use, it would be great to be able to create “children” of a material and change the setting you want while all the other ones remain linked with the “parent” material. Like classes in Python. You could use the hierarchy linking system and create a child of the material in the Material blend. Then you could link in the material and choose from that material the child you want (there could be more than on child).

Pipeline · November 10, 2010, 4:46pm

The all-in-one-file-full-of-scenes idea has come across my way before, but I don’t think it’s very good to do. As you say, only one person can alter it, and it becomes very big. Linking from other files is really a powerful way to do it (until we get the feature where many can work in the same file. We can always dream ).

The .project file concept, however, is very realistic, and it is one of the things I want to work towards. I made something like this in 2.47, just before my computer crashed and burned (literally, it burned. It had smoke and everything :(). I used it to create multiple scenes and save them as independent files. It did not create links, but it could link in assetts (models only, I think) by letting you press a button on a list. Need a certain model in a scene? Click one button, and it is there. so it was only a way to make linking and scene creation faster, but it had the same thinking as your .project. And I hope to start building the same in Blender 2.5, soon!

One really big feature I would love to see (apart from overall improvement of linking, because there are some seriously weird obstacles in it…) is the option to redirect links. think about it: You have, oh, 7 assetts linked from files in your Models folder. You want to use another set of models, just to see how they will look in the scene. You now have to do two things: Put the files into the right folder (and backup the old ones, if you want to switch back), and make sure the new files are structured in the exact same way (including model/object names). what if you could just go into the file that all the models were linked into, and set it to point at a different folder? Just like when you change the folder you render a movie to! And what if you could actually get a schematic of all your links, like the nodes or the old schematic Outliner, and just start switching links around! So your hero drives a Pickup truck instead of a jeep? Just point the link to your model of a pickup! With Blender now, you have to do all the links over again, and that can take a lot of time, especially if you use links as much as I am starting to