It's bound to happen! I found some more cracks.
Having recently completed a first iteration of my inverse kinematics engine for my ProxyMan tool, I went on to try and make a short animation showing the proof of concept in action. And, I came across a viewport that was very slow to work with. I figured out it was a background copy issue.
You see, programs have undo stacks, amongst other under-the-hood data. These things allow users to undo something. You've all used it before, like control-z on windows! What I found was that because of the underneath architecture, there was almost half-a-second delay between doing an action and having the viewport update. Although this isn't completely dire, it did make things slow to work with.
Diving into my code, I could see it was happening because the system underneath was taking my ProxyMan object and putting a copy of it onto the 'undo' stack. In doing so, each library clip was having to be copied or reopened, so that the object sitting on the undo stack had all its own resources. And because mine was making an entirely new scene each time a library clip was copied, it meant the user had to wait for the whole library to be copied behind the scenes before the viewport would update.
This was quite noticeable with just one clip in the library. Imagine if there were 10. Or more...
I came up with a better solution. Instead of each ProxyMan having it's own library resources, I made a global library structure for the session. This meant that any object using a motion capture file in its clip library, could now load the scene into the global library once and just refer to that version when needed. This meant that all copy-things that went on behind the scenes didn't have to open or copy every library clip over again, they just had to copy the reference to one that now exists in the global session library.
And as an added benefit, if another ProxyMan object in another scene came along and needed the same motion capture file, it searches for an opened version in the global library first, and if one is found, it uses that as its reference instead of loading a new one.
And for the copying to the undo stack part, it means the copies only need to copy the reference, which is very small, instead of having to create their own unique library clip all over again. Much, much faster.
It took my viewport from around 450-500ms to execute, down to 1-2ms. In some instances its so quick, that it doesn't even register a time. This exercise has been a huge time saver. And more importantly, it's made working with the viewport and tool much more speedy for the user, and just more efficient overall.
In addition, I also finished off some older functions I hadn't completed. These were mostly user-helper functions, like keyboard copy-paste routines. Separate to the issue above, I had made placeholder functions early on, but had never completed them. But I found a need for them, because the user would benefit from the new IK engine being able to be copied and used in multiple locations.
For instance, to fix a foot contact with the floor over multiple steps, I could use the same setup across multiple step locations. So, the idea would be to make an animation clip with an IK controller, fix foot step one, then copy the clip and move it along the timeline to fix foot step two. Just means I wasn't having to recreate a new IK chain for every single foot step. I could just borrow one that had already been setup.
I can even copy and paste clips across ProxyMan systems. Though there may not be much use for it, it just means it can help me make different versions of an animation if I need to, before going with the final approved one.
There are still some bits of functionality that don't exist (or work) yet. For instance, "ctrl-z/y" for undo/redo doesn't do anything in my timeline system dialog editor. And I probably need to deploy a few more keyboard shortcuts for it to improve usability.
I'd still like to complete the export to BVH functionality if I can, just to round off that side of it. But for now the tool looks like it can be used for something. And that's the important bit.
With these issues cleaned up, it's now time to try and make a demo edit of a character animation.
And more...
After posting the above, I went on to attempt to edit a motion capture with my new IK engine, only to find what I thought was another bug. I was attempting to use a motion capture clip for the full length of my timeline. When adjusting the length, it wasn't adjusting the internal scene's frame length. So the clip ended up going in a loop for a frame coverage that wasn't the length of the clip's internal scene itself.. I kept wondering why when I expanded the clip's length to fill the timeline, that it was ending up in a loop. Turns out, I was daft. It wasn't a bug. It was me forgetting how I'd made things work!
But... I did find a button was using the wrong icon. So, I did fix that. It all counts. Especially for the user experience. It's probably a job well done if they don't notice things. it also helps that you don't forget how you made it work yourself...!
I did also find a couple of 'working bugs'. These are just bus that just reveal themselves in odd ways. They don't necessarily prevent you from working, they might just be annoying, or means you work around in ways you're not expecting too.