Monday, May 30, 2011

Keyframes & skins

Now that school is (finally) out for summer, I can turn at least some of my attention to my pet project. The past few days I implemented one feature from the todo list that was mentioned in my previous post. I created an Keyframe Animation node, which can hold animation data (position, scale, rotation) for 3d models, cameras, lights and so on. The graphic user interface has a very basic editor for it, as shown in the top left corner of the screenshot below:



Even though you can import Lightwave/3dsMax scenes and animations in the tool, I wanted to have a basic keyframe animation editor so that you can directly edit camera paths to be used in scenes that are not imported but constructed using the tool (e.g. containing completely code-driven effects, with generated 3d objects). There are still some minor issues to iron out though: I want to be able to connect a keyframe animation to multiple 3d objects, which is trivial to implement. However a slightly bigger issue is that if you reuse the keyframe animation in multiple 3d objects, each object will share the same position, orientation and/or scale. To mediate this, a 'time delay' node is needed, which does nothing else than ... manipulate the time (e.g. make it go twice as fast, twice as slow, or reverse). Although this should not be that much work it is an example of how this project is kind of a 'pandora's box': every time I implement one bit of functionality, I discover that other features are desirable to be able to make the best possible use of the original bit of functionality. There still is a ton of work to do before this tool is really functionally complete and stable enough to be used in a demo production. Fortunately, I still like to work on it :-)

Another feature that was implemented, more or less by accident, is 'skinning' of the graphic user interface. By loading a 'cascading style sheet', which basically is a text file that specifies things like background colors, button images and so on, you can drastically change the appearance of the graphic user interface. Just compare the screenshot above with the screenshot from the previous post- this difference is accomplished by loading a text file. Since I really dislike the Windoze look&feel, I think this is kinda neat :-)

For the record, here is a more or less prioritized and updated todo list:

  • Change ColorCurveEditor: currently animating a color sequence requires animating the r, g, b curves separately. I don't remeber why I implemented it that way (probably because it was a quick fix at a time when I was still learning Qt programming), but this is not very useful. I want to change this so you can specify keyframes as colorvalues associated with time points. I may even ditch the curve display completely, and go for a table-based approach like the Keyframe Animation editor (Keep It Simple, Stupid :-D).
  • Scene import: I am leaning towards deciding on using LightWave as a preferred modeling package. Not that I know how to model though- I think that in the past modeling software was too complicated for my taste- I just want a modeler and thats it. What I do like about LightWave is that the modeler and layouter (scene animation/renderer) are separate programs. I am leaning towards extending a LightWave export plugin to maintain tight control over it's functionality. This should provide me with a 'basic but acceptable' model/scene/animation/material exporter rather quickly, which I can improve extend over time. If I've learned one thing from many years of using open-source software, it is that 'if you want something done, you have to do it yourself'.
  • Postprocessing node: A node that allows you to apply postprocessing effects (blur, bloom etc) to a rendertarget, while controlling and/or animating the effect parameters. Currently, postprocessing is supported but the graphic user interface does not allow animation of the parameters (meaning, you have to hardcode it).
  • Animated mesh node: for loading and controlling a mesh with skeletal animation. See previous post for more details. This is more or less low priority, since the only need for it that I can think of at the moment is for making 'evolved virtual creatures' (which in turn would also require a neural controller node... there is Pandora's box again ;-)

... to be continued ...