Properties supply options to the renderer, such as camera parameters, light positions and parameters, shader names, and so on.

Many properties are renderer-specific, though some properties that are common to all renderers, such as camera focal length, will be the same for all renderers and automatically translated into the appropriate renderer option by the properties system. Basically, the properties system maintains a list of properties the renderer knows about, and list of properties defined in Houdini, and maps between them.

The new properties-aware mantra, RenderMan, Alfred, and other render driver nodes use Python scripts at render time to translate the scene data and properties sent from Houdini into IFD (for mantra) or RIB. The combination of property inheritance and scriptability makes the property system extremely flexible.

The key feature of properties is inheritance. You can properties at any of several levels, and properties at more specific levels override properties at more general levels.

The inheritance order is:

• Renderer defaults – if you don’t specify a property, the renderer uses its built-in (or configured) default value.

• Output driver

• Material

• Objects

• Primitives – See per-primitive properties below.

At each level you can specify properties specific to that level. Any properties you define at higher levels are inherited by lower levels, so you can specify a default shader at the output driver level. Even though the shader definition is meaningless on an output driver, it’s inherited as the default by all objects rendered through that driver.

Properties at a lower level override properties at a higher level, so for example you can specify a surface shader on the object, and override it per-primitive.

In practice, inheritance is somewhat limited by the fact that, for convenience, Houdini automatically adds common properties, such as light mask and default shader, to every object created, so every object will override any light mask or default shader you add higher up the chain (such as on the camera or output driver). However, a TD can edit the list of default properties added to new objects. See advanced uses below.

Technically, properties are spare parameters. You can add them to a node using the Edit Parameter Interface window.

See the section on Inherence above for the different “levels” at which you can add properties.

1. Select the node you want to edit.

2. In the parameter editor, open the Gear menu and choose Edit Rendering Parameters.

See the Edit Parameter Interface window help for information on how to add and remove properties.

Once you've added render properties you can edit their values in the parameter editor.

You can attach them to renderable nodes (such as objects). You can also use a Properties SHOP to hold properties and refer to it from renderable objects.

Houdini decides what default properties to create on new objects. There are usually more properties available than just the defaults. You can add properties, or remove properties to clean up the interface, allow inheritance, or save memory.

• The Properties shader lets you attach arbitrary properties. Houdini will apply the shader’s properties to any object or primitive that uses the shader.

• Use the Material Palette to apply shaders per-primitive. The Material node replaces the old Shader surface node.

The properties system enables many useful and powerful scenarios:

• Override the object shader at the primitive level.

  • To set properties on primitives, create a Properties SHOP with just the properties you care about, and assign it as to the primitives you want to affect. Other primitive inherit their properties from the object.

  • Per-primitive shaders and light mask.

  • Per-primitive displacement bounds! This can be a huge performance boost: only increase the displacement bounds property on highly displaced primitives.

• Point instancing

  • You can bind properties to points, and when geometry is instanced onto the point, the point’s properties are inherited by the instanced geometry.

  • Scatter points that will be instanced as an asteroid field. You can set properties on the individual points to control the look of the instanced geometry.

  • Use a procedural shader to instance geometry onto points, with properties on the points controlling the operation of the shader.

• Define properties at the highest level that’s practical. The lower the level at which you set things, the more places you’ll have to edit when you want to change something.

• You can bypass properties (that is, have Houdini pretend the property isn’t present on a node) using a flag of the opparm HScript command.

• The Python scripts responsible for generating IFD/RIB are in $HFS/Houdini/soho.

• The dialog scripts in $HFS/Houdini/soho/parameters control the list of all available properties, as well as what properties are added to new objects.

  Each file includes a parameters/‹scriptname›.user.ds file. If you have such a file in your Houdini path, it will get imported, which gives you the opportunity to override parameter definitions and define symbols which control the operation of the parent scripts.