Shader assignments in linked objects?

Shader assignments in linked objects?

animate1978 30 Jun 2009 18:40

So I am beginning to work on a simple test animation, right now building an environment (hopefully that will expand), however I did notice that when I have appended objects from the prop library, the shaders I have assigned do not stick with it - which I almost half expected anyway. Not a HUGE deal considering once I append the text files of the shaders, they get assigned without having to take steps to do it again in the scene. Is there a way to permanatly assign shaders to any given object in a library blend file, thus avoiding to add shaders each time we need to do a shot?

Re: Shader assignments in linked objects?

Eric Back 01 Jul 2009 02:59

Hey Ted,

Unfortunately I don't think Blender see's or understands any text file connections MOSAIC has with project datablocks (it does with many other things such a automatically loading a texture with a linked material). So this means that text files will need to linked to any new production blends when they are started, however this should only need to be done once for each production file. Also I strongly recommend "link" over "append" as any changes made to the original shader blend will perpetuate to all linked blends however append will loose that connection. You can change this with the toggles on the bottom of the linked library dialog in Blender (I think append is the default).

A trick that may help is you can right click in the link dialog to select multiple texts at once for linking. Another more extreme solution would be to put all shaders, includes and fragments for the entire production in one blend and link them all for all shots, this will slow down shader export and compile but not scene export as it will only process shader fragments that are linked to materials in the current project.

Eric

Re: Shader assignments in linked objects?

animate1978 17 Aug 2009 16:40

After loosing net access for a few days I set about doing some research. One of them was this linking thing. It really is not that big of a problem as I thought, since I can actually link the shader fragments (such as ds_bumpy) rather than the shaders themselves, not only will it automatically assign itself to the object in question, it will also retain any parameter settings made. I believe that is what you were talking about Eric I just might have not understood it until actually doing it.

So this library linking has got me thinking. Which means of course that in order for me to really pull it off I would need to reassign ALL shaders (aside from the train and spider of course), this way the shader that gets linked from a shader library blend file can be modified and as mentioned before will spread to all the other blend files that use that shader.

Re: Shader assignments in linked objects?

Eric Back 17 Aug 2009 22:13

Linking has several advantages such as automatic centralization of assets and content protection (you can't accidentally modify something in a different project file). This said I think the main problem has been properly formed relative paths which will continue to be a problem even with linking (Blender still needs to find the project files in a relative way or paths will continue to break between systems). I do think this is all "doable" as I haven't had any issues between Window's and Linux with the BBB content and they used both linking and relative paths to assets.

If you haven't already I would use BBB as a model for asset management and project structure as it seemed to work very well in a cross platform environment with lots of assets ;)

Re: Shader assignments in linked objects?

animate1978 18 Aug 2009 08:35

Linking would be done via the blend file itself, so in other words, the environment library that Dan had built will have all the required shaders in it. I thought about doing a shader lib, however I am guessing that I will be using the same shaders, just with varying names, for the various objects. I will also be naming them differently as well, like ss_concretepillar for one concrete shader, and ss_concretewall for another. This way if they use the same shader code, the fragment is different thus there is more control over the various objects in the scene.

Since it would be far easier to make shaders for that particular blend file, keeping it within that blend file would be far easier than linking from a shader lib. I think… I could be wrong but it would seem logical to do it that way rather than a shader lib blend, since after all that is the majority of the actual environment.

So with the linking, well more the relative file paths… shall we restructure the project to make it easier for Blender to find assets? I will go through the BBB ftp site (as it is setup as-is) and take a gander around and make notes. I think right now it is crucial that we nail the directory structure now that we are getting into the layout phase, so once we start assembling shots the directory structure will need to be permanent, otherwise things get lost.

I think I will look into this tomorrow morning.

Re: Shader assignments in linked objects?

Eric Back 18 Aug 2009 19:46

I agree… the intent of the shader fragments are to be renamed and to use a variety of different settings per shader source, therefore storing shader sources in a library and storing fragments per project makes sense. Of course if you have prop and character blends the shader fragments can be done in them and the scene ribs would actually be linking in everything in the prop/char blend including the fragments and shaders (recursive linking). The cool think with this setup is you can't actually alter the character setup in the scene without editing it in the character blend, so on and so forth :)
As far a pathing with linked libraries it may be much easier to manage as there are options to check paths and make all paths "relative" in the "File"->"External Data" menu. As long as images and text are packed and make local then you only have to worry about using relative paths in the libraries. BBB doesn't actually do that everywhere however as they put textures for the characters in folders within the character folder and reference them in the UV/Image editor with relative paths. The good thing about that is the relative paths are simple such as "//textures/bird_skin_col.png" instead of "//../../textures/bird_skin_col.png" this means you just move the texture folder with the bird folder if you need to move it and it works, but if the textures are referenced before the bird and you move the bird folder you have to change paths :/ And of course with you link library to the bird blend you can link the the texture which in turn are referenced in a relative fashion.

Anyway this is all a matter of taste and organizational style but I think handling relative paths correctly is the key.