Even though you have cached the simulation as described in the previous page, you may observe Arnold rendering the motion-blurred pointcloud misplaced in time, and/or with some kind of a banding effect.
This page explains why Exact ICE Blur doesn't (always) produce the expected result, and, in any case, how to tune the caching and motion blur parameters to fix the problem.
To begin, we have to understand the relation between a cached sequence (Exact ICE Blur can work correctly only if Softimage is in cache-reading mode) and the frame time at which the geometry is pulled from inside an operator (in our case, the SItoA ICE module).
The easiest way is by an example. I have created a poincloud made of a single, straight, strand. The strand's points have their X coordinates set equal to the current frame time by an expression (Value=Fc) . So, for instance, at frame 5, all the strand's points have their X=5.
We now cache the sequence on file, with Subframe Sampling set to 2. This means that we'll have on file the strands saved at frame times 1, 1.5, 2, 2.5, etc.
In SItoA, I edited the code, so that, upon pulling the geometry, the X coordinate of the first point of the strand is logged. So now I switch in cache-reading mode, and I start playing with the motion blur settings.
I go to frame 3 and set Lenth = 1, Position = End of Frame.
With 3 motion steps, SItoA asks the geometry at frame time 2, 2.5, 3 and logs the following:
This is a perfect match between the cached times and the motion blur times, so the render performs perfectly.
However, let's now increase the number of keys to 5.
Here comes one of the problems: when SItoA asks for the geometry at a frame time other than one saved to disk, Softimage returns the geometry at the "ceiling" time.
For time=2.25, Softimage does not find on disk a cache file for it and returns the one at time=2.5 (remember that x=2.5 means "the x position at time 2.5").
The same happens for time 2.75, which gets the geometry at time 3.0.
So, you have what we can call "biased" motion blur because 2 keys out of 5 are the same, and Arnold weights the blur accordingly.
And, things can also get worst. Let's set Position = Center of Frame, Deformation Keys = 2, Length = 0.8
You would normally expect to have the motion blur centered around the strand, but instead, it's all shifted away (which is really ugly, if you have some skin under the hair)
The reason is the same as described above. At the time of the first key (3-0.4 = 2.6), Softimage returns the geometry at frame time 3, so the result is all shifted ahead in time.
So, how do we fix this?
1. Set the frame duration so that the motion blur times are easy to compute. Avoid 0.49 when you can use 0.5, and let this number be easily dividable by the number of keys.tSo, for instance, if you plan to use 7 motion blur keys, use 0.7 (or a multiple of 0.7) as your motion blur length because the key time for frame 3 will be:
Start On Frame: 3.0 3.1 3.2 3.3 3.4 3.5 3.6
Center On Frame: 2.7 2.8 2.9 3.0 3.1 3.2 3.3
End On Frame: 2.4 2.5 2.6 2.7 2.8 2.9 3.0
2. Cache the simulation so that no more than one cached subframe falls into 2 or more motion blur times. So, in our example, you should cache with Subframe Sampling = 10
So, to recap, we can state the following:
- Given a cached sequence, increasing the number of motion blur keys does not necessarily mean increasing the motion blur quality.
- The number of subframe sampling steps must be equal or bigger than the number of motion blur keys.
- The subframe sampling step must be chosen so that one cached frame exists for one and only one motion blur key.
One final note to describe another possible source of troubles. I had a scene that refused to return the correct strands position, although I had set the caching and motion blur parameters as described above. The Subframe Sampling was set to 4, but then I discovered that displaying the value in the viewport, it would show 1!
It was probably a scene initially simulated in Softimage 2012 and then imported in 2013, where the sampling controls were modified, and some changes are needed when migrating the scene, as described in the online doc under the "Updating Scenes and Compounds to Use Subframe Sampling" section. By following these steps, I had my attribute showing 4, and the cache writing/reading finally performing correctly.