...but it's right we need an option for disable those animations for lower systems
whoa! you're getting ahead of yourself here!!
Ok, first off, I took Idanwin's suggestion as meaning a be_built animation sequence that plays and repeats, like walking or something. I failed to acknowledge that however and tacked on my additional idea, which was to allow more than one "model" or "animation sequence" (one for partially done, etc.). Now here's what I'm thinking is possible
- A single be_built animation that loops or forward/backward loop (as proposed for 0.3 animations)
- One or more static or animated sequences, and once progress reaches a certain point, the next sequence is displayed (like frame work, framework with some stuff, and mostly finished)
- An animation that's played one time over the entire period of the build, so it slowly morphs from it's start to it's finish.
- Lastly, a hybrid combination of both 1 and 3 -- this one is 2x the CPU intensity and involves tri-polar (instead of bi-polar) interpolation
Also, remember that the 0.3.x animation specification allows for multiple simultaneous animations (models) to be played on top of each other.
Now to explain item 4 better, I'll use an example, taking simultaneous playback in mind. However, this is very pie-in-the-sky, so don't take #4 very seriously yet. Let's say that you have a be_built animation where you have miniature angle-like beings flitting about creating said structure. So animation #1 is the angles that has some 15-ish frames where these creatures flap their wings, do some assembly and then move to another location and do some more and this loops every 10 seconds or so. Then animation #2 is the actual structure as it's being built, it doesn't loop, rather it plays out slowly over the build period -- it starts with a foundation and then a frame stretches up, followed by the gradual building of walls. So animation #2 is pretty straight-forward and since we're playing it slowly and interpolating between frames, we can probably get away with 5 to 8 frames and have it look pretty descent.
But I don't want the angles building in the same place all of the time. Thus, I will actually create 4 sets of these 15-frame animations. It will play animation 1a up until 25% completion is reached, then 1b until 50%, etc, but it will actually morph between the frames of 1a and 1b until it reaches 25%, then it begins morphing between 1b and 1c. So in this example, the angles will be building around the areas that animation #2 is stretching into, giving it a more realistic look, while minimizing the actual number of frames needed. Animation sequence 1a will be the angles flitting about near the ground and 1b will be them flitting about at the top of the structure (so it looks like they are building the frame), then 1c will bring them back down to the ground and 1d will take them back up to the roof again (just as an example).
The only thing I can think of to make this #4 idea any better is just bone-weighted skeletal animation, but we don't have that feature in yet (I really want to see it though). With skeletal animations, there is a drastic reduction in memory used and animation file sizes, because we only need to store the models once, and then the skeletal movements are actually very small amounts of data.
