For the 'Project Dog Walk' game I was tasked to create "layout rigs" for the characters that would be used for pre-production. Now, I must confess, I had never rigged for a game project before; which guaranteed that this would be an interesting learning experience with plenty of bumps on the road. Here's what the character designs looked like in those early stages of the project:
Since the rigs were only for the pre-production, the pressure wasn't as high and I could rely on my previous rigging experience and create light-weight rigs from scratch. Here's some of the limitations and goals I had to keep in mind:
Here's the light-weight layout rigs I made for the characters:
Overall the layout rigs worked as intented and there were only minor tweaks needed. They were of course based on early character designs which had since evolved further. Here's the final character designs, modelled and surfaced:
At this point, it became clear that because of scheduling I would be tasked to create the final production rigs. Gulp. The pressure was on. And since the layout rigs seemed to work pretty well so far we could save time by basing the final rigs on them. Furthermore, if I managed to make the layout rigs and final production rigs more-or-less compatible then we could also re-use a lot of the preliminary animation that had been done so far. This meant I would be beholden to certain decisions and design choices made early on when I knew less about Godot and how it works with rigs - but in these circumstances there's always a trade-off. Here's the final version of the production rigs, which include additional feature requests:
The production rigs worked surprisingly well but of course there were some unforeseen bumps in the road. Each issue required a non-destructive solution that was backwards compatible and quickly implemented so that the production could keep going. To give some examples, here's the three biggest ones:
Once the animation has been exported from Blender, it's completely baked down by the time it's in Godot. That means that when animations (or poses) would need to be dynamically blended together, it became very important that the deformation bones were all in a direct hierarchy, to avoid weird artifacts or segments of poses getting misaligned. When rigging for an animated film this is not really an issue and there can be very good reasons why you'd want your rig not conform to a strict direct hierarchy, like when you want to add a simple hinge or an IK setup. Fixing this ended up being a bit tricky because I needed to come up with a solution that was non-destructive to what was already there and this was needed for every single hinge and IK. But I love a good puzzle!
Usually for an animated film, every prop has their own rig and as characters pick up and drop down props they simply get a copy transform constraint which we toggle on and off on a single frame, tailored for each shot. In this project, the props needed to get a copy transform to a specific bone on character's rig which would be used for the entire performance so it could easily be triggered on the Godot side at the start of the animation and then the baked animation on that bone would take care of the rest. In this case the Pinda character is constantly interacting with various props and many of them might already be "attached" to Pinda. So the solution was to just add bones for all these various props in Pinda's rig. It wasn't super elegant but it got the job done and we could just add these bones as the project went along without it accidentally interfering with anything we had previously made.
We were pretty late in the project when suddenly we noticed that Chocomel's toes extending like crazy in the animation where Chocomel wakes up and stretches their legs. It was caused by the IK legs stretching really far, Godot interpreted it as the bone being scaled, which in turn was inherited down the hierarchy to the toe bones, resulting in scaled up toes. Why did this problem not show up before? We had simply not had any animation at that point that required the IK legs to stretch so far. The solution was to replace the stretched bone with two bones on each end, giving both a tracking constraint so they always point at each other and divide the weight painting between the two of them. And in the interest of time/resources, this fix was only applied to the elements causing problems: Chocomel's forelegs and Pinda's arms.
Overall I'm quite happy with how these rigs turned out. There were lessons learned, of course, and in hindsight I would make a bigger emphasis on separating the deformation bones and only use the "two tracking bones" solution instead of any IK stretching. But you know what? The rigs work! Here's some animation I made using them:
And here they are in the game:
Hope this shines a bit of light on the rigging side of the project and I hope you enjoy the game when it releases!
Can you share the model of the pen display and stand Pablo is using? I like how the keyboard nicely fits under the stand.
Join to leave a comment.