understanding normalizing of a level set

[Steven Caron]

I am looking for information to better understand what normalize is doing and why I would need to use it. I am using a custom OpenVDB implementation inside Softimage, I recently exposed the LevelSetFilters and I am noticing some undesireable shapes and was wondering if I should be 'normalizing' the levelset after certain types of operations.

Thanks

Steven

[Ken Museth]

Hi Steven,

You might already know this but allow me to back up a little and set the stage for level set operations in general. Level sets in VDB are represented as a narrow band of signed distance values around the zero-crossing, i.e. surface from which the distance values are computed. All level set operations, like the LevelSetFilter, need to account for the movement of this zero-crossing as values in the narrow band is modified. This process is called interface-tracking and involves several stages (see section 4.2 in my VDB paper) that can be summarized as: add values to the narrow-band by topology dilation, renormalize the values by solving the so-called Eikonal equation, and finally remove boundary values from the narrow-band that are too far away from the new zero-crossing. All level set tools in OpenVDB that deform the surface performs this operation under the hood - including  for instance LeveSetFilter and LevelSetAdvect. So in your case performing an additional re-normalization shouldn't be necessary and might in fact smooth the surface (due to numerical dissipation). The fact that you're observing artifacts (can you share them with me?) suggests that the deformations are too aggressive in the sense that the surface is moving so fast that the narrow-band rebuild algorithm fails to track it. In most cases my algorithm tries to account for this (by computing CFL conditions and performing sub-steps) but given all the possible combinations of numerical integration and discretization schemes it's entirely possible that you've found a corner case that breaks the fundamental assumption of interface-tracking. Thus I'm very interested in hearing more about your application - please shoot me an email (mus...@acm.org). Lastly I want to mention that there is an interesting alternative to the "Renormalize" tool which is very useful when you're dealing with situations where you've performed non-level-set operations that makes it difficult to "restore" the values to signed distances by solving the Eikonal equation. This tool is called "Rebuild Level Set" and is also exposed in a Houdini SOP. It is much more robust (but also slower) in that it extracts the mesh surface of the zero-crossing and computes an exact narrow-band signed distance field from the mesh. Try it and see if your artifacts disappear ...

Hope this was helpful,
Ken

[Steven Caron]

Thanks again for the detailed response Ken, I had a feeling my deformations were too aggressive and it was causing some artifacts. The project I was using the OpenVDB library/tools has wrapped and I unfortunately cannot share any data from it (unreleased and the client wouldn't give us permission either). BUT I did implement the "Rebuild Level Set" tool in my custom Softimage implementation and I found it addressed most of my issues. It didn't really answer my fundamental question about normalization so I didn't follow up this thread as if it was 'answered'. Your explanation was helpful for me. My work on the plugin integration of the library is on hold but I am looking forward to getting the new 3.1 features (density advection!) working...