The first thing to do is to select all the nodes currently in your geometry network (inside the “trails” object), and click the little icon shaped like a box to create a “Subnet” object (see Fig. 1). This groups your whole network together into a nice little package, complete with inputs and an output.

Fig. 1

Double-click the Subnet to see your original network. The first thing you will probably notice is that there are four little boxes in your network called “Sub-Network Input #1-4.” These are placeholders for the four inputs you saw on the Subnet node itself. Whatever you plug into the input #1 of your Subnet will then output from the box labelled “Sub-Network Input #1.” We’ll only be using the first input here, since the only shape information we need is the object we’re emitting trails from. Connect the output of Sub-Network Input #1 to the first input of your network, which should be the Time Blend SOP.

Now we need to start going through our network and looking for attributes that we’ll want to be controlling. This part will take a while, since it’s not necessarily obvious which channels you’ll want to have control over from the very start, but fortunately it’s a pretty easy process once you’ve done it a few times.

Going down the network, the first parameter we’ll want control over is the Seed parameter of the Sort SOP. This controls the random seed that determines which points are selected for emission. In order to control this parameter, first we have to go back up to the Subnet node, and start adding parameters. Select the Subnet node, go to your Parameters window and click the little icon shaped like a gear, then choose “Edit Parameter Interface.” You can also just right-click the Subnet node and choose “Edit Parameter Interface” from there. What you’ll get is a big scary window that looks like Fig. 2.

Fig. 2

On the left side is a list of parameter types: Buttons, floating point numbers, strings, integers, vectors, etc. In the middle is the existing parameter structure of your selected node, which right now is just four String parameters grouped together under the “root” of the parameter interface. On the right side are the settings for the selected parameter. You won’t be able to edit the built-in Subnet parameters quite yet, but you can add as many of your own as you like.

Since the Seed attribute is an integer, start by dragging an Integer parameter from the left pane into the center pane. If you were to click “Apply” at the bottom right now, you’d see a new parameter pop up in your Parameters view, with a label “Label” and a value of zero, with a slider next to it. We can change those values using the right-hand Parameter Description pane. The “Name” is the parameter name as Houdini sees it. Let’s call it “pointsSeed.” The Label is what the user sees, so type something a little prettier like “Random Seed.” The last thing to do here is set a range, since by default the slider will only go from zero to ten, which is not very many values for a random seed. Check “Range” and then set the maximum value to something huge, like 10,000. Hit “Accept” and your Parameter view should update to reflect the new changes.

Now we have to connect this parameter to the Seed value of our Sort SOP inside the Subnet. We could type in the channel name manually, but it’s much easier to just right-click the new Random Seed channel we made in the Parameter view, and select “Copy Parameter.” Next, jump inside the Subnet and select the Sort SOP. Right-click the Seed parameter and select “Paste Copied Relative References.” The expression for this value will appear as something like ch("../../pointsSeed"), which is looking for a channel called “pointsSeed” on the parent of the Sort SOP (which is the Subnet node) and returning its value. Now we can control this from the Subnet! On to the next parameter.

There are a lot of parameters on the POP Network that we’ll want control over: the Start Time, Preroll Time, Random Seed (again), and Oversampling parameters all have potential to be tweaked by the user. Jump back to the Subnet, open the Edit Parameter Interface window, and create four new controls: Start Time (float, variable name startTime), Preroll Time (float, variable name prerollTime), Random Seed (integer, variable name seed), and Oversampling (integer, variable name oversampling). If you want to set default values for any of these parameters (to match the ones that work for your current simulation, for example), you can go to the Channels tab of the Parameter Description pane and set a default. Once the parameters are all added, then you can copy each parameter and then paste the relative reference to the appropriate channels on the POP Network node.

Another way to create parameters on your Subnet is to create them based on another node that already exists. This is really handy for more complicated control structures such as dropdown menus. As an example, let’s say we want a control that can choose the type of noise that affects our waveform (sparse, hermite, etc). The original channel is in the “noise1″ CHOP in our CHOPnet. Under the Create Parameters pane of the Edit Parameter Interface window, go to the “From Nodes” tab and find the noise1 node inside your CHOPnet. Open up the tree view, and inside you will find several folders of parameters. In the “Noise” folder, there is a channel called “Type” (variable name “function”), which is the channel we want. Simply drag this into your Existing Parameters pane, and a copy of that control will be added to your interface (Fig. 3).

Fig. 3

It would be really tedious for me to write out instructions for every single parameter, so you can figure out which parameters to add to the interface on your own. Don’t forget that you’ll need some channels from inside your POP network (to control forces and the like), and you’ll need to control some other channels in your CHOP network as well as from some of the other nodes in your geometry context.

Now let’s do some fancy shit.

Let’s say you don’t always want to output extruded polygons from your network… you might sometimes want just NURBS curves, or maybe you want just the original points that made up the trails. It’s not hard to just wire a Geometry ROP to different points in the network to save out the geometry you want, but if this network is going to exist as a neat little package, it’s best to just have that single output.

To do this, we can use a SwitchSOP. The switch allows you to wire as many inputs as you want into it, and it will output the result of one of those inputs based on the “Select Input” parameter. Now all you have to do is wire connections from the appropriate parts of your network to the Switch SOP. I like using Null SOPs to visually represent each possible output of the network: for example, for the “points only” output, I would create a Null SOP and wire the output of the POP network to it, then name it “OUTPUT_POINTS.” Then drag OUTPUT_POINTS off to the side somewhere, and wire it to the Switch SOP. See Fig. 4 for an example; my network has a few extra nodes in it that I haven’t mentioned in this tutorial but the green highlighted nodes are the outputs, each connected to the “switch_outputType” Switch SOP.

