|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:
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.
|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!
Hope this helps, future self!