Camera path animation

[chrisidefix]

Possibly in relation to #15 it would be a useful addition to have more functionality for automated camera movement. A very first simple addition I already added is auto-rotation (in a 360 degree turn-table fashion) that simply rotates the camera continuously around the current view.

Secondary, certain camera-view position should be able to be bookmarked. In addition a smooth path could then be generated automatically between those view-points. Optionally a more sophisticated camera path-planning tool could also be added to create custom fly-overs (based on spline paths).

[c42f]

Yes, some lightweight camera animation would probably make sense. There is the start of some camera animation machinery in #54 which I have shamefully not got around to merging yet.

If possible I'd like to avoid maintaining a full blown path editor, but a lightweight interface with an editable series of camera keyframes might be doable. We'd need smooth interpolation between them (I guess Hermite interpolation with a simple heuristic for the velocity at key frames might do?) In order to precisely position the camera, we'd need a first person camera mode.

There's also a possibility which involves no keyframe UI at all: Extend the current scripting interfaces by adding -querycamera, to return the current camera position and orientation. Along with a series of -animatecamera commands this would give enough for a scripting interface to query and drive the camera along a path managed entierly in the scripting layer. Clearly going this route would restrict the feature to power users which might be undesirable. OTOH, it might be a nice way to have a usable prototype of some parts without needing to build the UI right away.

[chrisidefix]

Completely agree, it should be lightweight and nothing complicated. Just setting a few keyframes and automatically interpolating between them. I probably missed that pull request as it already contains a rotation feature.

For a simple prototype there is no need for a UI in my opinion. Just a menu-bar section for setting / iterating over viewpoints. I recently captured some videos with displaz, which is why I brought this up. In the process I also noticed the screenshot functionality might be broken - at least we should test it with Qt5.

[c42f]

Cool, I'm always happy when it gets used for things I didn't build it for :-)

The screenshot functionality was always a bit of a hack I'm afraid. I originally tried grabbing the OpenGL framebuffer via QGLWidget::grabFrameBuffer() but I couldn't get it to work nicely (can't remember precisely why now - just another case of OpenGL and Qt4 not quite working together properly - but something to do with switching GL contexts).

Instead I ended up using grabWindow(), but this is far from ideal because it grabs any overlapping decorations like menus etc. With your latest refactoring I think it'd be fairly easy to do it properly by copying the incremental framebuffer into a new framebuffer, and rendering the overlay stuff there rather than rendering it on the backbuffer.

If the scripting interface supported setting the camera position along a spline and taking a screenshot (as separate actions), the process of making a video could be driven frame by frame from a script, and encoded with an external tool (eg mencoder). That would definitely give better results than screen grabbing, which has a tendency to produce tearing, and could be done slower than real time, so we could turn all the settings up (antialiasing, render all the points).

[nigels-com]

Oh, and I was getting worried from my gmail inbox that Chris was talking to himself. Never mind.