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.
Updated: Feb 10, 2022
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.
I started experimenting with the matchbox car and the race track a few classes ago using the RBD Hinge constraint, but I decided to abandon that in favor for a more CPU-friendly version of a hinged lever using object transforms. Since I already had keyframes for the lever the car was on, I used those and created a static object out of the lever. Inside of my DOP network, I checked on Create Active Object and Use Deforming Geometry. This keeps the keyframes from the lever and allows it to interact with the matchbox car's RBD packed object.
I also wanted to model the race track inside of Houdini, but was having some troubles getting a smooth and flat surface for the car to roll on, so I used NURBs within Maya and extruded for thickness and exported as an .obj file to use as a static object.
Running the RBD simulation with the lever took a lot of testing/trial and error. I was getting some weird behavior with the track itself, as the car would run along it and consequently fall off the edge as if the track was just a surface and didn't have guard rails. I changed the geometry type within the track's static object node to concave and also lowered the collision padding since I'm working as close to real world scale as I can (Houdini is in meters), and the car sat within and recognized the track's guard rails.
While this helped, the car was either bouncing off the guard rail and off the track or would flip as it went around the curve and would slide down the track. I did adjust the car and track's physical properties such as bounce, friction, and mass to aid this, but it was still happening. I assumed it was because the car was accelerating too much going down the initial slope of the track and the momentum was enough force to make it bounce out of its 'racing' shape once it hit the guard rail. So I added a drag node and adjusted the scale force and torque so that the car wouldn't accelerate as quickly.
This did help a lot. However, at its current state, the matchbox car is doing a railslide on the track for a bit. It eventually self adjusts (and is honestly kind of gnarly and sick) but I would like to smooth this out. I'd also like to figure out how to get the tires within the packed RBD to rotate as they would with a real matchbox car, since some of my current camera move shows that off.
The sphere and box that the matchbox car hits at the end are placeholders for the marbles that are going to bounce/roll down the stairs and knock off the Lego figures. At the moment, I haven't added the environment from the class 8 blog post, but I do have the stairs and railing modeled, so the next step really is integrating that and getting the marbles to flow with the current simulation. I do also plan on remodeling the catapult/ball into something less ugly.