Here, we see some (very) old concept art! The scene I'm about to add to the script is one of a few that this art is based on. All the beats have been plotted out for it now--I just have to write it. It includes a lot of things I was originally going to save for much later, but I decided I'll spoil you all and share them now!
The scene hasn't been written yet, however, because I hit a snag with Geometry Nodes that demanded more of my attention than anticipated. Namely: ROTATION.
See, transferring positions is easy. Transferring rotation, however--whether from mesh to bones, or even just different mesh islands in the same Geometry Nodes tree--is very, very, VERY hard. Instances, realizing instances, picking instances through indices...so many layers of calculation come into play. (And don't try it without using instances. Geometry Nodes hates that.) Checking for solutions online only goes so far when new Geometry Nodes versions keep completely shattering rotation methods that worked before. And even if you're manually calculating all the correct angles, if you try to combine them, something inevitably explodes!
And you would think that the new Geometry Attribute constraint, explicitly for transferring transformations from Geometry Nodes directly to bones, would make things easier. Wouldn't you think that? Well...for that to be true, that would require that anyone actually release any documentation or tutorials that actually explained how to use it (outside transferring positions, which can be done without it using the Shrinkwrap constraint)! I even tried substituting it by just using the Shrinkwrap constraint combined with the Stretch To constraint, but the Stretch To constraint can't seem to keep up with Geometry Nodes. I was forced to turn back to Geometry Attribute. The only information I could find on using it correctly for all transforms was by tracking down the individual person who contributed the code for it to begin with, and piecing it together from the few examples he provided across multiple sources. But I did figure it out!!! FINALLY.
So many methods plotted. So many tried. So many failed. In the end, it was all for nought--the method that worked was just combining a few simple methods I'd been using for years, but hadn't thought to apply here.
I think I have FINALLY gotten everything working correctly, except for scale. Hopefully, that should be simple enough, but who knows! I'll hack something together, anyway.
Funny thing, though: In the midst of my multiple failed attempts to accomplish basic rotation, I accidentally created an entire functional non-photorealistic lighting system that works far better than Blender's native lighting system for cel shading. Then, I realized I had all the tools I needed to make a second one that was even better than that!!!
This is huge. You might remember that my first update for this episode was talking about some add-ons I'd found to make cel shading work better. Even that required a ton of finagling, though. While it looked better, it still didn't look great--the normals still bounced everywhere, too many light sources would still break the ability to get overlapping shadows, and then just the limitations of the geometry inevitably having awkward, ugly deformations that would in turn cause ugly shadows.
With this new method, none of this is a concern. To fake shadows, all I have to do is shrinkwrap representative light and shadow meshes onto the object meshes, and boolean out any unwanted parts. No time spent calculating lighting or textures, and no resolution information lost--just clean geometry on geometry. Then, I just stick the light and shadow meshes another view layer, and I have infinite potential to tweak them with compositing! None of this would have been remotely feasible before, but with the latest Geometry Nodes version, both shrinkwrapping and mesh booleans are blazing fast. There's no reason not to do it this way!
Now, back to BrushRig. Now that I actually have the rotation tools that I need (hopefully), it's time to try to implement what I'm calling "billboard snapping." If I get it working successfully, I'll explain more on that next week. This update is already a novel, though!
I didn't realize until Claire pointed it out, but I've only been actively working on BrushRig for a month. In that time, I have implemented over half the features planned for this first version (in addition to the unplanned features I accidentally made). That's nuts, because I planned a LOT of things that seemed like they would be pretty hard! Apart from rotation, though, I've been flying through them. Once billboard snapping is done, only four features are left. Then, it'll just be a matter of cleaning up, integrating, and automating everything!
So, next week: write the last scene, go over Claire's final work on the storyboards, and implement billboard snapping.
The week after, hopefully, everything will be in place to work out one last feature before I take over from Claire on storyboarding: outline snapping. Namely, the ability to deform the characters to fit their storyboard art. Better to do that now and get a good idea of what standards the storyboard will need to conform to for that to work effectively!
Exciting progress being made. So many things proven, so quickly. I'm looking forward to seeing what progress I make by the new year. Until next time!