The problem is that we're used to seeing smooth animations now, and pixel animations are never as smooth as skeletal.
I guess being able to precisely control the speed of limb movement and switch it up with mad hella styled-out special maneuvres gives hand-drawn animation the edge.
Sorry to reask this question, as I do recall it being discussed before, but how can I create a webm clip? I'd be taking a video from Fraps and converting it, I suppose through VirtualDub with a webm extension of some sort?
Oh you reminded me
Added mouse following support to my desktop capture program :)
im making a clock in lisp.
This is really a discussion fit for both this subforum, but also the mapping section, as I'm sure you'd hear a mouth full from them on that subject.
My point is though, you can't compare scene-graph work to BSP or similar systems in terms of efficiency, because scene-graph rendering is a runtime process of rendering and culling, whereas compiled geometric approaches give you a world rendering set and other model subsets of what to render without having the computer figure that out outside of camera positions and visibility sectors. They do two different things in two widely different approaches.
Was trying to decode iTunes WiFi sync packets so I could make a Winamp plugin.
Fucking Apple enables SSL encryption after 18 packets :(
It's not something that I've done, but it's something I'd like to do at one point in life.
Well then let me get to the point.
No, it would be worse.
Ignoring BSP for a moment, I listed two other (very dynamic) schemes that can be constructed at runtime and modified whenever you need to. Octrees you should be familiar with. If you're not, I'm not going to explain them to you, they're common and simple enough that you should have no trouble at all finding information about them. Bounding volume hierarchies are a structure where items are grouped into bounding volumes (usually bounding-boxes or spheres, although any other shape will work just fine) in such a way that pairs (or three, four, etc.) of nearby objects are children of a node whose bounding geometry encompasses both, in a tree like structure with one root node which encompasses the entire scene. It makes no assumptions about scene structure (unlike even octrees, which requires you to choose some maximum dimensions for your root node) and can be built entirely at runtime using simple online construction techniques. Nodes can be inserted or removed whenever you want in O(log n) time. It works great for collision detection (including frustum culling, which is effectively a collision detection problem) and can be used to accelerate occlusion queries.
Now, getting back to BSP. BSP is a very broad term. It applies to any structure which recursively partitions space using hyperplanes (or spheres). Its use in the Id Tech and Source engines is only one of many possible applications, and you absolutely should not write it off as a "compile-time" structure.
I started out as a mapper, and I am well aware of the frustration you can encounter working with a tools that were written for an era when computers had only a small fraction of the power they have today. The choice to offload work to the level designers and map compiler was an excellent design decision at the time, but the constraints that were imposed are not an intrinsic quality of BSP trees.
When you show me any form of BSP structure that can do what scene-graphs are currently doing and on the scale they're doing it, then I'll be impressed.
A k-D tree is a form of BSP tree.
A quad- or oct-tree is a form of BSP tree.
You can have a BSP tree using spheres instead of planes, where the volume inside is one child, while the volume outside is another. This is called a vantage-point tree, or VP-tree, and it has qualities that make it useful for finding nearest-neighbors when only a distance metric is available (think spell-check).
It's a very diverse structure, with many variants, and it's used a whole hell of a lot of places where you probably wouldn't think to look.
If you have a 'scene-graph based' renderer that scales well, it's probably also employing one of these other structures in addition to the basic scene graph.
One of the problems I have with a lot of skeletal animations I see is that they can seem very jerky, because the slope (derivative) of the velocity of their bones isn't 0 when they start and stop. Using something like smoothstep instead of regular interpolation can help, although even then humans can still notice when the second derivative doesn't go to 0 at the start and end.
Another issue is that for many objects (especially ones that are alive), the movement of one part of the object can affect other parts, whereas most skeletal animation systems treats them independently.