[Sidefx-houdini-list] RSL vops for houdini

Louis Dunlevy 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:
>   
>> Hi,
>>
>> 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).
>
> Cheers.
>
>
>   




More information about the Sidefx-houdini-list mailing list