Creating a variable width path that traces topological changes…

Recently on cgtalk.com in the softimage section there was a post asking for ideas on how to animate the path of a submersible devices sonar as it worked along the sea bottom.

In other words–how to make a painted or drawn path.

Many possible solutions were posted, most involving some form of extruded geometry along a curve based path, or using nulls or implicit objects animated along a path to drive a weight map.

Being somewhat curious as to what might be the easiest method (for me at least) to use I set about experimenting with each technique. In the end I came up with another that I feel for this particular need is easy to setup and fairly flexible. First though a little bit about the other techniques tried…

There were several ideas that resorted to using some sort of proximity of a path object or set of nulls to influence the shading of the sea floor object. Remember–the path needed to be painted on to the surface of this object. Each of these presented nearly the same issue.

I tested first a set of nulls that would travel along the set path’s curves and change the values of the object’s weight map using the very cool and useful LM weight map tools proximity option to drive the changes.

Using shrink wrap in the parallel axis mode I was able to have the curve match the topology of the mesh surface. Using the constrain to curve command I had roughly 50 implicit objects animating along the curve and driving a fairly good-looking weight map along the path. However, I noticed some short comings of this method fairly quickly.

The first, that it requires a fairly dense mesh to get a good line edge on the path. Second, the method was slow and heavy to animate if you tried to soften the animated weight map via the LM weight map tool’s Smooth Map option. In addition there was the serious problem that there was no way of having the weight map take into account the changing width of the beams path along the surface (see figure 1).

Fig. 1 - The changes in topolgy effecting the path width.

Lastly was the fact that the weight map was generating a path based on it’s proximity to all points in every direction!

While at first that might seem like not that much of an issue, consider what we are trying to get–a hard edge path cut by a beam. The sonar beam is represented as having a defined direction that strikes only regions within the beam–not those nearby where the beam intersects with the sea floor. What resulted was that any objects that were denser in points than those around them, even if they were outside what should be the range of the beam, were being influenced. Not what was wanted at all!

While it could account for the beam’s width the same problem was presented when trying to use geometry extruded along the path to generate a ambient occlusion mask to be used in post or the render tree. Since the ambient occlusion searches a radius, it has this same problem. While narrowing the search area of the AO helped, and was very close…it was also a relatively more render time intensive process than any of the other methods tested.

Next I tried taking a path and extruding a beam shaped object along it to use as an animated Intersect boolean. This, in theory, would cut along the path correctly taking into account the width changes in the beam on the surface. While it did work 75% of the time anyone who works a lot with booleans will tell you they can get messy quickly, and often will not work at all. In addition, for this method, quite a dense mesh was required for the sea bottom and the slicing, beam path object. As to be expected this made for some SLOW scene editing and animating etc. when the objects were not hidden from view. In the end, while it worked, I found it too slow and cumbersome to work with, in addition to being buggy and inconsistent.

Frustrated, I tried something a tad simpler, in that I took the extruded along a path beam object, scaled it near flat on the Y axis, and then shrink-wrapped it to the sea floor object. OK, so its probably obvious that that didn’t work either, as that would not give you the variable width needed. Here is a rough animation of what that looked like.

At about the same time I tried taking another, simpler animated extrusion, and using it to generate a mask on the surface via a raytraced shadow from a distant light pointing straight down. The path object was hidden from primary rays, and the sea floor surface was given a Lambert shader, while the light was jacked up to the point where the lambert was blown out white, and the shadow was pure black. This mask would later be inverted in post. This effect could have most likely been achieved in the render tree without such brute force over exposure… but where is the fun in that? While this method worked… it suffered from what the previous example did in that the path (duh) wouldn’t be variable width! Brilliantly simple and stupid all in the same go!

Then it dawned on me–why in the heck don’t I just run the animated beam extrusion object with a constant white color through the sea floor with a constant black color and generate a mask that way? So I set up a pass with the correct constant colors, and used an orthographic camera from straight above to record the mask, and then re-apply it to the surface object for another pass mask pass to be viewed from the “normal” scene camera.

Well I’m happy to say that this was not only the easiest method to setup and use, but also worked well in post. It’s logical and not cumbersome… and requires very little experience on the XSI user’s part, which is good since we were all in the original post trying to help someone who was very new to XSI, and rendering techniques in general. In addition you’ll notice there are no problems created if the path overlaps its self like there could be with some of the other methods.

Here is the texture map generated from an orthographic top down view that was later applied back to the sea floor object and used to make a mask pass for the beam. Note–the constant colors are inverted from what they should be.

Here is final quick comp and animation. Keep in mind I did this fairly quickly…and in a slap-dash fashion so it isn’t 100%. You’ll need to take just a slight bit more care if you use it in your production of course…

My next post will give a quick step by step of how to set this up. Please leave comments if you think there is a better way, or something I missed that could make things easier/better. I know there must be a million and one ways to do this (like with particles)–all with their differences in learning curve, setup time, and flexibility. I’d love to hear them!

If you’d like to look at my hacked up, quick and dirty scene I made for this technique you can download it here.

Known limitations–where to start!?

Well first of all geometry with overhangs and caves wouldn’t work with this technique in its current form and the beam would act more like an x-ray that was penetrating the rock. A combination of shrink wrapping and this technique could potentially fix that issue though. Also–what if the scanning object rotated on its local banking angle? That would probably require something more along the lines of a bi-rail extruded object or some other method to alter the beams orientation in the right way. What about making the beam turn on and off- and not using post “hacks” to accomplish that?

Needless to say- there could be quite a few depending on what is needed for the scene- hence this is a simplistic solution to what should be a simple version of the problem of drawn and animated paths.