Sunday, September 30, 2012

Tools for curved surfaces

I have a love-hate relationship with NURBS. I love them for the same reason I like vector art: they scale to arbitrarily-high resolutions. I hate them because the NURBS tools often produce ugly artifacts, and it's not obvious how to fix them.


In two dimensions, curves are approximated using a large number of square pixels: zoom in too much, and you'll see the pixels. Vector-based images don't have this problem because they store the curves themselves, not the pixels.

Above: pixels.


In three dimensions, curved surfaces are approximated using a large number of flat faces: zoom in too much, and you'll see the triangles. NURBS-based geometry doesn't suffer from this problem because it stores the curves themselves, not the triangles.

Above: polygon edges.


This all sounds great in theory, but when I experimented with the Houdini tools in the NURBS category, I was repeatedly disappointed by unexpected artifacts in the generated curves. Sometimes the artifacts were tiny, but visible — and sometimes the generated curves were completely wrong. In both cases, there was no obvious way to fix the problem.

Left: subtle artifact.
Right: not so subtle.


As you can see below, eventually I did manage to produce some good-looking shapes. There was no magic artifact-fixing step; I sat down and learned how each tool worked, how they were calculating their results. This allowed my to understand why I saw the artifacts I saw, and guided me towards ways of using the tools which were less likely to generate artifacts. It's better to stick to profile-curves generated through the Carve tool, for instance.

17 down, 195 to go!
Yes, I know there are 20 icons,
but some of those have appeared before.

Oh, and one of those tools doesn't exist,
it's a digital asset I created myself.
Can you spot which one? 

I learned a lot during this series, but I still have many more tools to go through. Houdini has a lot of stuff!

Saturday, September 8, 2012

The tools from which everything else is built

In my quest to learn all of Houdini's 252 Geometry tools, I have explored the 32 node types listed in the Manipulate submenu.

Above: the Manipulate submenu.

I thought these would just be steps 9 through 40 of a long and boring quest of knowledge, but no! I discovered some very important tools in there, and I might never have discovered them if I had not tried to learn every single one of them.

The best example of a well hidden gem is the SSS Scatter node. Neither its icon, its name, or even its documentation gives any indication of what it does.

Poor SSS Scatter probably doesn't get much use.
Its icon hasn't been updated to the new style...
and its documentation is pink, for some reason.

If I wasn't trying to go through the entire list of tools, I would never have tried the SSS Scatter node. When I want to implement a particular effect, I look through the list of names, trying to guess which one could help me; but "SSS Scatter" never sounds like what I am looking for, regardless of what I am looking for. So, what does the darn node do, anyway?

It gives chickenpox.

It creates points all over the object's surface! Very useful-looking. I hope that, among the remaining 212 nodes, there is a version which creates points all over an object's volume, too.


The other reason why there are some useful nodes which I wouldn't have discovered otherwise is that so many of those nodes are redundant. There is a Twist node, for example, which does exactly what it says on the tin. Many 3D packages have a Twist modifier, because in those packages, that's the only way to twist objects; in Houdini, however, twisting an object doesn't need to be a primitive operation.

Twisting is a simple mathematical transformation, whereby points are rotated around an axis by an angle which varies along the length of the axis. I could implement that using the Point node, which applies a mathematical formula to each point of an object. Of course, writing a mathematical formula is much harder than using a pre-existing Twist node; the point is that being able to write any mathematical formula is much more powerful than having to pick among a list of pre-existing nodes. It's the powerful nodes in which I am interested, but they are buried under so many redundant nodes like Twist.


In the Manipulate category, I found three powerful nodes of that kind: Point, Primitive, and VOP SOP. The Point node, as I have already described, allows mathematical transformations to be evaluated on all points. The Primitive node is similar, except it works on faces instead of points. And, last but not least, the VOP SOP. Again, not a very descriptive name nor icon, but how much raw power!

Like the Point node, the VOP SOP also applies a transformation to all points. But instead of using a hard-to-read and hard-to-write mathematical formula, you can double-click on the VOP SOP node to dive inside and manipulate a sub-network. There is a whole new world with 229 extra node types in there!

32 down, 212 to go.
Plus 229 inside the VOP SOP sub-network.
Plus 74 at the scene level, 98 at the channel level,
138 at the compositing level, 41 at the render level,
67 at the particle level, 56 at the texture level,
264 at the dynamic level...



At this rate, I don't think I will ever master all of Houdini's nodes.

Monday, September 3, 2012

The first eight tools

One trinket for each tool in the Edge category.

After I discovered that development time is linked to familiarity, not complexity, I began a quest: I want to become familiar with all of Houdini's 252 geometry nodes, one at a time. Here are the first eight.

