MOPs Tutorial 4: Creating Instances
MOPs has a small category of nodes called Generators that are mostly designed to create packed primitives for animation, though there’s a few Generators that just build regular polygons, including MOPs Sweep Spline and MOPs Trails.
The most commonly used Generator is the MOPs Instancer, which is a kind of souped-up version of Houdini’s Copy SOP. The MOPs Instancer can automatically handle randomized or ordered instance variations, including weighted probabilities for variations, and automatically interpolates positions and orientations of copies over deforming template geometry. It also comes with a bunch of convenient distribution patterns for creating grids, rings, spheres, honeycomb patterns, and so on.
A few of the distribution patterns inside MOPs Instancer.
Another little optimization that the MOPs Instancer handles for you is in reducing time-dependence in your network. Normally if you instance onto something that’s changing using the Copy SOP, the Copy SOP itself will be flagged as time-dependent, and so it will cook every frame, regenerating the instances with every cook. In contrast to the Copy SOP, the MOPs Instancer generates all of its instances at once on a single frame, called the Template Rest Frame when instancing onto template geometry, and then the other MOPs modifiers update its transforms later on. This can mean a significant speed improvement when scrubbing the timeline in your scene. However, if your template mesh has a changing point count over time, this optimization can be a problem… you’ll want to set the Template Rest Frame to be equal to the current frame, @Frame, in order to create new instances as the point count updates, or just disable Template Interpolation entirely.
MOPs Instancer automatically interpolates instances over deforming geometry. Behold spiky Crag! Example file: instancer_spiky_crag.hip
Important: The MOPs Instancer was built before SideFX introduced the Piece Attribute parameter on Copy to Points, as well as the Attribute from Pieces companion SOP. It's still a convenient tool for laying out instances quickly, but it's no longer quite as necessary as it used to be for distributing variants of objects. It's important to remember that you do not need to use the Instancer to work with other MOPs tools! You can use MOPs on any packed primitives or points that you like, whether or not they were created with an Instancer.
When instancing multiple different objects using the MOPs Instancer, you have a few options for how you want to select what object goes where. The most straightforward method is to select the “Random” indexing mode. This will randomly select which instance is copied to each point. You can adjust the probability of a given instance showing up by scrolling down to the Instance Objects multiparm block and playing with the Probability slider.
The Ordered indexing mode iterates through each possible asset in order when instancing. If you want to adjust this order, you’ll need to modify the point order under the “Sorting” tab.
The last mode, Point Attribute, looks for a point attribute on the template mesh. By default, this is an integer attribute called “mops_index”. There's a helper node to create this attribute if you don’t want to do it manually called MOPs Index from Attribute that remaps any point attribute to the mops_index attribute based on a given range and number of indexes to support.
Using MOPs Index from Attribute to translate a Shape Falloff to the instancing index. Example file: mops_index_attr.hip
MOPs also has some handy tools for dealing with animated instances. MOPs supports both Packed Alembic sequences and Packed Disk Sequences. You can either plug an Alembic or File SOP directly into the Instancer, or set the Instance Type in the Instancer’s multiparm block to File and then give it a file path to load. MOPs tries to treat Alembic and Packed Disk sequences the same, so that features like looping behaviors work with Alembic files as well as Packed Disk Sequences without extra effort.
You can manually change the timing of any given instance using the MOPs Set Sequence Time node. You can set the timing of any given instance based on a constant value or a point attribute, and you can also modify any existing cycling behavior if you like. MOPs enables the cycling behavior of Alembics (they don't cycle by default!) by adding some special point attributes to your packed primitives. If you don’t create animated instances with the Instancer but you still want to take advantage of this behavior, you can use the MOPs Set Sequence Time node to override the existing cycling behavior. The only thing you can’t change after the fact is the total frame range of a Packed Disk Sequence, since that attribute is read-only… you can only change that in the original File SOP or in the MOPs Instancer if you used that.
Using a MOPs Shape Falloff and MOPs Set Sequence Time to offset the timing of some packed disk sequences. Example file: set_sequence_time.hip
It's important to remember that the MOPs Instancer is really just a very fancy Copy to Points SOP. Packed primitives generated by the MOPs Instancer are the same as any other packed primitives; they just have a few extra convenient attributes on them like i@id and s@name applied automatically. If you don't need the functionality of the MOPs Instancer, the default Copy to Points SOP followed by a MOPs Convert SOP is often enough to get you what you need.
MOPs Explode takes polygon faces and converts them into individual packed primitives. It can split up every face individually, use any integer primitive attribute to decide how to split, or use clustering to randomly choose how to split based on control attributes. Each generated chunk is then reoriented using the MOPs Reorient node so that its local axes match the average of the orientation of the original points. Something important to note is that MOPs Explode generates packed fragments, which are slightly different from packed primitives. Packed primitives are references to a single identical piece of geometry in memory or on disk. Packed fragments, on the other hand, are references to a single piece of a geometry. Fragments are more efficient when you’re dealing with a lot of unique packed primitives; meaning few pieces are identical. This is the type of packed primitive you typically get when you fracture geometry in Houdini. The only downside as far as MOPs is concerned is that you can’t preview Falloff on packed fragments due to a limitation of the viewport shader. If you really need to see Falloff preview on packed fragments, you can tick on “Display as Sprites” to see the fragments as little colored sprites, or you could try using the Repack SOP to convert the fragments to regular packed primitives, but be careful… this could get really slow if you have a lot of pieces.
MOPs Explode converting polygon primitives to packed primitives, based on a Voronoi shatter. Example file: explode_and_curl.hip
Something to be aware of is that most MOPs Generators are automatically creating a unique i@id and s@name attribute for your instances. The id attribute is needed by MOPs Apply Attributes in order to handle situations with potentially changing point counts… it might work without an id, but it’s not recommended. The name attribute is so that the instances can quickly be used in a Packed RBD simulation without any extra work. The catch is that these attributes all need to be unique. If you make several different streams with the MOPs Instancer or another Generator, you’ll want to make sure at the very least that the IDs of each stream are all unique before you merge them together. You can do this using the ID Start Number parameter. You can also use the Name Prefix parameter of these Generators to ensure unique name prefixes.
MOPs Convert is a little convenience node to quickly convert existing geometry into MOPs-friendly packed primitives. You can think of it a little like the Assemble SOP, except it also adds id and rest attributes for you, and it’ll automatically promote the name attribute to the packed points so they’re ready for use in a Packed RBD simulation.
The remaining Generators don’t create packed primitives… just regular old polygon geometry. I won’t spend a ton of time on them here because they’re not incredibly complicated, but they can be pretty great time savers when trying to achieve typical graphic effects.
The MOPs Subdivider is a bit of a one-trick pony, but it does make some cool patterns. The Houdini 17.5 splash screen used it to create the initial geometry for those glowing lines. It can’t do much more than this one thing, but if nothing else it’s a good study if you want to learn how to modify geometry with VEX.
MOPs Trails is pretty self-explanatory… it makes trails from animated geometry. It has some neat features to limit or randomize trail lengths, though, and it generates stable trails with consistent and easily modifiable orientations that won’t wobble as they grow.
MOPs Sweep Spline is probably the handiest of these three misfit Generators, at least before Houdini 18 showed up with the new Sweep. It works a bit like the old Sweep SOP, but with a lot more control, and most importantly, with predictable UVs. Any of you who’ve tried to get decent UVs from a Polywire or Sweep operation prior to Houdini 18 probably know the pain and frustration involved in getting this right. Sweep Spline just does it all for you. It works well with MOPs Trails… since the trails generate nice stable orientations and UVs, all you have to do is tell Sweep Spline to use the UVs already computed by the Trails and you’ll have animated, textured sweeps with just two nodes.
In Houdini 18, the new Sweep SOP contains most of this functionality, and is much faster. You should give the new Sweep SOP a try unless you prefer the MOPs Sweep Spline UI or need a specific feature that isn't in the new Sweep.
Using MOPs Trails to generate lines from animated geometry. The trails are then converted to tapered polygon tubes using MOPs Sweep Spline. Example file: trails_sweep.hip
In the next part of the MOPs Tutorial, we'll start exploring some of the many Modifiers we haven't already mentioned.