[Sidefx-houdini-list] Packaging and developing shaders
andy at andynicholas.com
Fri Dec 19 09:31:40 EST 2008
Thanks for taking the time to go through all of that. It makes a lot of
sense. I was vaguely aware of these things called "galleries" before, but
I'd never looked into it until your explanation.
Thanks for the heads up.
> The method used for the current gallery in Houdini is:
> - use VOP VEX SURFACE SHOP to create a shop that has a VOP network
> inside it. Parameter nodes get promoted automatically to the shop
> level and the vopnetwork is unique to this shader. this means that it
> does not create a vop type and only exists inside this subnetwork.
> - opengl tab is linked to appropriate parameters from shop
> -The SHOP is then collapsed into a subnet which turns it into a
> material node. Then either RMB on material and choose "Promote
> Material Parameter" or use the Edit Parameter interface to build your
> own UI.
> - materials can then be put into the gallery. You can even put
> different versions of the same material into the gallery with
> different parameter settings to create unique looks.
> - the galleries can be installed by other users into their houdini
> material palette and then assigned to objects or material sops.
> - by using materials you can also take advantage of the local
> parameter overrides which let you assign one material to different
> parts of your scene then use local parameter values (such as a texture
> reference) to get a unique look for each object.
> - when you place a material from the gallery into your scene, the
> instance does not retain a link to the gallery item. This leaves you
> free to dive down and change the vop network without changing the
> material in the gallery.
> - If the gallery being referenced is updated with new materials or
> with materials with different "inner" workings, the gallery will give
> you access to the new ones BUT any materials already placed into a hip
> file will NOT be updated because there is no dependency.
> If you want to link to a collection of materials that can be updated
> globally then turn your materials into digital assets and place them
> into an .otl file. When these shops which all have unique types
> (gallery items are all "material" types) then they will retain a link
> to the .otl definitions and using digital asset technology you can
> update the gallery and all hip files that reference those .otl files
> will be updated accordingly.
> By using this method, if you put down more than one version of a
> material asset the vop networks inside them are not trying to create
> vop types - in the past embedded vopnets would create multiple
> instances of voptypes making things a bit unwieldy - the new setup
> gives you more freedom both at the front end creating materials and at
> the back end managing them as digital assets.
> One thing that might confuse is that materials live in SHOPs. They are
> basically subnetworks that have special properties. You can use shops
> to build materials or other materials to build new materials....
> Hope this helps.
> PS - I DO know that we need tutorials on all this and promise that it
> is on the list......
> On 18-Dec-08, at 1:50 PM, Andy Nicholas wrote:
>> Hi guys,
>> I just wanted to draw on your collective experience on this. It
>> seems that
>> there are various ways of storing/encapsulating shaders, and each
>> has it's
>> own benefits and pitfalls:
>> 1) Compile VEX to VOP type.
>> This seems pretty useful since you can use it inside the VEX to
>> reuse it
>> in different ways. Unfortunately, you can't edit the shader as VEX
>> you have to get stuck into the code.
>> 2) Compile VEX to Shop type.
>> Seems to be the least flexible. You can't edit the nodes or combine it
>> with other surface shaders.
>> 3) Convert the entire material to a digital asset.
>> The advantage is that you can still edit the VEX nodes in the GUI.
>> 4) Convert to Vop Shop type
>> Like 2) but you can still edit the nodes.
>> 5) Keep a scene with the shader VEX nodes in.
>> Let's say that you created a set of basic shaders for general
>> use, how would you: a) Distribute them to artists, and b) Store them
>> further development and, most importantly, reuse components from them?
>> Let's assume we're just dealing with a surface shader, rather than one
>> that has, say, displacement as well.
>> I'm just interested to hear if there's a widely accepted way of going
>> about this.
>> Thanks a lot
>> Sidefx-houdini-list mailing list
>> Sidefx-houdini-list at sidefx.com
> Robert Magee
> Product Marketing Manager
> Side Effects Software Inc.
> 416 504-9876 x327
More information about the Sidefx-houdini-list