SItoA provides support for ICE point clouds and strands. Custom attributes, motion blur and shape instancing are also supported.
Currently the following point shapes are exported as Arnold primitives: Point, Disc, Rectangle, Sphere, Box, Cylinder, Cone. The Blob shape is not supportedAlso, SItoA supports ICE geometry instantiation of plain geometries, models, and stand-ins.
ICE examples: a bunny model covered with particles using the sphere primitive (left) and instanced tanks (right)
Plain ICE Strands are rendered using Arnold's curves primitive.
The following attributes are used, if available:
- Size / StrandSize for constant / varying thickness.
- Orientation / StrandOrientation for constant / varying orientation.
- Color for constant or uniform (one color per strand) color and StrandColor for varying color.
And this is the same scene, instancing a cone along the strands:
You can instantiate meshes and models. The pointcloud's attributes (like the color in this case) are also exported as constant values for each instanced object. Since the geometry of the master objects is deformed by the strands, each shape is exported as a separate shape, and not as an Arnold instance. Here is a cube shape, which gets twirled by the strand orientation:
If no instance shape is in place, you can orient the curves primitive along the strand orientation directions. To do so, apply an Arnold Parameters property to the pointcloud, and set the Curves Mode to Oriented Ribbon (ICE Strands).
This is the same scene rendered with oriented ribbons:
In ICE, each particle has many attributes such as age, rotation, color, size, etc, which can be read in the pointcloud's rendertree by the Attribute (Color, Scalar, etc.) shaders.
To export a custom attribute you may want to use in the rendertree, you will need to add a "Set Data" node that assigns the data to an attribute. There is one exception: the color attribute is always exported so you don't need to assign it manually.
Assigning a random scalar value to a custom attribute called 'HueOffset'
To have motion blur on points or strands, SItoA uses the following attributes:
- PointVelocity for linear transformation motion blur.
- AngularVelocity for rotational motion blur. Note that this attribute does not come for free, you have to set it in the icetree as shown in the snapshot: get the rotation, subtract it from the one at the previous frame, and multiply it by the frame rate. This way you have the angular velocity (radians per second). Finally, set this data as Self.AngularVelocity.
- StrandVelocity for linear deformation motion blur on strands.
For cases where sub-frame motion blur is needed, you must enable Exact ICE Blur in the rendering options.If enabled, SItoA does not require the velocity attributes to be defined for points and strands. Instead, the pointcloud geometry is evaluated at all the motion blur times, so giving much better results. But there is a price to pay, since it requires evaluating the geometry several times, which can be quite expensive. And, there are two limitation:
- The pointcloud must be cached to disk with a number of subframes per frame at least equal to the number of deformation motion blur keys.
- It does not work for pointclouds with varying number of points per frame (for instance, basic emissions). It will be automatically disabled, but you should do it yourself in advance to save time to the exporter.
See the rendering options documentation for further details.
Shading with attributes
For objects and strands, you must get the desired attribute by one of the Attribute_* nodes in the rendertree.
Same scalar attribute used to drive the Hue offset in the ColorCorrection shader
Example render with no hue offset (left) and with hue offset (right)
Instanced lights with attributes
For instanced lights (SItoA light shaders are not texturable), we rely on specific attributes' names. Any attribute whose name starts with "ArnoldLight" (case insensitive) is treated as a candidate for setting a given parameter on the instanced lights.
What follows "ArnoldLight" is used as the parameter name to be set. The parameter names used are not those of the light shader. The parameter names refer to the Arnold node used for that light.
For instance, all the light nodes in Arnold have parameters called "color" and "intensity".
So, you simple have to set two attributes called ArnoldLightColor and ArnoldLightIntensity, and they will be automatically pushed as the value of the corresponding parameters of the Arnold lights. There is no need to do anything in the light rendertree.
Note that, not being pulled by any rendertree node, you must force ICE to export the ArnoldLIght* attributes, for instance by displaying their values in the viewport, as showing below.
You can set light parameters of type point, vector, color, scalar, integer and boolean.
To get the full list of the parameters for a given light type, use "kick -info <node>". For instance, for a point light, kick -info point_light returns this:
Type Name Default
------------ -------------------------------- -------------
POINT position 0, 0, 0
This tells you that, for instance, if you want to affect the shadow color, the correct attribute name to set in ICE will be ArnoldLightShadow_Color (again, case insensitive).
Instanced stand-ins with attributes
Similarly, SItoA allows for stand-ins driven by ICE attributes.
You should proceed as usual when instancing standins on a pointcloud. Then, if the standin property has the string "ArnoldProcedural" set for the path and/or the data, then it will be exported by ICE as an Arnold procedural node. In ICE, any attribute starting with "ArnoldProcedural" is a candidate for setting the corresponding procedural parameter.
In the example shown below, we set ArnoldProceduralDso to point to an .ass file (depending if the point id is even or odd), and set ArnoldProceduralData to void. "Dso" and "Data" are the names of the parameters of the native Arnold procedural node. We can then set any of the procedural parameters, as long as you we use the original name of the attribute (kick -info procedural) after ArnoldProcedural. For instance, ArnoldProceduralSelf_Shadows, etc., the same way we did for lights (see above).
If Path is a valid dll (meaning that Data must be set equal to "ArnoldProcedural" to be managed by ICE), then the dll path is used, and you can just set ArnoldProceduralData in ICE to have the same dll using different data for different points.
If Deferred Loading is on, then the standin object bounding box is used (the asstoc file is not used, even though selected in the standin property). If you need to set or overwrite the min and max boundaries (for instance if using your own custom procedural), you can push two extra 3D vector attributes named ArnoldProceduralMin and ArnoldProceduralMax.
Note that, not being pulled by any rendertree node, you must force ICE to export the ArnoldProcedural* attributes, for instance by displaying their values in the viewport, as shown below.
Also, while rendering, you may get some warnings from Arnold about names being reused; these warnings can be ignored.