[Sidefx-houdini-list] Packaging and developing shaders
andy at andynicholas.com
Sun Dec 21 15:33:51 EST 2008
So the downside to using the VOP VEX Surface SHOP is waiting a short
amount of time for it to compile? Is that right? If so, then I can live
with that. The added amount of flexibility that it gives being able to
jump into it and modify it is great.
For me, I think some of this stuff needs a slight rework to make it easier
for artists (as opposed to TDs) to work with. The galleries provide a
wealth of materials to the artist, but how often does an artist want to
use a shader in its original form? For example, lets say that the artist
wants to use the "Basic Surface" material preset as the lighting model. If
they then want to use a fractal noise to drive the opacity, or say a color
map to drive the specular roughness, then there's no way to hook that up
without diving into the inner workings of the shader.
If it's a complex shader, then this might not be an easy thing to do, even
if the artist is technically able. There's also the question of whether
it's an appropriate thing to do anyway, with regards to maintaining a
consistent pipeline. You wouldn't want to have to maintain 10 different
versions of a basic shader so that it could support all the different
texture types driving the parameters.
Stuff like SOPs works well, since an artist can string together VOP based
tools and not worry about the internal workings. In that case you've got a
good logical separation and encapsulation while still allowing the artist
to experiment, but the SHOPs/Material system doesn't seem to have that. I
guess it's easy enough to encapsulate some VOP SHOP types and allow the
artist to fiddle around in there, but the logical separation is still not
very distinct. It's also a pain in the backside to have to keep on messing
around with the parameter layout in the SHOP output to get the GUI looking
okay, especially with shaders that have a lot of parameters.
Anyway, galleries seem to solve my current needs, and since it's just me
working with Houdini at The Mill it's not a major issue at the moment. I'm
just thinking ahead for situations where I might possibly want to get a
few of the XSI or Maya guys helping me out on a project.
Thanks for your thoughts Pablo. Have a good Christmas.
> 2008/12/19 Andy Nicholas <andy at andynicholas.com>
>> Hi Robert,
>> 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,
>> I'd never looked into it until your explanation.
> Very close to the way we managed materials in Cities on Water Andy ....
> Except the we didnŽt use galleries, we used pressets which is not so cool.
> The only problem about using the VOP VEX Surface SHOP is that it needs to
> compiled ever time the materials is used, basically all the network is put
> into the hip file, which is something flexible but not always desirable.
> There is another approach where you mix you our code using inline VOP and
> other VOP operators to create a new SHOP type, so you compile your shader,
> later you can use this SHOP into a material, create your own interface for
> the material, and put everything into and OTL.
>> 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.
>> > Robert
>> > 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
>> >> nodes,
>> >> 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
>> >> 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
>> >> production
>> >> use, how would you: a) Distribute them to artists, and b) Store them
>> >> for
>> >> further development and, most importantly, reuse components from
>> >> Let's assume we're just dealing with a surface shader, rather than
>> >> 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
>> >> Andy
>> >> _______________________________________________
>> >> Sidefx-houdini-list mailing list
>> >> Sidefx-houdini-list at sidefx.com
>> >> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>> > ----
>> > Robert Magee
>> > Product Marketing Manager
>> > Side Effects Software Inc.
>> > www.sidefx.com
>> > 416 504-9876 x327
>> Sidefx-houdini-list mailing list
>> Sidefx-houdini-list at sidefx.com
> Un saludo
> Best Regards
> Pablo Giménez
More information about the Sidefx-houdini-list