Fig. 4

Now to build a control for this switch. Go back out to the Subnet and edit the parameter interface. Create an Ordered Menu control, and name it “outputType.” In the Parameter Description pane, you can then create a number of options, each with a “Token” value, which is basically an array index, and a label. The order in which these appear depends on the order of inputs into your Switch SOP. If the first input of your switch is “OUTPUT_POINTS,” then you should assign the first menu item with a token of zero and a label like “Points.” Then apply the new parameter, right-click it in the Parameters window, copy the parameter, dive into your Subnet, and paste the relative reference to the “Select Input” parameter of your Switch SOP. Now when you change the Output Type control, your new node should change its output entirely.

We can use this same switch setup for other things in the network, too. Let’s say the user might want to emit from very specific points on the model, instead of at random. Instead of defining a group of random points using the Sort SOP, we’ll need to have an alternate path that accepts a list of points. To do this, we’re going to create a Group SOP right next to the “randomPoints” Group SOP we set up earlier. Connect the output of the Trail SOP to the first input of your new group. The group name will need to be the same as the randomPoints group, since the POP Network is looking for that point group by name, so even though this group is for ordered points, it still might be named “randomPoints.” A little confusing, but whatever. Make sure your new group is a point group. Now create a Switch SOP, and connect both of your point group SOPs to it. Make sure the randomPoints group is the first input. Then connect the output of this switch to the first input of the Point SOP below. See Fig. 6 for an example of the network.

Next, we have to create an interface for this. We’ll need some kind of option menu to choose which of these groups we want to use, and then we’ll need some kind of control to define which points we want to emit from if we’re using specific points. Create another “Ordered Menu” type control, and set the first index as “Random,” and the second as “From Group.” Then create a new string control and name it “groupPattern.” Set the label as “Pattern.” Now we have to connect these parameters to your network. Close the Edit Interface window, and copy the “Emission Method” control, then paste the relative reference to the “Select Input” of your new switch. Do the same for the “groupPattern” control, and paste the reference to the “Pattern” slot of your new Group SOP. Now if you select “From Group” as your emission method and then type a list of points into the “Pattern” control, your network should emit trails from the points you specified. Keep in mind you’ll need to adjust the “Number of Trails” control accordingly, or you’ll get some weird results.

Your custom node is just about done. By this time you probably have a ton of controls, which may or may not look pretty hideous and disorganized. There are a number of ways you can clean up the interface, the simplest of which is to create folders to house your controls. In the Edit Parameter Interface window, you can drag Folders into the Existing Parameters window, and then organize your controls under labelled folders. Separator controls are also good for dividing controls into groups that don’t warrant their own folders. You can see an example of this structure in Fig. 5.

Fig. 5

One last trick. If you select a control in the Edit Interface window, at the bottom of the Parameter Description window you’ll see a section for “Interface Options.” There are a couple of text fields here for “Disable When” and “Hide When,” which allow you to set rules for when the control is visible. The syntax is a bit weird, and not particularly well-documented, but it’s simple enough once you have an example or two.

One of your controls is probably the thickness of the polygon tubes that are generated. You don’t need to have access to this control unless your network is set to actually output these tubes; if you created the Switch setup then there is a chance you will only be outputting curves or points. The parameter we created earlier that drives the output type is called “outputType,” and in my network it ranges from 0 to 3. Values 0 and 1 are for points and curves, respectively, while 2 and 3 are for polygons and polygons & curves. The thickness parameter, then, only needs to be accessible if outputType is greater than 2. For the “Disable When” string, then, type this expression in:

{ outputType < 2}

The expression needs to be contained in curly braces, and the “outputType” variable isn’t called like a local variable would be, but otherwise the syntax is simple enough. Now the control will be disabled if it’s not needed. You could apply this same idea to other parameters in your interface, such as the number of polygon divisions, or to the “Pattern” control to make it disappear when you’re emitting from random points.

The last thing to do is to save your fancy new subnet as a Digital Asset. With the Subnet selected, right-click and choose “Create Digital Asset.” You can choose an operator name and label, and then choose 1 minimum input and 1 maximum output. Once that’s done, you can drop copies of your network down like anything else! If you want to edit an asset that’s already been created, you can right-click a copy of the node and select “Allow Editing of Contents.” To save changes you’ve made back to the node’s definition, right-click and choose “Save Operator Type,” then choose “Match Current Definition” to make the node read-only again.

That’s it for this tutorial. If you want to check out my build of the network for Houdini 12, it’s right here. As always, comment away if you have any questions or if there are any inaccuracies.

The new script is on the scripts page, in place of the old MEL one.

Post a comment if you have any questions…

Anyways. Starting from the geometry network we were in before, it’s time to make a chopnet manager. Double-click to jump into the channels context. Set one of your panes to “Motion View” if you don’t have it open already. Now lay down a file CHOP. You can import all kinds of information into a CHOP network, but in this case we’re going to use an audio file. Houdini seems to have trouble with some .MP3 files, so you might be better off using a .WAV file or converting an .MP3 to a .WAV. You can leave everything else at the default. If your music doesn’t start right at the beginning of the track, you can append a Shift CHOP and change the “Start” parameter to move the audio back a few seconds.

