Update: Imre Tuske from Weta pointed out that there’s a simpler method… it turns out that you can force expressions to evaluate inside a Wrangle by wrapping them up in backticks. So if you have a channel called “do_vexpressions” to enable or disable VEXpressions, and another channel called “vexpression” that Read more…
After months of work, the MOPs toolkit for Houdini is finally open to the public! MOPs is a suite of SOP tools to help with common motion graphics tasks in Houdini. The workflow and interface should seem familiar to users of other motion graphics software packages, but it’s using Houdini-friendly Read more…
In case you missed it, part 1 is here (and includes the .hip file!). Part 2 is here. In this last part of the breakdown, I’m going to talk about some of the smaller little details of the piece: the background plants, called “sprouts” in the file, the dewdrops, and Read more…
Continued from the previous post.
Part 2 here is all about the hero plant, which was by far the most time-consuming part of this whole process. The animation ended up being done primarily using FEM, which in retrospect was probably overkill. If I were to try this again, I’d probably try to build a more procedural system involving IK chains with maybe a layer of simple soft body dynamics on top to add springiness. Going the FEM route meant that each iteration took about 30 minutes to simulate, which adds up pretty fast. There are some neat little shortcuts elsewhere in the process, though, that hopefully some readers will find useful.
The hero plant
I am a masochist so I again started with L-systems to create the basic plant structure. L-systems are one of those things that start very simple and quickly build in complexity until they’re totally unreadable, so you generally want to keep notes of what the rules are actually doing as you build them. Of course, the notes from the original .HIP file that I posted are outdated, as they apply to an older version of the plant, so if you’ve already checked out the .HIP you may want to read these more accurate notes.
Here’s what the rules look like:
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…
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…
I’m working on a production right now that involves sending absolutely enormous animated meshes (6.5 million polygons on average with a changing point count every frame) out of Houdini and into Maya for rendering. Normally it would be best to just render everything directly out of Houdini, but sometimes you don’t have as many Houdini licenses (or artists) as you’d like so you have to make do with what you have.
If the mesh were smaller, or at least not animated, I’d consider using the Alembic format since V-Ray can render it directly as a VRayProxy, but for a mesh this dense animating over a long sequence, the file sizes would be impossibly huge since Alembics can’t be output as sequences. Trying to load an 0.5 TB Alembic over a small file server between 20 machines trying to render the sequence and you can see why Alembic might not be ideal for this kind of situation.
Hit the jump below to see the solution.
One of the bigger challenges with rendering liquids is that it can be difficult to get good UVs on them for texturing. Getting a displacement map on a liquid sim can make all the difference when you need some added detail without grinding out a multimillion-particle simulation. Unfortunately, liquid simulations have the annoying habit of stretching your projected UVs out after just a few seconds of movement, especially in more turbulent flows.
In Houdini smoke and pyro simulations, there’s an option to create a “dual rest field” that acts as an anchor point for texturing so that textures can be somewhat accurately applied to the fluid and they will advect through the velocity field. The trick with dual rest fields is that they will regenerate every N seconds, offset from each other by N/2 seconds. A couple of detail parameters called “rest_ratio” and “rest2_ratio” are created, which are basically just sine waves at opposite phases to each other, used as blending weights between each rest field. When it’s time for the first rest field to regenerate, its blend weight is at zero while the rest2 field is at full strength, and vice versa.
It’s great that these are built into the smoke and pyro solvers, but of course nothing in Houdini can be that easy, so for FLIP simulations we’ll have to do this manually. Rather than dig into the FLIP solver and deal with microsolvers and fields, I’ll do this using SOPs and SOP Solvers in order to simplify things and avoid as many DOPs nightmares as possible.
Here’s the basic approach: Create two point-based UV projections from the most convenient angle (XZ-axis in my case) and call them uv1 and uv2. As point attributes, they’ll automatically be advected through the FLIP solver. Then reproject each UV map at staggered intervals, so that uv2 always reprojects halfway between uv1 reprojections. We’ll also create a detail attribute to act as the rest_ratio which will always be 0 when uv1 is reprojecting, and 1 when uv2 is reprojecting. It all sounds more complicated than it really is. Here goes…
I ran into a problem recently where I was trying to make some nice-looking embers in houdini, complete with nice motion-blurred trails. Typically with a particle system you use the velocity attribute to handle motion blur, but geometry velocity blur is always linear, so your motion trails will always be perfectly straight even if you have nice squiggly motions with your embers.
Deformation motion blur looks great, but in most simulations particles are being born and dying all the time, and deformation motion blur doesn’t work with a changing point count.
The solution is to force a constant point count. This can be problematic when your particles need to have a lifespan, so there are a few little tricks you’re going to have to pull in order to make this work…