NOTEBOOK
click to expand a section
houdini - lava texture deformation
On my current project, we have a sequence which requires a ton of lava. The talented Kenzie von Pingel spent some time building a procedural animated texture in RenderMan to avoid the need to simulate an entire roomful of relatively static lava.
Unfortunately, we also need fluid-based simulations for a set of 'lavafalls' that start spewing out into the room halfway into the sequence. Getting the texture to play nice with a proper simulation has been a bit of a head-scratcher.
Current working solution: manifold advection.
By sampling the gradient of the fluid SDF, we can get vectors that point in the direction that the lava texture *should have* been moving. If we deform the texture like so, the movement is much more convincing than the alternative.
This version was before I culled out droplets, which we can safely ignore as far as manifold advection goes.
We can then transfer color from the sim to the grid where they're close and normals from the grid to the fluid, like they do in some video game environments.
Do we want to put the camera right up next to the seam? Of course not. But at a wide angle and with other things going on, this seems like it should work just fine.
vex - celtic knot tool
I've been working on a high fantasy short film recently, and a lot of the design work included various kinds of Celtic knots in the environment and costumes. I made a tool to proceduralize knots, based on this paper:
http://www.matt-kaplan.com/npr/knots/Knot_elec.pdf
I'm aware that EverythingCG did something similar, but I'm both too cheap and too stubborn to look at the setup, though their summary of the algorithm here is pretty solid.
It takes in a flat mesh, and the edges of the mesh become pairs of arcs on the resulting knot:
My implementation is a Houdini Digital Asset that's about 99% VEX. I exposed a number of parameters to the user to control the shape. The default output is a bunch of curve primitives with normals, but the tool includes an option to sweep the curve with ribbons, tubes or a custom cross-section. The demo above shows some of the variations you can get with just the exposed parameters on the ribbon output.
At some point I plan to drive a fairy dust-type effect with the curves from this tool. In the meantime though, we needed the ability to project the knots into textures for painting stone engraving, leather styling, and other fine details, so I built a second tool to take the flat geometry and export depth and normal map textures from the curves.
USD - steam asset
In a lava room sequence, the lighting team asked me for large steam volumes to get atmospheric depth cues in the cavern. The sequence is 46 shots long. As I saw it, I had a few options:
Make the FX team kick out a different steam simulation for every shot.
This option runs the risk of a different fog appearance in each shot.Use one static volume for the steam.
While this was somewhat viable, if we were just going to use a single uniform volume, I didn't see much of an advantage over just using a depth pass in comp to make the appearance of steam in 2D.Create one long steam simulation to use throughout the entire sequence.
The disadvantage of this is that the simulation would have the same moment in each shot, and the room is large enough that the VDB could get quite heavy, which would be unnecessary for closeups of the characters.
I ended up deciding to do two very long steam simulations, driven by large scale noises. I then packaged the simulations in a Solaris .hda with limited controls. This way, lighting and FX can decide what size the steam should be on a shot by shot basis and place it around the camera without the need to use 200m x 200m sims for every single one of the 46 shots.
Unfortunately, our pipeline does not have GL viewport support for variable density volumes. What to do?
I packaged a proxy mesh with very low opacity in the USD asset so that layout, lighting and FX could see the location of the fog asset in the viewport before raytracing.
nuke - lens setup
Director: "Can we make this more cinematic?"
Animated films don't need lens flares, necessarily, but my capstone film's style seems to be "cinematic." 2.35 aspect ratio, high-contrast lighting, high-detail, hyper-realist textures, etc. Since I'll be busy keeping our FX department floating most of next semester, I'm spending some time now automating as much compositing as I can so that our two lighters have to do as little troubleshooting as possible.
One part of that preparation has been auto-comp templates. Maybe I'll write that up here another day.
The other is a node to add lens characteristics. I'd like to strike a nice balance between art-directability, physical plausibility, and consistency. So, I'm rolling a poor man's version of Alex Fry's setup for Batman 2.
Lens flaws we chose to include: Procedural flares (convolution-based), glow, grain, distortion, vignetting, halation, chromatic abberation, etc. Chromatic abberation is often overdone by my fellow students, so I was careful to limit the artists' ability to make a shot look like a kaleidoscope. Also, halation should really be a thing of the past with the better film technology we have today, but many films are adding it back, and a little warmth around highlights isn't the worst thing.
Most of the components come from Nukepedia, though I went in and made some changes to a few of them for cleaner results and more optimized performance.
Nice and simple.
vex - ribbon ST map
Someone recently asked this question in a discord server--
The eventual solution ended up being much more finnicky than I had expected. The way I went about it was to create a sort of ST lookup that could take certain horizontal stretches of the input and convert them into polar coordinates--the x coordinate of a pixel of the original image would become the angle of the point for a semicircle on the right.
Like so.
The code itself involves some tricky remainder calculations. If we want five squiggles running across our image, then we need to split the left images into five horizontal strips to be bunched up. We can then chop each strip up into segments. Some segments will bend left, some will bend right, and some will stay straight.
// The math looks something like this:
vector2 center = set(0.5, 0.5);
float r = length(set(s - center.u, -(t - center.v)));
float theta = atan(s - center.u, t - center.v);
s = fit(-theta, -PI / 2, PI / 2, 0, 1);
t = r * 2;
if(t > 1) t = 1;