#brushrig

[humansbgone]

You will all be delighted to learn that I have successfully created the rhombicuboctahedron!

[humansbgone]

Here, you can see at work the feature I'm calling "outline snapping." It takes some line art that you've drawn of the character, and a model that you've lined up approximately, then tries to mush the model to fit the line art!

I have to say, I am ASTOUNDED by how well this turned out (to say nothing of how quickly and easily I was ultimately able to get it done). This is an extremely naive method. I did not have to manually select which part would have to be mapped to another; I did not have to lay out multiple positions in 3D space to project the reference image onto so they would line up better. Instead, right off the bat, it seems to know which part should match to which. Especially impressive, given this is some pretty old line art that doesn't totally match Sophodra's current design (as you can see by the noticeable pronotum/neck collar in back)!

Currently, this works by lining up the drawn line art, line art I've generated from the model, and the model itself, then shrinkwrapping them all to one flat plane parallel to the drawn line art (squashing the model flat). With the 3D model and its generated line art squashed, they match the drawn line art's 2D dimensions better.

Then, the generated line art is shrinkwrapped to the drawn line art. This normally would mess up pretty badly, but I was able to keep it behaving nicely by limiting the range it shrinkwraps within, so that generated lines will only try to line up with drawn lines that are close to them.

After this, the flattened model is then shrinkwrapped to the generated line art. The idea was that it would better with more similar line art as a base…but, trying it with shrinkwrapping the flat model directly to the drawn line art, I'm not actually noticing a difference. It might even work a little better without the extra step. So, even more streamlined than I thought. Wow! Still, good to have the correspondence if I need it later (especially if I want to transfer color or line thickness from the drawn line art to the generated line art).

Next, I just take the difference between this model that has been both squashed and shrinkwrapped, and the version that was only squashed. I then blend that difference with the original model based on how far away it is from the flat plane that was used to squash it.

In the video, offscreen I am scrubbing up and down a value that controls how close the model needs to be to the plane to get shrinkwrapped. As you can see, the higher it goes, the more aggressively the model gets flattened against the plane to match the line art.

As I said before, this is an extremely naive method. I have plenty of ideas to counteract the flattening, so that the model keeps its three-dimensional shape while still conforming to the line art.

That said…the flattening is not necessarily a bad thing. If you're trying to ape a 2D look to begin with, it can even be desirable for certain camera movements!

As you'll recall, last week I said it might take a month to finish up the last four major feature prototypes. However, as you may have also seen…I'm already done!!! Outline snapping only took an extra day to finish, and fur only took a few days to test all the features. By the time I finally reached physics and animation curves, I realized that in prototyping all the rest, I had already figured out everything I would need for them!

Now, the final stage: Putting everything together.

At the moment, I'm taking a little break before I plunge into the next part. I found some tutorials with better ways of doing some things I was already doing, as well as simple methods for features I thought would be difficult enough I'd have to implement them in the next version. I'll step through those, then start on actually creating BrushRig!

The first part of setting up BrushRig will be figuring out the basis of the entire system--something I'm calling a "BrushStroke." I touched on it a little in previous updates, but there's no telling how much the final implementation could deviate from those plans. More on that next week, hopefully!

So, that's a whole month shaved off! For now, let's keep the estimate of another month for completing BrushRig, or at least getting in a state workable enough for a test run on episode 12. Then, episode 12's storyboarding work can resume!! I'm kind in shock that it's gone this rapidly and this smoothly. I can't wait to share it with all of you, both the episode and the tools! Until next time!

[humansbgone]

Thinking I'll go back to BrushRig instead of Flesher Studio after all, because

1. Without the emphasis on rigging, people might think that "2D art to 3D motion" means it's an AI thing

2. All the Brush-themed names become Flesher-themed names. BrushStroke becomes FlesherStroke, BrushMotion becomes FlesherMotion, and BrushLight......

[humansbgone]

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!

[humansbgone]

I couldn't fit all the sketches into this image, but $2+ patrons can see the rest here:

$2+ Exclusive: Extra Sketches | Rev Storm

Get more from Rev Storm on Patreon

As you can see, I'm getting excited about sketching again!!! These are the kinds of sketches I was doing constantly the first couple years of work on HBG--getting a feel for the characters, especially Sophodra. Figuring out her personality, how she moved, how she posed, how she emoted. (I'd already been sketching Rose for years before this, but it took much longer to get Soph down.) It was a key part of the process, forming much of both my understanding and excitement of the project.

But for years, focusing on just getting the animation out, I'd started to lose my will to draw. I just made models, and animated them. The boards only needed to be there for guidance, so they didn't need to be especially well drawn, especially since the models wouldn't be able to match them anyway.

But now, with this system, it will be possibly to do 1-to-1 model to storyboard correspondence! Now, finally, you'll be able to see Sophodra as she was always meant to be seen!!!! This is a huge deal for Sophodra in particular--her poses are so dynamic, body so stylistically fluid, and eyes so cartoonishly expressive, that the CG could never begin to keep up!

It's also key to the "translation" dynamic of the visuals, in general. Characters need to be able to flow smoothly from one visual translation to the next. Now, that'll finally be possible!

On that note, I've still been hard at work on BrushRig. Coming at that from two angles: continuing plotting out the overall structure, and resuming implementation!

Starting with implementation, I've made very good progress: both the slice skinning system and the rotation system are roughly complete!!! Slice skinning means a unit stroke (a line with the points regularly spaced in a straight line at the center of the scene, corresponding to how many points the input stroke is made of) can be dynamically skinned based on a few user-designed cross-section shapes. Rotation covers how this skin rotates along the stroke/line! Rotation is mostly working, though there are some quirks I need to work out to get it rotating precisely accurately.

Now, I just need to get the stroke skin moving with the original stroke. Then, I can bring in rotation! It'll be easier to fix the precision issues when I have the unit stroke to compare against. Then, just a couple extra things to fix (caps on the ends transforming as well, more skin subdivision around joints), and...we'll be done with the basic atomic unit of BrushRig!!!!!!

Next will be integration with the physics system, which should be pretty simple. I was thinking I needed to incorporate my existing IK system as well, which was going to be multi-step and a little complicated for full integration...but, I think the existing features of BrushStrokes and the physics system may cover everything together as it is! No need for inverse kinematics when we're weighting influence independently of a parent-child system to begin with, and using stroke subdivision to get tweened positions along a stroke--also, since the user decides how much distance limiting is actually used to begin with during the posing stage, which only uses FK going from active points. This dramatically simplifies and lightens my workload, and means we have jumped ahead of schedule yet again!!

At that point, the next direction I can go has a few fork points. As I said last week, I may pause BrushRig work and move on to storyboarding soon. Then, when I got back to BrushRig, I would prioritize getting storyboard to animatic conversion done first. However, I would want to work on storyboarding when the weather starts getting nice enough that I can go out to parks and work a little bit. That may be happening next week!

If next week's weather isn't as nice as promised, then I'll probably keep going with BrushRig. In that case, the next step is as exhilarating as it is bewildering, because we are now in the advanced stages: system structure, HUD, automation, and import!!!!

That means, we are finally at a point in the project that I have NOT thoroughly plotted to death, because they all these features seemed so far away in the future. I have lots and lots of ideas, of course, and I have been making headway solidifying them as I've progressed...but, we are now at a point where remaining planning on BrushRig will be almost concurrent with actually implementing that planning!!!

After that, it's pretty much just tweaking visual elements with features I've already made!

What all of this comes out to is this: the next stages of BrushRig will be something I can do concurrently with episode work, because that very work can be used to test the systems as I develop them! Once the system structure, automation, and import are working, they can be used to replace the modeling and rigging stage of the workflow, for both characters and props; as well as to implement things like walk cycles and randomized behavior, to simplify the animation stage later. Once the visual steps after that are done, they can be used for fur, textures, lighting, etc. Then, once the HUD is complete, animation will be possible at a level of automation and customization that I never could have dreamt of before!!!

I haven't even touched on my tagging/link/folding system and how it replaces the traditional parent/child object hierarchy, but that's enough for now. Rest assured, even with as much as I have planned (and it is a LOT), it is coming closer and closer to completion...with even more planned after this episode is released. I can't wait to show you all. Until next time!

[humansbgone]

"...but we donn't yet know what you are. Do we, mmy child?"

Another look at Apith the honeybee, from Claire's gorgeous storyboards! I have so much I want to say about this scene, but it's better if I wait to show you. By the way, be sure to check out Claire's Instagram!

Instagram

Create an account or log in to Instagram - Share what you're into with the people who get you.

This week, I came to two major conclusions:

There is simultaneous much less and much more work left to do than I thought!

The bulk of that works needs to be done all at once, in one big step, NOW.

The core of this came from the startling realization that, apart from import and export, I really do not need to be involving bones in the rigging process. At all. There's just no longer any reason to. Converting back and forth between bones and Geometry Nodes mesh constantly takes up some overhead, in addition to being a pain to do. Not only that, but it limits a lot of things by restricting how much can be dynamically generated! It's easy to add new strokes in Grease Pencil or Geometry Nodes, and you can delete them just as easily. But adding new bones is significantly more difficult, and breaks old animations. Not to mention all the overhead incurred in setting up a fragile network of hidden bones to do something that Geometry Nodes can do instantaneously, without any of the customizability. There's no longer any reason to use the tweening system, either, since the new system allows for lightweight physics and many other custom touches! The final reason to use it was for ease of rotation...but, now I've got a better system figured out for that, too!

In fact, despite the name, BrushRig at this point barely qualifies as rigging at all! No armature, no weight paints--don't quote me on it, but I think I have gotten it down to a point that all mesh is being generated live from drawn Grease Pencil strokes. This means no worrying about ugly mesh deformation, because the system is aware of the underlying shapes involved. And no rig needed, because I'm just mapping the transformation of one stroke to another! This is what I'm calling "stroke mapping"--every stroke can be used to control the position of another stroke to any degree. Multiple strokes can also be used to control a single stroke, and it can also go both ways depending on which stroke is active at the time.

While CG bone-style animation will be possible, you could just as easily do the entire animation using only traditional 2D animation techniques!! Because of stroke mapping, however, this is still simple. Instead of moving a bone around, you can just draw a gestural stroke to show how how a part should move!

I also realized that animation strokes and physics--two major things that I'd been anticipating a lot of time and trouble to completely integrate--are doable as just simple tweaks of other things I've already gotten working. Animation strokes are just another way of using stroke mapping to affect tweening; and all that remained on physics was collision. I was anticipating some work with a custom hitbox system...but Geometry Nodes is already checking how close a given point on a stroke is to other points to keep them from floating apart, so if I tweak that a little I can easily avoid self-collision! The stroke already has thickness for mesh generation, so that tells me the radius I need to check right there. Adding a few meshes for external objects shouldn't add much overhead, either. And then mass and friction are just a couple multipliers to add!

However, realizing these things was just the beginning. While ultimately simplifying things, they meant my original plans needed some big adjustments. Almost everything that remains depends on the core design of the BrushStroke at a fundamental level, not just for feeding into the bones. So, to keep from having to fix a whole lot of things later, I need to plan a whole lot of things later.

Like I've said, all the component parts of the system are done! I know that the individual pieces work, so I don't need to go into Geometry Nodes and test them. I just need to figure out how they fit together.

So, this week has been almost entirely pseudocoding. Instead of going ahead and implementing things off the bat and panicking when they break, I just work out on paper exactly what goes into what.

And there's been a lot to figure out. The features I've listed out here are only the tip of the iceberg. Then, figuring out the most effective way for one feature to feed into another...for example, the custom rotation system. It doesn't make sense to rotate a stroke the typical way on its XYZ axes, because rather than one square object, you want to think of it as a cohesive chain. Besides that, the root Grease Pencil strokes don't keep track of rotation along the stroke!

So, I've been figuring out how to integrate my custom Geometry Nodes node for transferring rotation between parts using generated mesh squares (and I'll be needing the squares just so Grease Pencil knows something exists that needs rotating, and then I'll need to map those to more Grease Pencil points so it can store that rotation), Grease Pencil's default transformation system, and the custom IK system I've made for keeping limb joints from popping all over the place. I think I finally have a cohesive scheme to it! While local XZ (vertical and horizontal) rotation is the same, local Y rotation (rotation along the stroke, or "twist") is inferred from the position of the stroke's inner points. If you move a point, you probably want it to keep its orientation relative to the ends by twisting a little. Additional twist is a separate thing you stack on top of it. A TON of thought has gone into how exactly this works, but this post has already gone on long enough and still isn't done, so I'll move on.

Ah, and let's not forget about custom slice shapes--or, cross-sections, for defining the shape of a stroke along its length! By default the mesh that Blender generates from a Grease Pencil stroke is just one single shape extruded across it, but I need my strokes to change shape as they go! For example, if I were making a human torso, I wouldn't want it to just be a simple tube--there are all kind of dips and curves to think about! Not to mention, those cross-sections will change shape when the rest of the body moves...so, I also need to take into consideration stroke mapping for the shape of the stroke!

Another big problem is how all of this will work outside the hood. That is, where the user can see and interact with it. The interface needs to be a balance of intuitive, consistent, powerful, and customizable. Hard balance to strike.

There's also a whole custom modal to make, with a custom toolbar. See, the features I need for this are currently split across a bunch of different types of editing modes in Blender, which requires a lot of extra mouse strokes to do one simple thing. That on top of needing an easy way to switch between different strokes. I also want to map a lot of custom shortcut keys, which might interfere with the user's existing shortcuts. So, I need a modal--a custom type of editing mode, basically. A pretty ambitious thing to set up, but it really won't work any other way.

Not to mention, there's figuring out the how stroke mapping representations will work...and how difficult Blender's data types and menus are to work with, to the point it would probably be both easier and look better to make a HUD out of actual objects in the scene wherever possible!

Ah yes, and import from a regular mesh and bones. Can't forget that. Or aaaalll the other things...like boolean mesh operations on strokes to make more complex strokes....

So, despite not having produced a single thing I can show off except filling two notebooks in as many months (and figuring out how to implement blue noise in Geometry Nodes, for more satisfying randomness; and also figuring out more story plot points!), I have been doing a LOT of work. Hopefully, by next week I'll have a thorough enough plan that I'll feel confident going ahead and producing something concrete. If I can get basic rotation and slice skinning going on BrushStrokes, as well as a working stroke map system with folds, then I'll be able to import Sophodra's model to begin testing the rest with as I go! And I think that'll make things a lot more interesting for all of us, myself included.

After that, the remaining BrushStroke features should be feasible in another week or two. Then, maybe another two weeks for all the interface stuff. Hard to gauge that one especially--I've never made an interface this extensive before! Let alone a system this extensive, period...it's all been little standalone utilities before now. I'm definitely excited to meet the challenge, though!

Finally, a week or two to complete the last few features. Thankfully, these should be pretty simple, since they're mostly just tweaking a bunch of existing things to make them look nice (storyboard to animatic, outline generation, outline snapping, fur, fake lights and shadows, compositing).

So, for safety, I'm setting this at another two months. Given how quickly progress to this point has gone, however, I'm doubting it will take that long to get back to episode work. Especially since, before long, I'm going to be itching to just start testing the storyboards with it as I go! Until next time!

[humansbgone]

This week was lots of organizing! Lots and lots and LOTS of organizing. Not just for file structure (not to mention moving over to a new writing program), but also for story! I was hit by another blast of creative inspiration, and refined the upcoming plot in even more detail than before. Before I was pleased enough just to have gotten all the big things sorted out and figured out a better way for composing episodes, but now I've gotten all these little details figured out! Themes and parallels now tie in better than I could have hoped, and I found places for all kinds of minor bits and characters I'd hoped to include but given up hope on finding space for years ago!!

As you may have seen, I decided to split the Formicosa arc up into two seasons (for a total of four seasons for the entire series). Now, instead of episode 12, this will be episode 1 of season 2! I feel like enough is changing with this episode that it feels sort of like a soft series reboot, so starting a new season feels appropriate.

You may have also seen that I was going to change BrushRig's name to Flesher Studio. I ultimately decided against it, though--I want it to be clear that this is not AI-powered, and I think focusing on the rigging aspect helps with that, even if it's much more than a rigging system. Besides that, renaming some of the systems became kind of, uh, unfortunate. BrushStrokes to FlesherStrokes, and BrushLights to…..

Besides that, I took some more break time to relax, and work on some side projects. Of course, like everything else, they will tie back into BrushRig and HBG eventually.

Unfortunately, none of this very visually interesting to share here. So, let's take a look at something I finished back in December! If you're a $5+ patron, you can see the full video for this post here:

$5+ exclusive: Old Eye vs. New Eye | Rev Storm

Get more from Rev Storm on Patreon

