There was an interesting thread recently on Odforce in which someone wanted to be able to “boolean” a curve against a polygonal mesh; essentially chopping up the curve at the intersection points between the curve and the mesh, and removing the inside parts of the curve. This ended up being Read more…
An updated version of this article is now available here: https://www.toadstorm.com/blog/?p=942
On the Houdini Discord server(s) I keep seeing the same kinds of questions over and over again, mostly related to instancing. The most common questions asked seem to be:
“How do I randomly rotate/scale my copies?”
“How do I rotate each copy along a specific axis?”
“How do I randomly change what objects get instanced?”
“Why am I not supposed to copy stamp anymore?”
Houdini’s documentation can admittedly be a little vague at times, but more importantly they expect you to have a decent understanding of how some fundamentals of computer graphics work, like how a 3×3 matrix works for orientation. I’m admittedly not great at math, so hopefully I can explain everything both intuitively and in such a way that I don’t completely embarrass myself in front of people who actually know what they’re talking about (i.e. this guy).
Anyways. The Copy SOP.
One of the first things to learn about the Copy SOP is that the point attributes on the points you’re templating to can influence how each copy is placed in the world. Aside from the obvious position of each point, P, there are a few other attributes with obvious effects. You can view the complete list here: http://www.sidefx.com/docs/houdini/copy/instanceattrs The important ones to remember are:
v@up(these vectors work together, explained later)
f@pscale(uniform scale of each copy)
v@scale(a vector that can scale each axis independently)
p@orient(a QUATERNION that defines the orientation of each copy
p@rot(another quaternion that defines an additional rotation)
(Keep in mind that those little @ prefixes in front of the attribute names are only used in Wrangle nodes… they’re just there to hint to Houdini what attribute type they are. For common attributes you typically don’t need to include them in your Wrangles, and you never need to use them when writing group masks.)
Now, in many situations, you can get by with just using the Attribute Randomize SOP to randomly generate an
N attribute for you, and a random float for
pscale, and you’re good to go. But there’s always going to be times where you need specific orientations for copies, and these times are when you’ll need a more thorough understanding of what the Copy SOP is doing under the hood… (more…)
I’m going to try to make a nice easy introduction to my two favorite functions in Houdini VEX (besides
chramp of course):
primuv. These functions are at the core of a lot of really useful and cool tricks in Houdini, including rivets, the attributeInterpolate SOP, the old “droplets falling down a soda can” effect, and some really awesome stuff with volume shaders. I’ll do a little example of each as a way of showing off what you can do with these clever little tools.
First, let’s take a look at the VEX definition (the third overload here is the most frequently used):
float xyzdist(string geometry, vector pt, int &prim, vector &uv, float maxdist)
At its most basic,
xyzdist will return the distance from the sample point
pt to the nearest point on the surface
geometry. Note that this doesn’t mean the nearest actual point, but the interpolated surface in between those points.
Those little “&” symbols mean that this function will write to those parameters, rather than just read from them. So if we feed this function an integer and a vector, in addition to the distance to the surface, it will also give us the primitive number
prim and the parametric UVs on that primitive
uv. Note that parametric UVs are not the same as regular UVs… this just means the normalized position relative to the individual primitive we found.
So, what can we do with this? Click below to find out…(more…)
My good friend and motion graphics bromance, Eli Guerron, asked me to help him create a procedural system of branching circuits that would look something like a schematic drawing. I stupidly thought this would be an easy trick with particles, but to get the right look it actually took quite Read more…
As part of the pipeline I’m currently writing for Timber, I’ve been working on an input/output system that can pass data back and forth between Maya and Houdini. The goal is to have a Maya artist send an Alembic scene to Houdini, process the scene in Houdini, then send the Read more…
I’m trying to build a system right now that can automatically substitute environment variables for paths on a per-scene basis. When a user opens a Maya file, I want to parse that file and set temporary environment variables called $SHOW, $SEQ and $SHOT that point to the show’s root folder, the sequence’s folder in that show, or the shot in that sequence. The variable names and paths I’m trying to get are pretty specific to the current pipeline I’m working on, but this essentially lets me use relative paths in Maya but WITHOUT using Maya’s outdated and inflexible workspace system. I don’t want an individual Maya project for every single shot and asset in the entire show, and I don’t want all of my Maya scenes to be forced to live within a single workspace, either.
I’ve solved this problem before by using symbolic links to basically force all of the Maya projects generated for every single shot and asset to link to the same place. This makes for a pretty busy-looking file system, though, and symlinks only work on Unix-based servers (i.e. not Windows). This system I’m building now looks a lot more like Houdini’s global variables… as long as I define $SHOW or $SHOT or whatever, I can path a reference or a texture to $SHOT/assets/whatever.xyz and it doesn’t necessarily have to be within a Maya workspace, and it’s also not an absolute path.
Read more below… (more…)
A while ago I posted about how to manage viewports in Maya in order to prevent the screen from redrawing while doing a bake or Alembic export, which slows things down considerably. It turns out there’s a way easier way to handle this, thanks to a hidden (of course) MEL Read more…
Last year I worked on a Vikings teaser for King and Country over in Santa Monica. The spot was mostly live-action, but there were a bunch of CG snakes that needed to be added in post, and so I finally got to flex my rigging muscles a little bit.
First, here’s the spot:
Snakes seem like simple problems to solve, since they don’t have shoulders or hips or any other nasty bits that are hard to rig on humans, but the problem lies within the lack of control an animator has over a typical IK spline.
Most simple snake rigs are just that… make an IK spline, cluster the curve, let the animator sort out the rest. Maybe the animator will get lucky and there will be some kind of control hierarchy, but otherwise they’re in for a lot of counter-animating hell. IK splines also suffer from a lack of precision twisting… snakes (especially when you have big piles of them) tend to need to have different twisting rotations along the length of the body, and IK splines can only twist linearly from start to end. Stretching them also typically results in unstable behavior, with the end joint stretching well beyond the intended values, especially when the spline curve is bent quite a bit.
Click below for more details…
I realize this effect was done years and years ago by smarter people than me (JT Nimoy, Adam Swaab, among others) but I’m a big nerd for procedural art and wanted to see how I could create the Quorra Heart effect described on Nimoy’s blog here. The effect itself isn’t Read more…
A quick script here to convert Gizmos in Nuke into Groups. Gizmos are nice in theory in that they provide reusable groups of nodes for users to interact with, but they’re often more trouble than they’re worth, especially if you need to send your Nuke scripts to someone else. Here’s Read more…