Shaders are created within Arnold Shader Network nodes. These nodes are also used for Light Filters and Environment Effects.



In the SHOP context Tab > Arnold > Arnold Shader Network to create an arnold_vopnet1 node. Double clicking or pressing "I" enters a custom VEX builder context where Arnold shaders and nodes can be networked together.

Output nodes

There are 3 types of output depending on the purpose of the shader network; Material, Light and Environment. The result of the shader network must be connected to the input of the relevant output node. Multiple Outputs of different types can be contained within the same shader network. If multiple outputs of the same type exist, Arnold will use the first one translated by HtoA.

Material Output
  • surface: To connect the color output of a surface shader like Standard or Lambert.
  • bump: Connects a bump2d or bump3d node to modify the surface normals.
  • displacement: Connect a bitmap texture (image node) or procedural texture, like noise, to displace the geometry surface.
  • volume: For connecting a Volume Collector shader.
Light Output
  • color: For attaching a shader (like a Physical Sky) to be used as the color of a light. 
  • light_filter #Light Filter nodes are connected here. As each is connected another input will appear.
Environment Output
Shader Assignment

To assign a vopnet drag it from the SHOP onto the geometry or use the Operator Chooser in the geometry Material tab.


The 'jump to operator' in the material tab will go to the Arnold shader network, rather than jumping to the shader inside. This is Houdini behavior, because you're assigning a SHOP and thus it brings you to it, not inside.

Shader List

These are the available shaders and nodes.

Core Shaders
AOV Read/Write
  • AOV Read Float
  • AOV Read Int
  • AOV Read RGB
  • AOV Write Float
  • AOV Write Int
  • AOV Write RGB
User Data
  • User Data Float
  • User Data Int
  • User Data RGB
  • User Data RGBA
  • User Data String
Shading State
  • State Float
  • State Int
  • State Matrix
  • State RGB
  • State Vector
Ramp Shaders
  • Ramp RGB
  • Ramp Float
Math Shaders
  • Abs

  • Add
  • Atan
  • Cache
  • Complement
  • Cross
  • Divide
  • Dot
  • Exp
  • Fraction
  • Invert
  • Is Finite
  • Ln
  • Log
  • Max
  • Min
  • Mix
  • Modulo
  • Multiply
  • Negate
  • Normalize
  • Pow
  • Reciprocal
  • Sign
  • Sqrt
  • Subtract
  • Trigo
Matrix Shaders
  • Determinant
  • Matrix Berp
  • Matrix Frame
  • Matrix Invert
  • Matrix Lerp
  • Matrix Multiply
  • Matrix Multiply Vector
  • Matrix Transform
  • Transpose
Utility Shaders
  • Cache
  • Clamp
  • Color Correct
  • Compare
  • Fetch
  • Length
  • Linearize
  • Passthrough
  • Random
  • Range
  • Space Transform
  • Switch
Data Types
  • Color Convert

  • Int To Float
  • Float To Int
  • Float To Matrix
  • Float To RGB
  • Float To RGBA
  • RGB To Float
  • RGB To Vector
  • RGBA To Float
  • Matrix To Float
  • Vector To RGB
Light Filters
  • No labels


  1. It should be great to access the low level functions of the shaders , so we can make custom 'aiStandard ' from scratch, like calling the main diffuse function or just the specular function instead of calling the full aiStandar... 

    1. (This has been answered on the list, reposting here for reference)

      It is very possible to decompose parts of the shading in elementary shaders so you can reassemble them in a bigger compound shader like you do in mantra. Actually, for just the main components of the shading, you can emulate this yourself by setting each shading component's weight to 0 save the one you wish to expose (eg. specular). The standard shader code will take shortcuts and not evaluate the code paths whose weight is zero.
      But contrarily to Mantra, the Arnold shaders are compiled C++ shaders and not a shading language that is compiled on the fly before render. This implies a performance penalty when linking lots of shaders, whereas with shading language such as VFL the entire shading tree will generate a single shader that it will then compile.
      So this decomposition into elementary bits is possible, but not advised. In fact, you should always try to have as few shaders as possible in your networks -- especially for volumes. This would of course change if / when we decide to support OSL. Please also note that, as far as I know, single OSL shaders are slower that their C++ counterpart, but very large and complex shading networks are faster in OSL.
      But there is also a more philosophical answer. One of Arnold's goals has always been about simplifying the workflow and decomposing the standard shader in subcomponents goes a bit against this philosophy. It makes my head dizzy each time I dive into Mantra's surface shader VOP network and its many subnets. Knowing a junior lighter can mess with this makes the dizziness worse. This kind of network is also difficult to debug and optimize, in other words it's a huge potential time waster in production.
      I do understand the need for each studio to tweak their own ubershader or build needs for specific shaders and Solid Angle is known to have given the source of the standard shader to selected customers. Some open source Arnold shader collections such as Anders Langlands'ObliqueFx or Kettle are also good starting points. But you may have to change some of your Mantra habbits when working with Arnold, hopefully for the simpler, so you can concentrate on higher-level creative tasks.