Community
Arnold for Houdini Forum
Rendering with Arnold in Houdini and Solaris using the HtoA plug-in.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Custom VOP Wrappers for OSL Shaders

4 REPLIES 4
Reply
Message 1 of 5
mmarengoKAM7M
270 Views, 4 Replies

Custom VOP Wrappers for OSL Shaders

Hi all,

I'm new to Arnold (though experienced with other renderers) and currently exploring HtoA specifically.

I noticed that Arnold/HtoA will automatically generate VOP wrappers for any .osl/.oso files it finds in ${ARNOLD_PLUGIN_PATH}, which is nice, but I need to define a few VOP wrappers by hand (because they have complex interface requirements).

The typical workflow in, say, Renderman, would be to generate a vanilla VEX Vop whose shader name is the osl function, and set it up up as an external shader, but I haven't yet had any luck using similar approaches with HtoA -- that is, none of my custom VOPs get picked up by the HtoA network parser and so do not get put out to the .ass file.

Is there a specific attribute that the HtoA network parser looks for inside the nodes of a material network is order to recognize it as an OSL shader wrapper?

As an aside, I'm currently trying to reverse-engineer it from the auto-generated ones, but this has not yet yielded anything useful, so here I am 🙂

TIA!

Labels (4)
4 REPLIES 4
Message 2 of 5

Well, I just noticed that the auto-generated nodes convert all outputs to hidden parms (tuples and single-components) with the following custom tags:

  • arnold::shader_parmname
  • arnold::shader_component
  • sidefx::shader_parmname
  • sidefx::shader_parmtype

Which is interesting, but not sufficient... hmm... looking at the Python API for further clues (just noticed the Python API and what appears to be much of the network scanning logic is in there), but if anyone can throw me a bone I'd appreciate it, thanks!

Message 3 of 5

Turns out this is a bug in the network scanning part of the SOHO libs (I'm testing with HtoA-6.0.1.0 and Houdini-18.5.696)-- specifically, the function vopKind() in the module htoa.material

The problem is that it assumes that any VOP which returns a non-empty type().definition() must therefore be a Subnet HDA (i.e: an HDA with children) and reports it as type "hda" to the caller inputShaderVop() which then proceeds to dive into its children to continue the recursive scan.

But, of course, this is not necessarily the case: HDAs that represent single Nodes (no children) are just as common as the subnet type (with children), and a typical "OSL VOP HDA" is one such.

I'm not sure where one sends RFEs or bug reports, so please let me know so I can send a more detailed report. For now, I'm circumventing this issue by monkey patching that function inside 456.py so I have a workaround, but it would be better if it were fixed at source.

Cheers!

Message 4 of 5

@Mario You can send your detailed report to support @ arnoldrenderer dot com



// Stephen Blair
// Arnold Renderer Support
Message 5 of 5

Will do. Thanks, Stephen!

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums