Class 13: Balloon Pop Tests

I moved forward just a bit in my simulation process (skipping the ziplining lego figure for the moment) and started working on the balloon pop for the rubber ducky. I found an excellent tutorial that briefly runs through the process for "fracturing" vellum here and applied the same principles to my own balloon. I first used an edge fracture node on my balloon geometry and output the new points group so I can use them later.

I then used the vellum balloon configure node in Houdini to set up the basic simulation, which essentially treats the mesh as a soft body and applies pressure inside the mesh so it looks inflated. I then sourced the new points group from the edge fracture node into a weld constraint and scaled up the breaking threshold so the mesh pieces would hold together. I then created a point group for the points at the neck of the balloon and added a pin constraint so the balloon would look like it had been taped up and wouldn't fall to the ground.

Within the vellum solver, I needed to output several attributes in both my vellum cloth node and in my weld node. In the initial cloth node, I output both the stretch and bend attributes so I could control through constraints how the balloon pieces behave after the pop. I also changed the scale type in the weld constraint to scale by attribute rather than value and used that in a geometry wrangle to control what frame the breaking threshold would drop and allow the balloon to pop.

I also added a couple of popforce and wind nodes to push apart the mesh pieces and add more disturbance by linking their activation to match the frame the break threshold drops.

Here's a preliminary result. It obviously needs fine tuning and some tinkering to get the pieces to rest upon landing instead of fluttering around, but I decided to use this just to test out if the rubber ducky on top would work.

All I did from here was cache out the initial balloon pop with a vellum i/o node and then read it back into a separate geo container in Houdini using a simple file node. I then set up a simple RBD simulation with the rubber ducky sitting on top of the balloon, which I made a static object, and adjusted a few of the physical properties and collision padding to be a bit more accurate. Here's the result.

Like I said before, it needs a lot of TLC before it's ready to be locked into place, but I now have peace of mind that my initial idea will work; it's now just a matter of getting the behavior and shape I want from the balloon with my preexisting constraints.

Class 11/12: UVs and Textures

A lot of my progress was spent this weekend UV-ing models that are in the opening scenes (the entire bedroom) and refreshing myself on how to use Substance Painter since it's been a while since I've used it. Because of that, there's not a lot of pictorial documentation.

Class 10: More Sims & Presentations

This weekend I decided to start finalizing the beginning part of my simulation so I would have an extremely solid foundation to start the second part of my simulations that involved the stairs. Most of the refinement I needed was making better/more interesting models for some parts of the simulation and to get the secondary parts animated, like the ringer of the clock and the wheels on the car, since any previous keyframe animations were ignored once the mesh was converted to a packed RBD. I thought this fix would be as simple as caching the packed simulation and then unpacking after the cache to access the needed mesh groups and then incorporating the keyframes after that. Fortunately, it was that simple, but it did take a bit of time for me to figure out exactly how to set up my workflow to access the groups. When I packed the object for the RBD, there is an option in the pack node to transfer any selected mesh groups to the RBD object. This worked and I was able to access the groups for animation this way for the clock. However, my pivot points were tied to a certain point in space rather than to the centroid of the object, which caused issues with the animations, so I did end up having to essentially redo the set up of my node graph to set the pivot point when the object was at the origin, do my animations there and then transform the clock to its position in space after.

However, the car wheels proved to be a bit more of challenge. The pivot points of the car wheels were all based at the centroid of the car body when using the hscript centroid command in the pivot transform, even by isolating each wheel on its own. Adjusting the pivot points with absolute values would work when procedurally animating the wheels at the origin, but since the car changes directions during the sim, the wheels would jump around trying to reference the pivot point. This took a while to figure out, but I eventually got the wheels to turn by turning on the check box for deforming active object in the car's RBD node in the dopnet. This got the wheels turning (visualized by a simple randomized color to primitives), but it unfortunately undid all the previous work with the car going down the track, so I had to go back and readjust values to get the look I previously had.**

**including the very sick and epic railslide, as per Joe's request