Another aside: to preview audio in Houdini, you need to click the little icon in the bottom-right corner that looks like a speaker, set the mode to “Scrub,” and point to a CHOP or a file you want to play while the timeline plays.

Now, if you hold middle-click on your File or Shift CHOP, you’ll likely see two audio channels: chan0 and chan1. Those are stereo channels. We don’t really need both of those channels, so append a Delete CHOP and delete chan1. It’ll save a little time later on when we need to do a few operations down the line.

Next up, we want to compute the amplitude of our audio. To do that, append an Envelope CHOP. You can mess around with the Envelope Width later on. It’s not a bad idea to resample the audio by checking “Resample Envelope” and setting your sample rate to something reasonably high, depending on your audio and whether your Common settings for the CHOP are in frames or seconds. Audio curves can get pretty dense depending on the original sample rate, and you really typically don’t need that level of fidelity. Again, this can be adjusted more later on.

Now append a Trigger CHOP. The Trigger is meant to take channel data and turn it into distinct “attacks”: if you’re familiar with MIDI, you’ll know the “attack, sustain, decay, release” structure. What we’re looking for is for the value of this curve to be zero except when a “beat” is happening, in which case we want a very fast ramp-up to a value of 1.0 (the attack), a brief hold at 1.0 (the sustain), and a slightly slower tapering off back to zero (the decay/release). The “Trigger Threshold” parameter controls what amplitude is the minimum for activating the trigger. You’ll need to mess with this value the most to control when a beat happens. You’ll probably also need to adjust the Envelope Width and Sample Rate on the Envelope CHOP. Keep tweaking the sliders around on both the Envelope and Trigger CHOPs until you have a curve that looks something like the one in Fig. 1.

Fig. 1

Next up, we’re going to take this trigger information and use it to blend between two other channels: a channel with a constant value of zero, and a generated noise channel. When I originally created this effect, I wanted to use the actual waveform of the audio to displace the motion trails, but the real waveform just didn’t look that good. Generated noise had the pattern I was looking for, and was a little easier to control, so that’s the setup we’re using here. You could use a real waveform if you wanted to in place of the generated noise, feel free to experiment.

Start by creating a Wave CHOP (in the same CHOP network, but not connected to the previous CHOPs). I used a Triangle type wave, but you can use whatever you think looks best. The Period of the wave is probably going to need to be very small unless your scene scale is huge, try starting with a value of 0.05. Everything else is relatively unimportant right now.

We’re going to mix up this waveform with a little noise. Create a Noise CHOP (don’t append it to the Wave CHOP). I used Sparse noise, but again play around with the types and see what you like. I set the Period to 0.005, and the Amplitude to 4.

We also need to make a channel that’s going to act as the blender between these other two channels. Create a Channel CHOP. Add just one channel, you can name it “blend” or whatever you want. The type should be float, and the size is 1. Set the value to 0.5 for now, you’ll be adjusting it later. Finally, we’re going to tie all three of these channels together with a Blend CHOP. The channel that drives the blend amount (using a range from 0 to 1, like a ramp) needs to be the first input, so connect your Channel CHOP to the Blend first. Then connect your Wave and Noise CHOPs to the Blend. Make sure to turn on “Omit First Weight Channel,” since we only want to use it as a blender, not as actual channel information.

You should end up with a channel looking something like the one in Fig. 2. It’s a waveform that’s slightly blended with a noise pattern, enough to make it a little more visually interesting. You can control how much noise is in the curve by adjusting the “value0x” of the Channel CHOP you created from 0 (no noise) to 1 (entirely noise).

Fig. 2

Next  up, we need to extend this generated pattern so that it lasts as long as we need it to, so just append an Extend CHOP and set the Right Behavior to “Cycle.” The noise is irregular enough that nobody is likely to notice a repeating pattern in the motion trails.

So now we have two separate channels… a trigger channel that goes from zero to one based on the amplitude of the music, and a waveform channel that generates the visible pattern we want. Now what we need to do is have the waveform channel scaled by this trigger channel, so that the waveform is only really visible when the trigger is activated. To do this, we’ll just multiply the channels together using a Math CHOP. Set the Combine CHOPs to “Multiply.” If your channels from the Trigger and the Extend CHOPs are named the same, you can set the Match By parameter to “Channel Name.” Otherwise, if you only have one channel in each of those nodes, “Channel Number” is fine. Under the Mult-Add tab, the other setting to play with is “Multiply,” which will multiply the result of the Math CHOP by a scalar. This is effectively the amplitude of your final curve. Your curve should look something like Fig. 3 here.

Fig. 3

We’re almost done with the CHOP network. It’s good practice to name your channel something useful, so append a Rename CHOP and rename your channel from whatever it’s currently named (likely “chan0″ or “chan1″) to “waveform.” Then append a Null CHOP. Nulls are great for exporting data, since you can easily see them in dropdown lists if you name them in capital letters, and you don’t have to worry about other connections to your network breaking later on if you need to append extra nodes to your network. Name the Null CHOP something like “CHOP_OUT.”

Now we have to jump back to the POP network you made earlier. Go inside the POP Network. We’re going to insert a few nodes between the Force POP and the Drag POP we made earlier. First, we need to define exactly which points we’re going to be moving for each frame. We don’t want to move the points that have just been emitted, since that would push the start of the trails away from the body, which would look weird. Instead, let’s make a group out of particles that have been alive just a little bit longer than that… say, three frames. Append a Group POP. Set the Group Name to “displaceGroup.” Under the Rule tab, check “Enable” and set the rule to $AGE == 3/$FPS. This means that the group will evaluate to include only particles whose were born exactly three frames ago ($AGE gives you the particle’s age in seconds, so we divide it by the $FPS variable to get frames).

