I’ve had a very hard time with the Houdini tutorials lately, and so I was proud to even get through the first forty minutes following along. My smoke looks okay, but it’s doing something weird towards the end of the simulation, when a large box of light develops.
I was able to follow along until rendering, but then this happened. I’m going to book a session with Mehdi on Monday and just ask him what’s going on, I suspect there are multiple issues with my file.
UPDATE
I spoke to Mehdi and he informed me that the only issues were either with my graphics card or not hiding the geometry. I rendered again with the geometry hidden and was able to produce this:
The density adjustment slider was really interesting to me, and it’s cool to be able to choose between pure flames and a more smokey fire.
When it came time to render our simulation, I was at first met with the same issue as before:
But happily, I was able to solve the problem on my own this time! I realized that it was because the material shader name had not been updated and I reassigned it as well as making sure all the geo was hidden. As soon as I did, I got this image:
I feel that this week helped me understand rendering better and continued to help me get accustomed to the Houdini workflow. Being able to find my own material shader issue is a big step in the right direction of understanding the way Houdini nodes interact.
This week I was able to follow along all the way until the point in which we got back into the particle animation. For some reason, my computer crashes every single time I try to render even one frame of it.
But I learned a lot about rendering just from following along with the rubber toy example, and I will try to render one of my destruction sequences using this knowledge.
Method 1 (Voronoi Fracture) vs Method 2 (Grid with Boolean Fracture) vs Method 3 (RBD Material Fracture)
I found last week’s tutorial very easy and fun, but I expected this to be a little more intense, as it says on the tin. However, it did take me about 3 hours to get through the first hour of the tutorial. Most of the extra time it takes me to get through these is spent researching terms I don’t understand like “voronoi”, “vex”, “VDB” and “voxel”, going back to repeat the step when it happens too fast, or going even farther back to figure out why my results don’t match his. While the process makes sense to me overall, I often don’t understand the significance of many of the little steps or how Mehdi is able to tell that they are necessary. I’m also only about 80% confident that I understand the goal of our work in the first hour. I know that we’re creating a realistic fracture of the objects, but is exploded view the end result of the destruction or simply a way to review whether or not the fracture seems realistic? Despite this, I am able to follow along, and often understand it better towards the end of the tutorial, so perhaps it will all make more sense soon.
Side note- here’s a video I found that helped me get on the same page really quickly.
Hour and a Half In
Somehow, this took me even longer, and only for 30 minutes worth of tutorial. I was just about ready to give up for the night when I finally got to see the product of my work- this beautiful destruction- for the first time, and regained motivation.
I feel that, as with the last tutorial, it helps it come together for me to be able to visualize the product of the long line of work.
After a couple Houdini crashes on my slow computer, I figured out how to get my boolean fracture linked up to the DOP network for an even better effect.
I got the rbdmaterialfracture to run, but it’s incredibly slow and not really doable on my machine. I’m going to follow along with what Mehdi is doing in it so I can learn but I’ll have to keep my Houdini on manual update.
Day Two
Before plunging back into the tutorial, I took a mini break to smash something else out of sheer curiousity as well as to test how well I retained the skill.
I also wanted to try a building complex, but these are not made of a solid material and I’m not sure how to do that yet, so I’ll finish the tutorial first.
2 Hours In
The polyreduce node was a big help in speeding up my simulation enough to follow along with Mehdi, in addition of course to keeping my work on manual mode. I will keep that in mind in the future as our tutorials continue.
Unfortunately, it looks as though this will be the first tutorial I don’t complete. I got to the point where we create and active and inactive point group on the cabin so that the entire object isn’t moved during the collision, but rather a small part breaks. I copied Mehdi exactly over and over again and my product was always the same- no change.
Stopping Point
The only possible explanation for the problem I could think was that my geometry supposedly has holes. I couldn’t figure out where or how to locate these, though, and I was using the simple geometry that we made during the tutorial.
In the beginning of the tutorial I got confused very quickly. I was having a hard time understanding what Mehdi was talking about when he discussed UVs. The last time I also struggled to understand the concept of normals, which is a similar subject. I did a little bit of research online and found this diagram to be helpful:
-as well as the explanation that UV does not stand for anything but instead refers to the points used on the map, as XYZ are already taken in reference to area in space.
On to the project-
POP Object: a container for particles
POP Solver: toolbox for calculating the physics
POP Source: generates particles on the surface of the object
Scatter: generates points on the surface of the object
SOP Path: sources the object
At first I was worried because I couldn’t see my object in the POP network while Mehdi could, and then realized I simply had to move to a frame in which the points had begun conglomerating.
I was already really excited about my simulation with still half an hour left to go, and was surprised when Mehdi said “let’s make it more interesting”! There’s so much in Houdini I don’t know, I can only imagine all the awesome things that we could choose from.
I rendered our first flipbook:
I specifically chose to work with a little less points than Mehdi, just because I felt like they were obscuring my character and I didn’t like it aesthetically.
But in the next step I was a bit confused. Mehdi created a sphere as a test object to work on our point attributes with, but when I did that, Houdini would not let me. Logically, the point simulation we created was coded to work with the group testgeometry_crag1, so they would not apply to the sphere.
I’m not sure why Houdini allowed Mehdi to do this, unless I missed a step along the way.
I managed to resolve this on my own, but the issue I’m proudest of resolving on my own was the inability to see any particle at all at frame 0- I remembered that we set the beginning frame to 235 in our popsource and went back to include all the frames. That, and I once again adjusted the parameters in the pscale to my own liking. I actually turned the birth rate way back up and made the particles even smaller.
Unfortunately, Houdini then crashed. And it was about 1 AM, so I called it a night.
Next day, though, I returned, with my brain function switched on, and I found it super easy to recreate the finished product.
Time to learn Houdini! Despite my growing trepidation related to the constant reassurances that it will be fun after a grievously long learning curve, I went into this first tutorial eager to learn. I tentatively want to declare my specialization as lighting and texturing. I still have a very long ways to go in this area, and in fact I’m really just getting started. But I’ve heard from everyone that Houdini is the software to use for this and I’m excited to see what I can do.
Here’s some of the most important notes I took during the beginning of the session.
Vocab
obj > object
img > compositing
ch > animation
mat > materials
shop > shaders
out > rendering
stage > USD (?)
tasks > pipeline
SOP: old term for geo –Surface OPerators
OBJ: object
DOP: Dynamics OPerators
ROP: Rendering OPerators
VOP: Vex OPerators > Vex: Houdini scripting language, similar to Mel.
$HIP > file output
$OS > object name
bgeo: Houdini file format that can save anything. bgeo.sc = compressed
1 unit = 1 meter
About half an hour in, I was sure I was lost because Mehdi added a geometry node to his sphere, while I could not find the node “geometry” listed and only had more advanced options-
My menu vs Mehdi’s
-but I realized quickly that it came down to being in the object context rather than the SOP context- the SOP context has many more options as most of the work is done there. I found a couple times that when I was unable to follow along it was because I was in the OBJ rather than SOP context- for example, trying to place a file node.
I brought in my own OBJ file to follow along with the file SOP node- a set of dice I’d used in my performance animation:
I was originally unsure why they are wireframe, and quickly realized that toggling between these options-
-allows for different levels of visibility.
After some trial and error I managed to merge my dice and sphere objects, and scale them down when I realized that a unit is equivalent to a meter. This should be important knowledge down the road.
Moving onto the next Houdini scene. I was stymied for a while because Mehdi, when creating a ROP Geo node for his torus, saved his project under $HIP, and I had changed my project’s path to a specific folder for schoolwork. I kept trying to change the file output to this folder and was unable to locate the geo. However, I went back into the tutorial the next day and realized, upon listening more closely, that $HIP does not necessarily mean any kind of Houdini preferences folder, instead it refers to whichever path the file is saved in, therefore there is no need for me to change the $HIP path to my own- it’s already there. Sure enough I saved it under $HIP and was able to locate it in the geo folder of my project.
$HIP can be a variable, $HIPNAME cannot.
The only other problem I ran into was all the way at the very end.
Somehow I could not stop the raised points from being deleted when I merged the roof with the main cabin.
The way I ended up solving this was simply re-creating the transform node for the points. It still wasn’t working, but I deleted and re-attached the connector and somehow that changed everything. I am not sure how this worked. To me, the tree looks exactly the same before and after I did this.
I moved on to Mehdi’s bonus project: building the cabin with pronounced wood slats. I was able to remake the entire cabin, but for some reason my booleans for the windows weren’t working, and I’m sure that although the cabin looks good there is something mathematically off. I am sure that the Q&A session will provide me with more insight.
Additional questions-
Why create a transform node instead of just working in the viewport?
How does the divide node work?
I’m still not sure what the delete node actually does.
