I have a layered rendering question and expect this must have come up before (I do not consider myself an Arnold expert).
The arises in a layered rendering situation and even though I am generally not a layered rendering fan, in this case, the scale makes it an absolute requirement. This needs to be treated as fact.
Consider the need to render a single mirror plane so that it is the only thing visible in the layer (i.e. it is the only thing with primary visibility on). However, imagine it is surrounded but a torus and I need to be sure the torus is properly visible in any reflections in the mirror. The torus would be on for indirect illumination calculations. Fine so far.
Now consider the case where the mirror and torus are positioned relative to the camera so that the mirror is substantially obscured by the torus. If the shader calculation for the mirror were extremely expensive to the point of being significant in my overall computation time, I would want to be able to use the torus geometry to obscure the mirror to avoid having to evaluate the shader where the mirror is obscured. I realize I would not have this problem if I were not rendering layers but I have to. I could do something like render a masking pass but it strikes me that there might be a mode like this in the Arnold itself. Is there a third or augmented visibility type (a bit like a "light blocker" which does exist) which would allow me to set geometry as only visible in secondary illumination calculations *but* also be used as a "view blocker"? Can a shader check to see if a shade point is visible using all scene geometry (primary *and* secondary)?
FWIW, I am working in Maya but once I figure all of this out, I intend to write a plugin to configure these scenes through the Arnold API. Again, I'm new to Arnold so please forgive me if the answer is obvious and I've just missed it.
Solved! Go to Solution.
Solved by Mike_Farnsworth. Go to Solution.
To make sure it is clear, in the resulting layer render, I do not want depth information about the obscuring geometry. I just want to not render the pixels on primarily visible objects where they will end up being obscured anyway.
There is a built-in parameter for Arnold shapes called 'matte' that will turn it into a black hole for camera (primary) rays, but for indirect rays its regular shader is still run. You definitely don't need to run a second matte pass to get matte effects. There is also the built-in matte shader, which will allow you to run whichever other shader you want for indirect rays, but set a flat color for camera rays.
This seems like it covers your main scenario.
Additionally, you can tweak object visibilities per ray type, for example you can make an object entirely invisible to camera rays, but show up in indirect diffuse rays; or you can make an object only visible to shadow rays to cast shadows but invisible to all other types, etc. Finally, using the ray_switch_shader built-in shader you can run entirely different shaders based on ray type. There's quite a bit of flexibility that should be able to help you cover the scenarios you mention.
Also, you probably don't need to use the API to make these setups; MtoA is perfectly capable of them. However, if you had a custom procedural DSO plugin that generated objects for you, then you would need to use the API to set these types of things up. It's fairly straightforward. You can get the Arnold node types and attributes available by introspection using kick (in the MtoA bin directory) if you want to see what's available:
List nodes available; set env var ARNOLD_PLUGIN_PATH to make custom nodes available:
kick -nodes
Get parameters and their types/defaults of a node (in this case, the polymesh node):
kick -info polymesh
Get more info on a specific parameter:
kick -info polymesh.subdiv_type
Perfect. I saw the matte section of the shader but did not get it to work on the geometry as I expected -- which is what you said would work as well. Well, I've since realized that I have to turn primary visibility *on* for the matte option on the geometry to work as expected. I guess I was trying to be too clever. This is exactly what I was looking for. Thanks for your help.