Now to the good part– we’re actually going to take this group of particles and translate them based on the value of that CHOP network. Append a Position POP. This node lets us manually define the position of any particle. Set the Source Group to “displaceGroup.” For this example, we’re only going to modify the Y-coordinate of these points, since we’re looking at this animation from the side. If you have the inclination, you could move the points instead along the normal for each point, or use a VOP POP to handle the translation in VOPs, but I’ll stick to the slightly easier-to-understand Position POP. Leave the x and z position values to $TX and $TZ, which are the current coordinates of the particle. For the y position, input the following expression: $TY+chopf("../../chopnet1/CHOP_OUT/waveform",$FF)

This expression looks a bit ugly if you’re not used to using them, but it really isn’t that complex. We are taking the existing Y-coordinate of each particle, $TY, and adding the value of the channel we created in the CHOPnet at the current frame. The chopf() expression looks for the path to a CHOP channel, which, relative to our current path, is “../../chopnet1/CHOP_OUT/waveform”, and then wants a frame, which we set to the current frame as a floating-point value ($FF).

If you try playing the simulation now, you should see your particles being bumped around by the audio channels! Just a few more things to do before the effect is totally finished.

There will be situations where the particles get way too close to each other, especially when the emitter isn’t moving fast enough. To alleviate this problem somewhat, we can give the particles a sort of electrical charge, forcing them apart. To do this, append an Interact CHOP. Set the Particle Radius to “Use Supplied Radius” and the Effect Radius to “Use Supplied Radius.” The Particle Radius is the virtual radius of the particle, almost like a collision radius. The Effect Radius is a sort of padding around the particle, within which the particle’s electrical charge can be felt. You can set your own values for the two radii- I used 0.2 for the Particle Radius, and 0.5 for the Effect Radius. The settings will depend on your scene scale and motion. Under the Behavior tab, you can set your Force Multiplier to scale back the repulsion force a little bit, maybe to 0.3 in all directions. Finally, under the Defaults tab, check “Override Charge” and set the charge to 1. This means that all particles will have a positive charge, and since particles with similar charges repel (think magnets) the particles will push away from each other if they bunch up too close. The settings on this tab will have to be messed with a bit in order to get good results– settings that are too high will result in your trails exploding.

Try your simulation now! If the audio bumps are a little too big, try adjusting the final amplitude of your CHOP channel (the post-multiplier in your Math CHOP). If they happen too often or not often enough, check your Envelope CHOP. If they fall off too quickly or start too slow, adjust your Trigger CHOP.

There are a lot of settings to mess with, and it’s really annoying to have to jump all over your networks to adjust these things, so the next part of this tutorial will show you how to package this whole effect into a single node, with an interface that controls all these parameters in one place. You can then save that node to your own personal library and use it anywhere you like, or share it with other Houdini users. As always, if something doesn’t work right or if you have any questions, feel free to comment away.

Anyways, after beating my head against the wall for the better part of a month I’ve finally started making sense out of this program, and I want to share an effect I’ve been researching for an upcoming spot, and turn this into a sort of tutorial for dealing with particle systems, creating objects on the fly, and manipulating shapes using audio. Later on I’ll also go over how to make the effect into a “digital asset,” meaning packaging the effect into a single node with its own interface that you can then use for other shots or share with other artists.

I really dislike video tutorials so I’m going to try to write this one out. The first segment will be about creating the trails, the second will be about modifying the trails using CHOPs, and the third will be about repackaging the effect as a digital asset and building an interface.

Anyways, here’s the effect we’re creating:

I realize it kind of all turns to spaghetti in the end, but that could probably be fixed with a little more fine-tuning, and I wanted to show a little complexity to the effect. Hit the jump for a big huge post about how this is done.

So, how do we make this? I am going to assume you know the very basics of Houdini, like how to make an object and animate it from place to place. If you’re like me and took a really long time to understand all the “OP” lingo, here’s a quick rundown:

• SOP = surface operator (a node relating to geometry, in the “obj” context)
• POP = particle operator (a node relating to a particle network, or POPNet, in the “part” context)
• CHOP = channel operator (a node that modifies channel information such as an animation curve or an audio clip, in the “ch” context)
• ROP = render operator (a node that outputs images, geometry caches, etc, in the “out” context)

There are other OPs (DOPs, VOPs, SHOPs, etc.) but we won’t be using any of those here. Anyways, back to business.

First, you need an animated shape. I imported an FBX sequence that I had laying around, it comes as a mocap example built into Maya. You could import your own sequence, or just quickly animate a shape from point A to point B in Houdini, it doesn’t necessarily need to deform.

Once you have your animated geometry into place, it’s time to build the effect. I like to keep effects in separate geometry nodes, and use the Object Merge SOP to import my necessary source shapes into my effect network. Keeps things separated and clean. Create a Geometry scene object, and dive inside. The first thing to do is create an Object Merge SOP, and point it to your animated shape. Make sure the “Transform” setting is set to “Into This Object” so that any transforms are properly inherited.

Next, we need to create velocity information for our animated shape. We want the particles that will form the trails to inherit some of the animated motion. In order to do that, you append a Trail SOP, and set it to “Compute Velocity.” Now if you look at your point information in the Details View, you should see some information in v[x], v[y] and v[z].