You might remember that last year, when I started work on episode 11, I was hyped for a new feature I'd figured out: eye generation from drawn 2D art! BrushRig is an expansion of that system to be used for the entire character, but I've still kept the workflow for eyes in mind as a special thing. In the video here, you can see a side-by-side comparison of the improved system next to the old one (with the faint red strokes indicating the 2D drawings they're generated from). There are lots of little improvements here, and the new system is not yet complete, but the key takeaways are this:

The eyebrow can act as a boolean to cut into the eye itself when lowered. This is extremely important for Soph's expressions, since her eyebrows just kind of float in space, and it can be very difficult to see them against different backgrounds. Previously I was trying to mash her eyeballs into shape manually to fit the eyebrows, or just relying on the eyelids to communicate it for me.

The eyelids actually exist now! Until this point, I had been faking them with textures in the shader, because that was the best way to get an eyelid wrapping to a cartoony eye no matter how it warped, especially a mantis eye that needed to have an eyelid extending all the way to the back of the eyeball. Before episode 11, this limited the range of expression I could do, since the eyelid needed to line up with a straight line. In episode 11 I expanded the expessiveness of the eyelid shape, but this left some unfortunate jagged artifacts because the shader could only take so much information from Geometry Nodes without being bumped up to a ridiculously high resolution. Fortunately, mesh booleans are now so fast that just generating actual eyelid models is now way faster, in addition to looking way better!

There are lots of other little things to note: BrushRig will make sure the drawn strokes and the rig keep a one-to-one association instead of getting offset as the rig moves around; I'm not doing the little eyelid creases anymore, because they're a pain and I don't think they looked that great to begin with; the new system means I can add as many additional strokes as I want, to make the eyelashes look more or less sketchy as needed…etc, etc. There are also various small improvements I need to make, as you can see with how the eyeball snaps to the eyebrow chaotically unless at just the right distance. For now, however, good enough!

I've gone through the tutorials I mentioned last week, and figured out lots of improved methods, as well as easy ways to incorporate features I'd initially planned for farther out! Now that I've given myself a chance to catch my breath and settle my thoughts, I feel confident to push ahead with starting actual work on BrushRig's pre-alpha next week. When the pre-alpha is complete, I will test it with production on S2 01 (season 2, episode 1). Before then, however, I might make the pre-alpha available to $5+ patrons to download. I need testers, and if any of you are interested, I would love to get your feedback!

So, more solidly: Next week, I'll try to get the atomic BrushStroke unit going with custom slices, physics, and the IK system (with some improvements). I may try to get branches and sections going, too! The week after that, dynamic stroke subdivision and one-to-many stroke handing, as well as dynamic dependency direction switching…then, it'll be time to automate everything and set up the user interface! Anywhere from two weeks to a month for that.

All features after that are mostly done and just need some tweaking, apart from the motion stroke and animation gadget system. Let's say two weeks for that. So, all in all, a month to a month and a half remaining to get BrushRig to pre-alpha. Closer and closer…. Until next time!

[humansbgone]

(This is a progress update for Humans-B-Gone!, an animated series by Rev Storm that you can watch here: https://www.youtube.com/humansbgone )

Back to work on BrushRig core with physics! Nothing too flashy to show off here, but I like how this stroke ended up moving like a horsey.

The main point of this system is improved tweening. Instead of just smoothly and mechanically interpolating between two frames of animation, it takes into account velocity and mass (just a little) to give you a more natural feeling to the automatically generated movements, even before editing.

It will also act on posing (if you want it to). By default, posing characters for 3D animation is like stop motion, only even more meticulous--you only have one hand to pose, instead of two, and you can only move one single bone and its children at a time, unless you've painstakingly hooked it up to move more bones. These bones have to be specified one by one, however, and even more painstaking specification is required to make them respond to still other bones to avoid things like collision.

With this system, posing would be more like working with a puppet. You don't get parts clipping through each other, gravity is taken into consideration a little, and any part moves according to what it's attached to accordingly, influence by how big and heavy the parts involved are.

The crucial takeaway: You can animate the whole character nicely by moving just one point.

On top of that, collision with other objects means your character reacts to things like floors. That means walk cycles will be much easier, and much more realistic--instead of only putting their feet down where the animation has predefined that their feet will be at floor level, the characters' feet just stop when they hit the ground, and can't go any farther.

And a bonus cool thing: Due to the strokes having their own thickness, they can take self-collision into account without having to run a ton of calculations on a separate mesh!

Unfortunately, a host of health issues and exhaustion came to a head this month, and I wasn't able to make as much progress as I would like. I'll go a little easy on myself, though, since making even a basic physics system is kind of. Uh. Hard. Fortunately, I've taken some time to rest, and I'm feeling much better now!

Currently, I need to get self-collision for each point working in relation to all other points at once, not just one close point at a time. I also need to sort out the order of position changes, so that velocity, self-collision, gravity, angular momentum, minimum/maximum segment lengths, and the movement towards the next animation frame are all playing nice together.

Then, it will be time for collision with the environment, bouncing, and friction. Then, angular momentum for lengthwise rotation. Optimistically, I would be able to get all this done next week!

After that, it will just be a matter of improving and automating everything for stroke editing that I have so far. Then, at long last, it will be ready to start testing by importing Sophodra to the system. So close to the meat of it, now. Until next time!