You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 22 Next »

SItoA provides support for ICE point clouds and strands. Custom attributes, motion blur and shape instancing are also supported.


Motion Blur

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:

  1. 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.
  2. 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.


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.

SItoA will also convert between different types. For instance, in ICE you can declare ArnoldLightColor as a scalar attribute, and SItoA will assign the same scalar value to the light color's R,G,B.

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
FLOAT         radius                            0
ENUM          decay_type                        quadratic
BOOL          affect_volumetrics                true
BOOL          cast_volumetric_shadows           true
NODE          volume_density                    (null)
MATRIX[]      matrix
RGB           color                             1, 1, 1
FLOAT         intensity                         1
FLOAT         exposure                          0
BOOL          cast_shadows                      true
FLOAT         shadow_density                    1
RGB           shadow_color                      0, 0, 0
INT           samples                           1

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.




  • No labels