Next, we want to define what points on the geometry are going to emit particles. To do this, we have a couple options: we could manually define a point group using a Group Geometry SOP, or we could select a random assortment of points. We’ll eventually set the network up to do both, but for now let’s select a fixed number of random points, since it gives us the chance to learn about a few more SOPs. First, we’ll append the Sort SOP in Point mode, with Point Sort set to Random. If you look at the details view and use the Bypass flag (the yellow one) on the Sort SOP to turn it off and on, you’ll see the point order change randomly according to the Seed parameter. We can adjust the Seed parameter to pick a different grouping of points later on, if we don’t like what’s chosen with the default Seed of 0. Once the points are randomized, then we can just take the first few points and define that as our source group for the particles. To do this, append a Group Geometry SOP and set it to “Group by Range.” We’ll start with point 0, and end with the number of trails you want, minus 1, since 0 is the first point index. Let’s start with three trails, so set the end of your range to 2. You can name the group whatever you want… I’m calling mine “randomGroup.”

One thing you’ll commonly see with groups is the expression $OS. $OS returns a string equal to the name of the current operator. If your Group SOP is labelled “myGroup,” and the Group Name parameter is set to $OS, then your group name will also by “myGroup.” It’s good practice to do this with Group SOPs so that you can quickly see what group is being created without having to actually click on the node and check the parameters.

Fig. 1

Now we have motion information from the geometry, and a group of points to use as the particle source, so we’re ready to create the particle network. Append a POP Network SOP, with your Group SOP connecting to the first input of the POP Network. Here’s what the shape network looks like so far (see Fig. 1).

Dive into the POP network. First, we need an emitter. Since we’re emitting from a group of points on a geometry, we’ll use the Source POP. Set the Emission Type to “Points (random)” and the Source Group to “randomPoints” or whatever you named your point group earlier. Your geometry source is the “First Context Geometry,” which just means “whatever is plugged into the first input of the POP Network node.”

Under the Birth tab of the Source POP, we’ll need to change a few things. We want to emit one particle, per point, per frame. We’ll use Impulse birth instead of Constant, since it’s a little easier to emit an exact number of particles per frame this way. Set Constant Activation to 0, and then set Impulse Activation to $FF > 1. This expression means that as long as the frame number ($FF means “frame number” as a floating point number) is greater than 1, the expression evaluates as “True,” and the Source node will emit a number of particles every frame equal to the Impulse Birth Rate if Impulse Activation is anything other than 0 (or “False”).

The Impulse Birth Rate is next. While we could manually set this to be 3 (the same number of trails we want), it will get a little cumbersome later on if we want to change our number of trails and have to update both this number, and the End Range number on the Group SOP we created earlier. So let’s just reference that End Range parameter using an expression instead. You can go back out of the POP Network, select the Group SOP, right-click the End Range value and select “Copy parameter”, then go back to the Impulse Birth Rate, right-click and select “Paste Copied Relative Reference,” and then add a “+1″ at the end, or you can just create the expression manually. Either way, it should look like this: ch("../../randomPoints/rangeend") + 1. The ch() expression evaluates a channel on another SOP, in this case, the randomPoints Group SOP. We add the +1, again, because our point array starts with an index of zero.

Finally, under the Attributes tab, we need to set Inherit Velocity to some small number. Setting it to 1, while it can be physically accurate, is probably going to result in particles flying all over the place if your object moves too quickly, so let’s start with 0.1 or 0.2 for now. That means that new particles born from a source point will multiply the source point’s v[xyz] values by this fraction and apply the new value as the initial velocity of the particle.

Next, let’s add a little bit of gravity. We want the trails to feel as if they’re underwater, so the force won’t be too heavy, but a little bit gives the motion a nice touch. Gravity is pretty simple: append a Force POP, and set the Y component of the force to be something like -0.1 (actual physical gravity is about -9.8 along the Y-axis).

Now let’s add a bit of drag, to slow down the movement of the particles. This will really create that “underwater” motion effect. Append a Drag POP, and leave the Scale at 1.0 for now. Set the Output flag (the blue one) to this Drag POP, and let’s back out and see what we’re getting so far. Rewind and play forward for a few seconds or so.

Fig. 2

Your simulation may vary, but based on what we have here (Fig. 2), we can already notice a few things: the particles are definitely inheriting motion from the source object, and they’re emitting from random points on the surface, but there aren’t nearly enough points to define those nice sharp curves we’re going to need later on, especially when the source object is moving quickly. To get more particles to emit per frame, we’re going to need to use oversampling. You might think that we could just double or triple the Impulse Activation rate, but all that would mean is more points being emitted all at once, and we actually want to emit particles during sub-frames. The Impulse Activation will actually emit particles every time the operator “cooks” (I lied earlier about it emitting per-frame), so if we oversample the particle network, we’ll get particles emitted according to the motion on during sub-frames as well. Try turning up your Oversampling on the POP Network to 3 or 4, and you should see more particles right away.

Fig. 3

If you have very fast movement in your object, though, and we’re emitting particles during sub-frames, we also need our geometry to be evaluated at sub-frames. Otherwise you might notice that particles will be emitted in small, tight groups during fast movement. To calculate the position of deforming geometry at sub-frames, we can use the Time Blend SOP. Put the Time Blend right before the Trail SOP in your network. Now your object should be sending out nice, detailed, smooth trails of particles, like the next example (Fig. 3).