The goal is not to visually represent the effect of each node; Houdini already has node icons for that purpose. Instead, the goal is to for me to play with each tool, getting a feeling for what it does, and combining it with other nodes in order to get a simple, but nice-looking result. If you want to follow along, I recommend that you try to reproduce my trinkets, with no other indication than the picture of the final result and the name of the main tool I wanted to illustrate. Trying to get to a specific result will be harder than just trying to get something nice, but the extra challenge will be worth it: learning how to use a piece of software as a game, through a series of challenges is much more stimulating and rewarding than aimless experimentations. It's true! I'd go back in time and challenge my two-hours-younger self with the above image, if I could.

For the rest of this post, I would like to reveal the steps necessary to create the parts of this image which are not part of the game. This part, I am sending to my future self, in case I forget the intricacies.


First, the lighting. There is no light. When there is no light, Houdini adds a default light behind the camera, and that's what you see here. Except for this:

Artificial shadows.

By default, Houdini doesn't render any shadow. This causes the inside of the sphere to have the same color as its outside, which in turn makes the 3D shape hard to see. I'm sure there must be a way to somehow turn on shadows, but for now, I used a trick: I painted the inside of the sphere in a darker shade than the outside of the sphere.

If this was a real physical object, that would be it: the two sides of the sphere would be distinct, and I could paint each side a different color. Virtual spheres, however, store their color in their vertices, and that color is used by both sides.


Implementing a two-sided material was harder than I thought, but in the end it thought me a lot, and I am glad that Houdini does things this way. In any other 3D application, I would be looking through the material options, looking for a "backface color" field or something like that. If I succeed at finding the button, then the problem would be solved, and I would then know how to make two-sided surfaces. If an extensive search revealed that there was no such button, then it would mean that two-sided surfaces are not supported by the application, and I'll have to live without them, end of story.

In Houdini, however, giving up is never the solution. I wish more applications were like that.

After I failed to find the button, I double-clicked the default Clay material to see how it was implemented. I played with the wires, unplugging and re-plugging them to see what they were doing, and that allowed me to figure out which one was responsible for the color. I tried to force a green color, to see if I knew what I was doing, but the entire surface became flat — clearly, that was the wrong place to interfere. I continued to investigate, and found another plug which yielded a better result. Aha! That's where I should plug my two-sided apparatus.

Playing with wires.

I then added a few nodes to check whether the surface normal is pointing towards the camera, and if not, to darken the color by an adjustable amount. At each step of the way, I could debug my network by plugging an intermediate result into the color output and observing the rendered result. On that subject, an important remark: fancy materials like this one are only visible in the Render view, and not in the Scene view.


After the shader, I moved to the Compositing network in order to join all the inputs into a 2D table. In the past, I had exported all the individual images and layed them out in Gimp, adding some text as needed. This strategy has the disadvantage of leaving the procedural realm. Once I render a 3D model and process the resulting image inside Gimp, it is too late to go back to the 3D model and make adjustments. Very often, I only notice erroneous details once the image has been posted on this blog; at that point, I either adjust the model, re-render, and re-process it inside Gimp, or, more often, I give up and hope nobody notices.

But why use Gimp? Houdini has procedural 2D tools, and the only reason I wasn't using them was because I wasn't familiar with them. I decided to fix that! It was again harder than I thought, but it was worth it, because I did change my models often afterwards.

The first step was to render the different models to different files. The easiest way to do that is to render a different model at every frame, and to render the animation to a sequence of files. I did this using a Switch node, switching to a different input at every frame.

Yup, that's a lot of inputs.

Then, we need to get this sequence into the Compositing network. I first tried a Render node, but it was always complaining about a failed render for some reason. I had to render to a sequence of files, then load them into my Compositing network using a File node. Even that was hard, because the renderer was quitting early, without writing the files. When that happens, the easy solution is to save and reopen the project (no need to quit Houdini).

Once I got the sequence of images inside the Compositing network, it was easy to arrange them into a table using the Mosaic node, and it was moderately easy to reorganize the images by reordering the inputs of the Switch node. The hard part was to add the text: there is a Font node, but it took me a long while to figure out that the reason I couldn't see the text was that it was rendering the font to a separate image plane! I can see how that could be useful, but I don't think it's a sane default.

Above: the reason why you can't see the output of your Font COP.


Finally, I added a few Subdivision and Facet nodes here and there to make the models look nicer, but alas! Once I turned off the Preview setting in the render pane to admire my high-quality renders, I saw a few inexplicable lines between faces which were supposed to be sharp.

Subtle, but annoying.

I still don't understand what is causing this, but the solution was to turn off Ray Variance Antialiasing, from the Mantra node's Sampling properties.


Hope this helps, future self!