FastSweeping: Support for one direction dilation and field extens…

[apradhana]

This PR adds support for one-direction dilation and extension of a field. To achieve this there are a few notable changes to the FastSweeping tool and SOP Extrapolate:

• Add an enum for sweeping direction (SWEEP_DEFAULT, SWEEP_GREATER_THAN_ISOVALUE, and SWEEEP_LESS_THAN_ISOVALUE). I also add mSweepingDirection as a member function of the FastSweeping class.
• Add mExtGridInput as an optional member of the FastSweeping class to provide a default voxel value for the SWEEP_GREATER_THAN_ISOVALUE and SWEEP_LESS_THAN_ISOVALUE cases.
• Bump isInputSdf as a member variable of the FastSweeping class.

On my TODO List regarding FastSweeping that are not addressed by this PR:

• Add support for mask grid and extension grid input not having the same transform as the fog/SDF grid input.
• Revisit the TestFastSweeping debug build.

[kmuseth]

Please see my comment related to performance. Another much less serious comment is about the terminology used for this feature. "sweep direction" has a very specific meaning in the context of the fast sweeping method. Specifically, in 3D it's the 8 diagonal direction. However, your choice of terminology (cf. enum FastSweepingDirection) seems to suggest that there are other (new?) directions introduced with your changes. I would argue that you're not really changing the sweep directions (there are still the same 8), however your changing the mask or domain in which the 8 sweeps are applied. Long story short I would prefer you rename FastSweepingDirection to FastSweepingDomain :)

[kmuseth]

I'm concerned about these two extra branch tests in the inner-most loop of the old Fast Sweeping algorithm. Have you tested the performance impact? Is there no way of extracting those if-statements into three different kernels - at least so the 99% default cause is not negatively impacted by the new (arguably rare) cases?

[apradhana]

I had a test with extending a Cd grid from a sphere to a box with 215 million voxels. Before this change, the timing is 12.613s. After the change, I get the following timing:

• SWEEP_ALL_DIRECTION = 12.645s
• SWEEP_GREATER_THAN_ISOVALUE = 12.929s
• SWEEP_LESS_THAN_ISOVALUE = 12.652s.

So sweeping in a given direction does make the algorithm go slower by about 2% in this case.

I think we can rid of these two extra branches by making mode as a template and making the SOP to dispatch the correct instantiated template based on the user input. Let me know what you think.

[kmuseth]

@apradhana thanks for looking into this - I think 2% is small enough that it shouldn't block this PR (I'll approve it). At some later time it would be great if you could allow for the the two code path to be selected at compile-time (say with a boolean template parameter) so as to avoid the (granted) small overhead.

[apradhana]

Thank you @kmuseth. I started taking a stab at it, but couldn't finish it on time. That's my homework for the next iteration.

[jmlait]

The conflict is because you tried to re-use an existing pending_changes which got merged in the mean time, each PR needs its own unique pending_changes file.