dennis.albus

You want to write it like this: exec(hou.node('/obj/geo/subnet/py').parm('python').eval());onClick() Or even better relative to the current node: exec(hou.node(hou.pwd().path() + '/subnet/py').parm('python').eval());onClick() kwargs is a prefilled dictionary that contains information about the current node, the parm that has been changed/executed and can be used as a convenient way to grab that information in your code. You can simply run print(kwargs) to see what information it contains.

Setting environment variables with python from inside a running Houdini instance is messy and not working as expected. I've had more success using the equivalent hscript commands. hou.hscript("setenv JOB = foobar") hou.hscript("varchange JOB") # this is optional and probably not needed in your case Hope this will work for you. Cheers, Dennis

There's a mismatch between the Arnold version (4.2.11.2) and the version that alShaders have been compiled with (4.2.12.2). Try and install the matching HtoA version and see if that fixes your problem.

While Arnold is not particularly picky about this, there are certain combinations that don't work well together. Ideally you have an HtoA version for the specific Houdini version as well as alShaders compiled for exactly the same Arnold Core version as HtoA. Could you launch Houdini from the commandline tools and copy the Arnold log in here? If the env is set correctly Arnold will tell you that it tries to load the plugins from the alShaders location. If something goes wrong (like non compatible versions) it will load 0 (zero) plugins and also print that to the log. Cheers, Dennis

Hey, I've also seen this problem and for me it was related to an issue with the Curvature VOP. Are you seeing any error messages or warnings on your material node? Simple solutions are: keep the shader locked get rid of the curvature VOP use the principled shader Cheers, Dennis

Here's basically the same setup but this time in VOPs. Hopefully this is even more useful, especially for people not comfortable with code. I was struggling with this as I tried to do it in a fog shader, but the pbrlighting VOP was not available in that context. Doing it in a material shader context solved this problem. Just be sure to export your needed variables (all_comp in that case) into the fog context and not only into the surface context. reflectionPass_pathtracer_vop.hip reflectionPass_pathtracer_vop_simpler.hip

To get exactly what you are looking for I actually had to customize a little bit more. This is neither recommended nor a good way to do it (it is just hacked for this single case). I basically made the same changes that I did in the fog shader, but this time directly inside the pathtracer that mantra uses for rendering. This way we get access to all the export variables (AOVs). Note that I did not change the actual pathtracing, but only the results!!! Heres what I added: // Custom Exports export vector4 torus_reflection = 0; .... // custom code goes here string object_name; renderstate("object:name", object_name); if (object_name == "/obj/torus_object1") { torus_reflection = direct_comp[1] + indirect_comp[1]; // sum up the direct and indirect components Af = 0; // set Alpha to zero for the color channel Cf *= Af; // premultiply the color channel } You can see the full code when looking at the code section of the pathtracer vop node. Maybe this is interesting to someone. The problem is interesting enough that I will spend some more time with it and see if I can find a better (more convenient) solution. Cheers, Dennis reflectionPass_pathtracer.hipnc

I am not 100% sure if this is what you want. I've used a fog shader to adjust the final output color / alpha before they get written into the actual AOVs. reflectionPass_fog.hip

I agree that this is important. However for this purpose we use a node coloring scheme (all nodes are colored automatically upon creation). From far away this is even easier to read and distinguish than different node shapes.

Love the new VOPs nodes with thumbnails. That was long overdue. Could have a bit flatter look for my taste but whatever ... I am however VERY sceptical about the look of the other networks. Way too playful. The idea of having customizable node shapes is great, but keep the defaults simple and unobtrusive. Use simple shapes to distinguish the different node types (rectangle, rounded rectangle, chamfered edges, oval etc.). Keep the node flags in the same place for the nodes. If that's not possible with different node shapes use a different approach like Katana which has two squares (always left and right of the node name). The node inputs and outputs also look very small which makes it harder to quickly connect nodes. I also hope that there are new methods to connect nodes. I am thinking about a click-output + drag + release-on-input mechanism (painting the connection) instead or in addition to the old click-output + click-input. Regarding the adaptive sampling: Will this be a pixel-variance based adaptive sampling which is generating more AA samples when needed (like VRAYs adaptive sampling)? I really hope the answer is yes

Nope, but now that everybody seems to be doing it (Redshift, VRay) it might be a good idea. I am a big fan of having a common shader across renderers that is NOT the Disney stuff

You can also use primitive attributes and access them in a shader which should give you the accuracy / sharpness that you expect. -dennis

Well I always use Raytrace in favour of PBR as I have the pbrlighting code right inside my shader which means it's very easy to hand over per shader information that I can use in my customized pbrlighting code. I also like the fact that I can tweak the result of the lighting calculation inside my shader and fiddle with the output variables and AOVs. I just think it's a more flexible system than PBR which basically just hands over the information from the output VOP to the pbrlighting code without the possibility to directly do something with the result.

I don't think we need to keep the distinction between Raytrace and PBR though. And I am sure that one will be deprecated pretty soon. But I totally agree that we should keep the Micropolygon hider at any cost. It is still soooo useful

Hey there, the script parameter of the python node is not where you want to put your callback scripts. It is meant for processing incoming geometry. You need to create a new Digital Asset definition and put the callback script into the hdaModule. Go to the Type Properties of your HDA and select the script tab. From the Event Handler dropdown menu select "Python Module". Write your "onButtonPress" funtion in there (it can have any name you want). Now you can call that with a button callback script. hou.phm().onButtonPress() # hou.phm() is a shortcut to getting the current node's hdaModule If you want to have a user editable script in your node you can run it like this: exec(hou.pwd().parm("python").eval()); onButtonPress() Cheers, Dennis