I found myself in a bit of a pickle recently. I had made an animation showing the proof of concept of the new FK and IK tools, which I rendered and posted about here. Continuing with development, I then added more functionality into the FK solver, which helped to solve another problem.
I also added and updated some of the data associated with the other IK system.
But in making these additional changes, I found myself realising that the animation scene now became out-of-date. That's to say, it won't stand further editing without maintaining a data structure that is now "old". The data structure changed enough that it did this to a previously saved scene:
In light of the above, it had me wondering if I was in need of a solution to this. The easiest solution would just be to animate the character again. Not too difficult. But what happens if I'm in a production and I have to make an update midway through a project. How would this be handled?
There are a few ways to solve such issues like this. Up until now however, I hadn't worried about it, I just considered it part of development. But now that I'm etching closer to more production projects, it has me wondering what I may need to consider in future to prevent saved scenes from becoming obsolete.
My solution, albeit perhaps not the best, but still, was to make a container inspector that could look at, and edit, the data underneath.
New data container inspector
This new dialog tool is a data inspector; it lets the operator look at the data containers sitting underneath an object. And, it lets you manipulate the containers, evening allowing the user to edit, delete and add new data fields. You can inspect the top-level container, or open up pages of containers held within containers.
Being able to read the data structure gives me a few benefits. First, the obvious, it lets me see what a container is housing. If nothing else, to make sure that said data is in fact, in the container.
But the second benefit is what I built it for. And that was to allow for the data container to be edited, and sent back to the object. This means I could inspect the data, and change it as more updated tool versions come forward. It's not a perfect measure, but it's a way to keep a scene relevant over a longer period, as much as is possible.
This kind of tool is not without its risks of course. I will have to be careful how I use it, as technically I could use it to edit a lot of things around the program - things that I probably shouldn't touch. The saying 'with great power comes great responsibility' comes to mind here. I think for my tools this will be fine though. After all, it won't matter if I crash my own stuff. I just don't want to risk things elsewhere in the overall program.
The dialog is actually really powerful, because I can look into just about any object type that stores a container. It might be a scene object (like my ProxyMan tool, or a cube), a tag (a material/texture tag) or something else altogether. If there's a container with data, I can probably look into it. I may not be able to change all data types, but all the usual standard ones, and a couple more, I can..
Here's what the interface looks like:
The image above shows the Container Reader tool with container in the edit area. There are also a number of sub-containers shown as 'pages'. The pagination display is really useful for this. I can go right into deep nested containers to see what's lurking in there. Though I still need to complete the little pagination arrows and page numbering at the bottom.
UPDATE: the pagination numbers and page navigation have now been completed.
I was a bit hesitant to post about this. I really started to question what I was doing here. Having to make a tool like this to fix up old saved data files is a bit of a stretch really. Why not just move on? But, the tool does have a use, and who knows, maybe it'll save me in the future when I need to make an urgent update to a tool, which changes the underlying data containers.
Think I'm getting to the point where I want to start talking about project-based stuff now. The programming and tool development is part of this adventure, but the real stories are yet to come.
On a slightly different note, my new motion capture gear has finally arrived. So I'm now kitted out with camera hardware to make my own motion capture. And of course, the developing tools to turn it into a character animation. I know it's just a matter of time at this point. But that's just it. I'm trying to overcome the "when can I start" thoughts. Some days look dreary.
Maybe the frustration is a good sign though, I don't know. We press on.