Once I got the car up and running again, I decided that I would switch to a new file so I could start with a fresh dopnet for the next set of simulations. The car provided an excellent way to transition between files since there is an extended period of time where its just the car and the track in view of the camera, which meant that I didn't have to import any of the geometry previously used. To set up my file to start again, I imported the upper floor geometry and track and copied the transforms from the first file. I then imported the file cache for my car and retimed it so the car running down the track would start at frame 1. This did cause problems with importing the camera (I figured out a way to export the animated camera from the first file as an alembic file, but there was no way to match the retime of the "new" car since the frames from the first file didn't match the second; something to keep in mind if/when I start a new file for another set of simulations) so I did end up having to manually input the values for the first file's camera into the second so it would line up exactly.

Immediately, I realized that my original idea for a bag of marbles opened up a very sizeable can of worms. The bag itself would include vellum/soft body, while the marbles inside and the car would be rigid bodies. I figured a work around for the car would be to reference it as a static object and to turn on active object so the vellum could interact with it that way, but the marbles themselves and the vellum bag was something I couldn't quite figure out. I did have an initial sim of the marbles inside a vellum bag in its own file, but this would only work as a still object. After many hours of tutorial watching, documentation reading, and general frustration, I decided to abandon the marble bag and replace it with a gumball machine full of marbles. This way I could continue working the RBDs while still maintaining the playful aspect of things. I quickly modeled a gumball machine and ran a separate simulation to get the placement of the marbles inside the machine, then cached a single frame of the settled marbles and imported that to act as the new RBD marbles object. This was partially so I wouldn't bog down my already new file with a simulation that didn't need to be seen and partially because it could be seen by the camera. I then used a similar technique on the gumball machine door as I did with the lever on the track (see my write up here for more information on that) and timed the animation to line up with the car as it slides across the lever.

This is where the new and exciting stuff starts. I modeled the gumball machine to have a chute of sorts that leads directly to the door so that the marbles in the top part of the gumball machine fall down that chute and then out of the gumball machine when the door moves. The initial movement of the marbles was pretty slow, and they weren't reaching the edge of the stairs like they needed to for the next step (the Lego man), so I fixed that with a fan node in the dopnet so the marbles would disperse at an angle. Once the marbles were working I added the fan. In my initial sketches, I had marbles hitting a paperweight that pulled the knob of the fan to turn it on. Realistically, the mass of the paperweight needed to pull the knob would not be affected by the hit of a marble, so I began to rework this part. I already had my car, which was moving at a very fast velocity coming off the track, so I thought the force of the car hitting the paper weight would not only be more realistic but also give the car another purpose in the grand scheme of things as well as stopping it so it didn't randomly disappear in the sim where its cache stopped or hurdle into space forever. This took a bit of massaging to get the car to slow down enough to hit the weight and not have it go flying but to also have it hit with enough force to knock it down. My solution ended up being animating the activation of wind nodes to counteract the velocity of the car for a split second to slow it down, then adding back a portion of that drag so it didn't immediately stop. Increasing the friction on the stairs themselves to reduce the amount of sliding and tumbling also helped get a pretty decent result.

The box fan itself was a simple procedural animation of the blades and a keyframe of the knob to get the spinning effect. From there it was time to add in the first Lego man. Getting the marbles to knock him off the stairs was a matter of positioning him in the right spot and tweaking his physical parameters such as mass and friction. To get him to float down like he was parachuting/being affected by the wind (at its current state without the parachute) was adding a fan node to the Lego man's dopnet and angling it to where the fan would output a lot of force at the level where the Lego man fell. For our midterm and for my time and sanity's sake, I stopped here for midterm review and added another Lego man in the path of the first one just to show that the second will continue the sim in that manner.

And here's a rough comp and edit of the machine!

Since the farm was down AGAIN this weekend, I did have to render locally so the quality of the video is not the best, but the motion is still there. Again, lighting is still preliminary, but I think my next step while moving forward with more of the simulation is to begin to texture the beginning assets and begin to lock down some lighting for those shots (I'm debating using volumetrics for the lighting in the beginning to get a "god ray" effect, but still on the fence about it simply because of render times). The camera move up to the car leaving the track is pretty locked down; everything after that still needs some fine tuning. I ran into a lot of both user error and general confusion this weekend but I'm feeling rejuvenated and ready to use the knowledge I gained from said problems to hopefully speed up the remaining steps of the machine and finish strong. I think the major things I'm going to focus on (besides getting everything blocked out; no more animatic placeholders!) will be the parachute and the subsequent balloon pop following the second Lego man.