[Sidefx-houdini-list] RSL vops for houdini
ld at dneg.com
Tue Feb 19 15:13:51 EST 2008
Using the inline code vop is probably the best way to get going as you
can make assets from it super quick and it's set up in a way that's
easy to manage. I really like the way you can RMB on a vex shop node and
make a vop from it. Pity it doesn't work for prman. Don't know about
parsing all your shader libraries though, sounds painful...
Mario Marengo wrote:
> On February 19, 2008 01:29 pm, Andrew D Lyons wrote:
>> We're looking at ways to incorporate a PRman shading pipeline with Houdini.
>> We'd like to procedurally build a suite of mid-level rsl VOPs
>> (specular, reflection, shadow etc) from an RSL code base, and build
>> larger uber shaders out of those.
> The only way that I know of to do this (generate VOPs with fully-defined UI
> and everything else it might need from a code base) is by writing your own
> packager -- a script (in the scripting language of your choice) that
> interprets the source (pre- and post-vcc/rsl/whatever) and builds the otl
> contents from it (including the html help, dialogue, and all other bits). Of
> course, the source in this case, has a bunch of non-vex/non-rsl symbols that
> are meant for the packager alone, so they're no longer directly compilable by
> the target shading language, but then, they mostly just forward to some
> function in the library anyway (much like houdini's built-in VOPs).
> Something like this would solve the code-to-vop problem. However, if the
> intent is that all resultant VOPs from this process are only meant as
> low-level ops that will then get used to build (manually via UI) the mid- and
> high-level components, and expect that *these* in turn will need to be
> re-generated procedurally (i.e: via make for example), things get more
> complicated. Here you'll need another script to convert the hand-edited otl
> back into single encoded source file. We have such a thing as well, but the
> result is no longer easily editable -- its only advantage at that point is
> that it can be "made" (by make or whatever) in the same way as everything
> else and doesn't need special treatment. We've only come across one instance
> of such an animal, and it's not a shading-related HDA, so "meh" :)
> That's the theory anyway. In practice, we've ended up with a mix: all the
> shading-stuff (shaders, vops, dso's, etc) that I maintain are generated from
> source as described above. Then there's a bunch of HDAs maintained by other
> people which are put under version control as-is (directly as OTLs) and which
> have to be updated by hand then resubmitted (as binaries).
More information about the Sidefx-houdini-list