Now let’s try making these points into a line. We need to make a point group out of each line individually somehow, or else we’re going to end up with a disordered tangle of lines. We need to create an attribute on these points that is somehow unique to each individual point on the emission surface. Fortunately, this is fairly easy, though not obvious. Go back to the Source POP, and turn on “Add Origin Attribute.” If you rewind and play through a few frames, and then check out the Details View, you’ll see that each particle has an “origin” value between 0 and 2 (or however many trails you’re creating minus one). We can use this attribute to group each line of points together, though we’ll have to get this attribute out at the SOP level first.

Go back outside the POP Network and hold middle-click on it. You’ll see that there is definitely an attribute named “origin,” but unfortunately we don’t actually have access to it yet. Why? I have no idea. Fortunately we can easily gain access to it by creating a new attribute here in the SOP context with the same exact name. Append an Attribute Create SOP, and set the attribute’s name to “origin.” Now we can actually refer to this value later on in the network.

Now, to use this origin value to make our groups. There is a very powerful SOP made for just this reason, called the Partition SOP. Append this to the network. Set the Entity parameter to “Points,” since we’re making point groups. The Rule parameter is the important one here: it defines how our new groups are going to be named. We want one group for each set of points that have the same “origin” attribute. Since we didn’t set a custom variable mapping for “origin” in the AttribCreate SOP, the way to reference that attribute in expressions is just $ORIGIN. The Rule parameter, then, will be linePointGroup_$ORIGIN. If you middle-click the Partition SOP, you’ll see that a number of point groups will have been created, each named linePointGroup_#, where # is the origin value. So now we have a group for each line of particles!

Now we have to connect the dots. The Add SOP has a perfect function for this. Append an Add SOP, and set the top tab to “Polygons.” Enable “Remove Unused Points,” and set the mode to “By Group.” Set the Add mode to “Each Group Separately.” Now you just have to define the group name. Since we want one line drawn for each group, we can use a wildcard to send all the groups out at once. Set the Group parameter to linePointGroup_* and you should have solid lines drawn through your points.

Next let’s convert these lines to NURBS curves. Append a Convert SOP and set Convert To to “NURBS Curve.” The rest of the settings should be okay at their defaults. Almost there! We want nice, even divisions along this curve for when we turn it into polygon geometry, so let’s append a Resample SOP and set the length to 0.1 or 0.2.

Let’s do a little cleanup. We’re going to delete all of the groups we’ve created so far and make new groups out of the polygon geometry we’re about to create. Append a Group SOP, uncheck the “Create Group” box and switch over to the Edit tab. Under the Delete option, enter * to delete all groups.

Now we’re going to create some new groups. We have three (or some number) of NURBS curves, and each one is a primitive. Each primitive has its own number, which you can refer to in expressions with the variable $PR. So if we want to make a primitive group out of each curve, we can once again use the Partition SOP to group them. Set the Entity to “Primitives,” and your rule is linePrimGroup_$PR. We’ll use these new primitive groups in just a second. First, we have to actually make these curves into geometry.

Append a PolyWire SOP. This lofts a circle over the length of each curve. The Wire Radius parameter controls the thickness of the wire, and the Divisions parameter controls the number of sides the circle has. If there isn’t enough resolution along the U direction of the curve, go back to your Resample SOP and decrease the Length parameter.

Unfortunately, we just lost all of our group information when we created this new geometry, but there is an easy way to get it back. Append a Group Transfer SOP. The PolyWire SOP goes into the first input since we are transferring group information TO this object. The Partition SOP just before the PolyWire SOP goes into the second input, which is what we are transferring FROM. The Group Transfer SOP will transfer group information by proximity, so all of the primitives (polygon faces) in each wire will be placed into the same group as the original NURBS primitive.

Fig. 4

That’s about everything for the first part. If you wanted to export this geometry, you could add a Geometry ROP and export a .bgeo sequence, or try your luck with the FBX exporter. Or, if you have Realflow, or the Realflow plugin for Maya, you can use this OTL to export .bin sequences. Before you export, it’s not a bad idea to append an Attribute SOP to the end of the chain and delete any attributes you don’t need. For me personally, I deleted everything except the normals by using this string under “Delete Attributes” in the Point tab: * ^N. This basically means “delete everything but don’t delete N (normals) information.” Your SOP network, from the POP Network down, should look something like the next example (Fig. 4).

Next up, distorting these trails with audio information using CHOPs!

There are other, more informative posts on how to get Python running in standalone mode (I learned a lot from this one in particular), but the gist of it is that you start by running /bin/mayapy.exe, and then initialize the Maya Python interpreter by calling the following function:

import maya.standalone as standalone
standalone.initialize(name='python')

Once that’s done you can start scripting like normal, starting with import maya.cmds as cmds and working from there. Some commands are not available in standalone mode, especially anything to do with UI.

Anyways, while working on a script that is meant to process huge heaps of unsorted Maya files, I realized that crashes were going to be a frequent problem when opening ancient, broken scenes, so I couldn’t just load an instance of Maya in standalone mode from a script and let it run through everything in a loop. I needed to be able to process one file at a time, and then either return some useful information if the process is successful, or let me know if Maya crashes so I can avoid that file later on or at least mark it.

To do this, I used Python’s subprocess module. Again, I’m not going to go into a ton of detail about the module, it’s pretty complicated, but I’ll give a quick example of how I’m using it to return information from a Maya process when I am calling the script from Maya (or any other program, really).

Let’s say I want this script to add a new render layer to several scenes, and add all meshes in each scene to that new layer. First, I’ll write the script that actually creates the layer and assigns objects.

import sys
import maya.standalone as std
std.initialize(name='python')
import maya.cmds as cmds
filename = sys.argv[1]
layername = sys.argv[2]

The sys.argv[1] and sys.argv[2] are easy ways to pass variables to an external script. sys.argv[n] just means the nth command line argument, so sys.argv[1] is the first command-line argument when running the script (after calling for the script name, for example, by running mayapy.exe yourScript.py). When we call this script, we’ll pass it a file to open, and a layer name to add.

def addRenderLayer(filename,layername):
    cmds.file(filename,o=1)
    newLyr = cmds.createRenderLayer(name=layername,empty=1,makeCurrent=1)
    meshes = cmds.ls(type='mesh')
    xforms = []
    for i in meshes:
        xf = cmds.listRelatives(i,p=1)[0]
        xforms.append(xf)
        cmds.editRenderLayerMembers(layername,xforms)
        cmds.file(s=1,f=1)
    sys.stdout.write(newLyr)
    return newLyr

addRenderLayer(filename,layername)

Here we’re creating an empty render layer based on the “layername” argument, then we’re getting all the meshes in the scene. In most scenes, people add transforms to render layers, not their individual shape nodes, so we’ll do this by creating an empty list “xforms,” then going through each mesh in a loop and finding their first related transform node (hence the listTransforms(i,p=1)[0] since listTransforms returns a list) and appending it to “xforms,” then adding “xforms” to the new render layer. Then we just save the file and return the name of the layer (I just like having return values for my functions).

We also write the name of the new layer to stdout. I’ll go into more detail about this later, but it lets us send information back to the program that calls this script later on.

Save this file as makeNewLayer.py somewhere in your default scripts directory.

Next, we’re going to make the process that we run from Maya…

import maya.cmds as cmds
import subprocess
# replace mayaPath with the path on your system to mayapy.exe
mayaPath = 'c:/program files/autodesk/maya2011/bin/mayapy.exe'
# replace scriptPath with the path to the script you just saved
scriptPath = 'c:/users/henry/desktop/addRenderLayer.py'
def massAddRenderLayer(filenames,layername):
    for filename in filenames:
        maya = subprocess.Popen(mayaPath+' '+scriptPath+' '+filename+' '+layername,stdin=subprocess.PIPE,stdout=subprocess.PIPE,stderr=subprocess.PIPE)
        out,err = maya.communicate()
        exitcode = maya.returncode
        if str(exitcode) != '0':
            print(err)
            print 'error opening file: %s' % (filename)
        else:
            print 'added new layer %s to %s' % (out,filename)

Okay, a lot going on here. The subprocess.Popen function is calling mayapy.exe with three parameters: first, the script we want to run (makeNewLayer.py) followed by the two arguments that script wants (the filename and the layer name), then the input stream and the output stream which are both set to subprocess.PIPE. I’m not quite knowledgeable enough about the subprocess module to go into specifics, but basically when you run a process there are three “streams”: the input, output and error streams, usually called stdin,stdout and stderr. When you set the input and output streams to subprocess.PIPE when calling Popen(), you can be sure that the process will receive any input stream you give it (which we are not doing here; instead we’re using the sys.argv method shown above) and also communicate back any output it gives.
The next procedure, communicate(), returns two variables: stdout and stderr. We can use this for debugging or monitoring progress. Normally in the Maya script editor, if your script fails for whatever reason, you will get some kind of (possibly) useful information back from an error. However, you won’t have any idea what goes wrong with a subprocess unless you are listening to the error stream.
communicate() does a couple other awesome things. First, and most importantly, it waits for the subprocess to complete before continuing with your script. This is REALLY IMPORTANT, as you definitely don’t want a script like this to continue running until the process is finished. Second, it sets a few variables on the Popen() object, one of which is Popen.returncode. If you have ever slogged through Maya render logs and noticed lines like “Maya exited with status: 210″ or “Maya exited with status: 0,” those numbers are exit codes. Status 0 means the program exited normally; any other exit code means something went wrong. Since I want to be notified if something goes wrong when opening or editing a scene, I check to see if Popen.returncode is anything other than zero, and if it is, I print out the error stream and leave a notice that says something went wrong. If everything worked, I just want to know that it worked, and so I print a string. Since I wrote the output layer to sys.stdout, when I read stdout from the subprocess, I get the name of the newly created layer. I do this since the layer might not come out with exactly the name I wanted if another node in the scene had the same name as the new layer!

I’ve been using the subprocess module along with Maya standalone more and more as I make more complex applications. It’s incredibly useful to be able to process many files at a time… if you get any good ideas, you know where to post them.

Normally in Maya/mental ray, when you want to apply a displacement map you just create a displacement material and connect it to the shading group you want displaced. If you want to adjust the amount of displacement, you actually grade the image itself by adjusting the color gain and offset on the file node. It’s simple, it works, whatever.

You can still apply displacement like that in VRay, but there is a better and more flexible way to handle it using VRayDisplacement sets. They’re kind of like VRayObjectProperty sets, but they act as a sort of container for displacement settings instead of generic render settings and object IDs. In order to use these sets, you want to select the objects to displace with a single map, and go to Create > V-Ray > Apply single VRayDisplacement node to selection. A set will be created, visible in the Outliner.

Next up is to assign a displacement texture to the set. This means you don’t have to connect a displacement shader to any shading group; the set will handle that connection.  When you select this set, the Attribute Editor will give you just two options: a checkbox saying “override global displacement,” and a plug for a displacement material. Check the box on, and then connect a texture to the displacement material (not a material, but a texture). I usually run a file texture through a Luminance node first to make the connection easier (file.outColor –> luminance.value), unless I’m using a vector displacement map in which case I’m using color information instead of just luminance or alpha.

So where are all the displacement options? You have to add them. If you don’t change anything, the displacement will use the default values set in the VRay render settings under Settings > Default Displacement and Subdivision. This defaults to an edge length of 4 pixels, a maximum subdivision number of 256 (this is a lot of subdivisions!!), and a displacement amount of 1.0 (which is usually way too high). These are terrible values for most scenes, the displacement will look grossly exaggerated and it will take forever to render.

In order to tweak the settings, you need to add the appropriate attributes to the VRayDisplacement set. With the set selected, open the Attribute Editor and select Attributes > V-Ray > Displacement Control and Attributes > V-Ray > Subdivision and Displacement Quality. Now you have a ton of options to play with, the most important of which are Displacement Amount (color gain), Displacement Shift (color offset), Edge Length, and Max Subdivs. I recommend starting with a displacement amount of 0.1-0.5, and a max subdivs of maybe 16-32 before starting to increase those settings.

I have no idea why these attributes have to be added manually, but hell, it’s still better than mental ray.

One problem that I remember having over and over (since I’ve never rigged frequently enough to ever learn the correct method) is that when applying an IK handle to a joint chain, and then applying a pole vector constraint to that IK handle, the joints can sometimes move subtly. It’s not always a big deal, but it can be a problem when you’re trying to have multiple matching skeletons for FK and IK control, and suddenly your rotations don’t line up anymore.

The fix, as it turns out, is really easy. Before you apply the pole vector constraint, you need to place your controller (whatever is going to drive the pole vector) exactly between the start of the IK chain, and the end effector, e.g., the shoulder and the wrist. This is quickly done by selecting the start and end joints, and then the controller, and creating a point constraint (do not maintain offset). Then delete the constraint. Next, use an aim constraint to point the controller directly at the middle joint (say, the elbow). Delete the constraint. Then you just need to move the controller along its pointing axis a little ways, to push it away from the bones. For example, if your aim vector for the constraint was +X, then push your controller a few units forward in its local X axis. Now you can create the pole vector and the joints shouldn’t snap at all.

The first thing to do once you attach an image plane to the camera is to switch the “Type” attribute from “image” to “texture.” Once you do this, you can attach a regular File node to the texture, and set up your image sequence attributes on the file node if you are using a sequence.

The next step is to connect the file node to a gammaCorrect node… create a gammaCorrect node, set the gamma in all three channels to 0.454 (or whatever the inverse of your current gamma is if you’re not correcting to 2.2) and then connect the outColor of the file node to the “value” of the gammaCorrect node.

The last step is the tricky part. Try connecting the output of the gammaCorrect node to the imagePlane node… where does it go in the Connection Editor? Maya decided that you, the user, should be sheltered from this most dangerous input, and it’s been hidden by default. Turn on “show hidden” on the right side of the Connection Editor, and then connect the outValue of the gammaCorrect node to the “texture” input of the imagePlane.

I don’t really understand why this has to be so difficult in Maya, but the same could be said about a lot of this program.

A lot of people in the past have asked me or others to find the material you’re supposed to use to render this pass from Maya. There are different ways to make it, but by far the easiest is to just use a place2dTexture node and a surface shader (or a VrayLightMtl, if that’s your thing).

Connect the place2dTexture.outU –> surfaceShader.outColorR. Then connect place2dTexture.outV –> surfaceShader.outColorG.

That’s it. Apply the material to everything and you’re done. In VRay, you don’t even need a material if you want to save a render layer; just create a VrayExtraTex element on your render layer and connect the place2dTexture outputs to the ExtraTex element in the same manner.

The setup is really easy but there are a few things to watch out for. First of all, if your UV’s are distorted, then any texture you place on it is going to be distorted. So you need good UV’s. If you’re using simple rectangular billboards, make sure the UV’s are normalized (you can normalize UV’s in the UV Texture Editor). Also, the image quality will suffer if you aren’t rendering to a floating point file format– 32-bit floating point images are best to avoid artifacting.

One other subtle thing to watch out for. If you are using a linear workflow when you render (and you should be!) it’s easy to screw up this render and end up with weirdly warped images. This render should NOT be gamma-corrected in any way, so disable your lens shaders if you’re in mental ray, and set your gamma to 1.0 and turn off “linear workflow” if you’re in VRay. It’s hard to see, but take a look at the difference between a linear render of this pass and an sRGB (gamma 2.2) render:

The image on the left is the correct one. Using a color-corrected UV pass will cause your substituted textures in After Effects to appear very warped around certain edges.

(I’ve made this mistake way too many times.)

Also on a positive note… the Maya pipeline system I’ve developed here at Scholar, “Mustache,” is now fully production-ready, and being used for several simultaneous 3D spots right now! It’s taken a long time to work out the bugs, and there’s still plenty more, but it’s made jobs that would have previously been impossible to manage a comparatively painless procedure. I’ll be posting more later about the more unique features of Mustache and why nobody here wants to work without it anymore.