Animation Workshop

Here we will explore the possibility of displaying some animated dinos on this wiki.

Section 1: Simple Test of Animations in Wiki Pages

Testing if small animations can be displayed easily on Wiki Pages. 

You know where this project is going!

Test 1. Simple in-line display. Does it work? 

Test 2. Inside Tables: Now let's test if the trees still sparkle inside a wiki table. 

Test of Animation inside Tables

Test 3: Well that image is a little big for my taste. Since we can't use th px modifier without destroying the Animation let 's try another approach. Next we simply uploaded the Cristmas Tree to www.GifMagic.com and used their FREE service to decrease the size to 150x150. The modified animation was downloaded in seconds to my computer and then uploaded here. Let's see how it looks. Not bad! 

This great service at  can also help crop, filter, enlarge, rotate and even flip our animations. 

You can add a beveled box around your animation as shown here. 

Meet Professor OneStone's dogged assistant, Snappy, the prehistoric snapping turtle. Here he is holding a few of the professor's celebrated writings on DinoFusion, and in his left hand, the latest tomb entitled "Unified Theory of Dinofusion", a treatise which purports that all the historical epoques of DinoFusion can be explained by a single underlying mechanism.

Section 2: Sprite Sheets

Animations consist of a series of frames or cells which are displayed, much like an old-fashioned flip book, in a sequence to create the illusion of motion. Nowadays, these individual frames are all packed into a single graphic image so that the server only has to send out a single file, resulting in greater efficiency. This larger graphic file, containing all the individual frames is called a sprite sheet. Here is a sample sprite sheet for a baby White Sabretooth Tiger. 

You can see there are a total of 15 small frames. These frames must literally be cut out of the sprite sheet one at a time using the information provided in an accompanying plist file, and then displayed in order to create the animation. The abbreviation plist is short for "property list". Each plist file must identify the sprite sheet or Texture File with a line similar to: 

<key>realTextureFileName</key>     <string>dino-sabertoothwhite-s1.png</string>

It must also identify the size, which is often limited to powers-of-two for optimization reasons. 

<key>size</key> <string>{256,512}</string>

Notice the width is 256 = 2^8 while the height is 512 = 2^9, both powers of two. Finally, the plist must provide instructions on how to cut out each individual image from the sprite sheet. This involves giving coordinates for the bounding rectangle for each frame and any additional instruction such as whether the frame has been rotated. 

Animation Workaround

Now wiki pages are not designed to take as input a srite sheet and its associated plist file and display the animation. So our next project is to find a workaround suitable for use in a wiki page. 

Any ideas out there? Please help!

Let's Try The Opposite

Since we have not solved that problem yet, let's circle the wagons and slowly close in on the problem. It turns out of course to be quite easy to extract the frames from an Animated gif. So let's see how to do this related task to build our confidence. We will do this for the animated Christmas tree shown above.

First download Adobe Air and the free Showbox utility.

We used the Animation to Sheet feature with the icon  by dragging our Xmas Tree animated gif file onto the icon.

With a few clicks we can assemble our own Sprite Sheet for the above Christmas Tree. There are options for either 1D or 2D arrangements under the Settings button. 

1D Sprite Sheet for Xmas Tree: Game Engine Single Row Option

2D Sprite Sheet for Xmas Tree: Game Engine Multi Rows Option

If you look carefully from frame to frame, you will see the lights flicker on in the sequence red, green, blue and yellow. We conclude, it is easy to go from an Animated Gifto a Sprite Sheet. 

All Engines Full Reverse!

But our problem is the reverse. We have plenty of in-game Sprite sheets, and want to create the animation - without the game engine of course. So let's start with the above 2D Sprite sheet for the Xmas Tree and see if we can recreate the original animated GIF.

We need to extract the individual frames, all 15 of them from the Sprite Sheet. This can be done simply by dragging the 1D sprite onto the "Extract Sprites" icon in Shoebox. In this case we readily received all 15 frames as separate PNG files. Not the disassembly here was unusually easy because all teh frames have have teh same rectangular size. This will not be the case with our dino animations because the dinos are walking, jumping and playing various tricks - and in general changing size! That will present quite the challenge that may have to be handled on a frame by frame basis to prevent the animations from showing disturbing jumps and jitters. 

Next we will test if we can assemble the 15 individual frames back into an animated GIF - using only free software. I used GraphicConverter, but tehre are rfeally many many free options to choose from. I have all 15 frames that have been cut out of the 1D sprite sheet in a single folder. To assemble them back into an animated GIF using GraphicsConveter, just use the detailed instructions here . On my Mac, the Animated Gif option was under the Window menu item instead of the Picture menu choice. Now you can see I was not quite successful!

It looks like the frames are out of order. It also is not in an endless loop, so the animation just dies out shortly.

For now, we will leave this posted so you can have a nice laugh at my first attempt!

But undeterred, I shall try again tomorrow. 

I have also tried to use Graphic Converter to scale the tree. Does it still work? Yikes!! What happened!!

I also tried to reassemble the slices using the free online service GICKR at http://www.gickr.com,  but that only allows ten frames (we need 15) and has modified the picture noticably as well as putting an annoying stamp in the lower right corner! 

Experiment: Can we add dinos to existing animations? 

This was just a quick rough test of adding a little Raptor to a thunderstorm animation.  Used the Detail Window in GraphicConverter to help align the eye of the raptor in all 6 frames. He is fairly well aligned now, and was finally able to adjust the loop flag in Graphic Converter. Just reopened the GIF and noticed the loop flag which I had definitely checked while editing individual frames - - - was mysteriously unckecked. Simply checked it, saved and voila!

Whew! One more hurtle overcome. Technically, the little white pixels around the raptor should be corrected, but I rather fancy these sparkles are a severe case of Saint Elmo's Fire. 

Dino in a Desert Thunderstorm

Was also able to rescale the Thunderstorm using GifMagic, but failed at adjusting the loop control there. 

Experiment: Can we animate baby dinos? 

The above animation was just about the simplest possible, because the dino is fixed in one spot. This fixed reference point is a great simplification and substantially reduces the work required. Let's now tackle the next hardest type of animation, and that will be animating a baby dino. If you look carefully, although the baby dinos certainly jump about, the nest in which they are living never moves. This will serve as a fixed reference point and greatly simplify the task of alligning the individual frames. 

Step 1: Extract the frames from the baby dino sprite sheet using Shoebox. It could  also be done by hand using a marquee or clipping tool in any graphics package. 

Update: Shoebox easily extracted all 15 slices of the Baby White Sabretooth Tiger sprite sheet and stored them as 15 separate gifs. Next each image was opened in Graphis Convreter, zoomed to double magnification and most but not all of the images needed to be rotated 90° to the left (counterclockwise) so the head was pointed up. 

Scrambled Eggs: Yikes!

So now all 15 sprites are ready to go - but there is yet another problem. Not really sure of the order, and because the plist info was not used at all by Shoebox, it is quite possible the individual animation frames are all scrambled up. Taking a break now. Going to feed my dinos and watch my baby tiger triplets. Maybe if I stare hard enough, the order of the cells will become clear. There are only 15 after all. I would hate to have to use figure out the plist info, as that is still all Greek to me. 

Inspecting the Property List File 

Update: Still not certain about the order of the animation frames. Will now attempt to figure this out using the property list file. Seems there is no choice. It appears this does use Apple's Texture Packer software. We shall also look at Zwoptex in the near future. The sprite sheet file with all 15 frames for the baby white tigers has dimensions 256 X 512. Can we find this in the propertty list file? That may help figure out these files. The file opens beautifully in BBEdit, nicely formatted and clear to read. Aha! Under the key metadata, we see the size key which agrees with the known dimensions of the sprite sheet. 

 <key>size</key>   <string>{256,512}</string>

We also see:

<key>format</key> <integer>2</integer>

I believe this means the file is using the power-of-2 convention, which is common in games to minimize the size of the files. There is also a key identifying the software TexturePacker by name, which is a clue that ultimately, we should work more carefully with that software. That will have to wait for a bit. Let's tackle the easier problems first. 

Here is a small portion of the key info for the first frame of our animation. Maybe this will help us find the actual first frame by inspection of the sprite sheet. 

                <key>frame</key>   <string>{{2,248},{56,74}}</string>

                <key>offset</key>

                <string>{-1,-73}</string>

                <key>rotated</key>

                <true/>

                <key>sourceColorRect</key>

                <string>{{96,161},{56,74}}</string>

                <key>sourceSize</key>

                <string>{250,250}</string>

What in the world does all this mean? Hmmmm, ... OK, we can see 13 of the 15 frames have been rotated. That's the meaning behind:  <key>rotated</key> <true/> Indeed, inspection of the plist file shows 13 trues and only two frames 11 and 12 are not rotated. Those are the two in the third column facing up. Not sure which is which just yet.  Let's see next if we can figure out which of the two is frame 11 and which is 12. That may help us figure out the coordinates used.

The property list file is basically a smart file with two components. First there is a dictionary of all the frames, and then there is a metadata section. Technically the frames section can be viewed as an array of dictionaries with a key for each file name and additional keys for the relative coordinates of that image withing the sprite sheet, which can also be called a texture atlas. 

Coordinate Systems for Sprite Sheets

There is more than once coordinate system used in gaming to identify the individual frames in a sprite sheet. 

We'll need to figure out which one is in use. 

Both the Zwoptex plist and cocos2d plist format conventions assume the origin is at at the top-left, while the openGL coordinate system assumes origin is at the center of screen. Thus, a dead giveaway the openGL coordinate system is being used will be negative coordinates in three of the four quadrants of your sprite.  

Alright, as soon as the coorinate system is figured out, you can pretty much identity each frame in the animation using the coordinaets provided in the smart file, that is the plist. 

For the Baby White Sabretooth Tiger this gives the ordering of the frames as follows.  The floating palette labelled C for center gives the frame numbers down the center of the sprite sheet. You can see the individual cells are truly scrambled! Each of the small squares is 64 X 64 pixels. The top left corner of the sheet has coordinates (0,0) while the botton right corner is (256, 512). In the smart file or plist, the coordinates for each cell are given by the (x,y) value for the top left corner, plus the width and height of the little cell. Using only this info, it is easy to identify each frame in order. Our next project will be reassemble these individual cells into a baby dino animation!

Here are the individual frames for the animation organized into a grid. The frames start with frame #1 in the upper left, and continue just as you would read a Western newspaper, left to right and top to bottom. 

Animated GIF Loop Control

You can see, I am a complete Newbie at animation, and have had a lot of problems getting some of the animations to loop continuously. I have used both GraphicConverter 8.5.3 and Apple's Preview to make small edits or even just to duplicate a working animated gif. And then the damn thing stops looping, as with the little raptor hunkering down in the above thunderstorm. Let's focus next on this vexing problem. 

After a little internet research, it turns out that each animated GIF has two settings in its header that control the looping. First there is a boolean "loop flag" which can be either 0 or 1, and only the 1 means the GIF should be looped. There is also an integer valued "iteration setting" which controls how many times the GIF should be looped. Rather oddly, if loop=1 and iteration=0, the GIF will loop endlessly. And in most software (but not all)  if loop=0, the convention is to loop as many times as specified in the iteration setting. It sounds like some of my loop flags ae changing to zero. Now we need a way to fix this. 

First Attempt: Tried to use the online GifMagic to adjust the loop control, but the file just "dries up" each time I try to adjust that setting there. Status: Failed. 

Second Attempt: OK, I am now usually getting the Loop control to work using the same Graphics Converter software mentioned above. Not exactly sure what I was doing  wrong before. If it does not loop, I just reopen the GIF animation, and double check that loop is checked. Seems to work more than half the time. More later, when I can figure out how it was going wrong.

Alpha Channel Compositing

You may have noticed a big delay here. That was because like many newbies to the Graphic Arts, I was completely clueless about how to work with the alpha channel. As I added the frames for the baby white tigers, their alpha channels  - shown to the right - were colliding and wiping out portions of each next frame. The area around each of these stencil shapes is transparent - and is therefore not drawn. The baby tigers in my first attempt were literally disintegrating.  It also turns out that the Mac clipboard does not always copy the alpha channel of a graphic - and this blocked most of my first attempts to figure out how things work. This problem completed destroyed my first Baby White Tiger animation. Here's the alpha channel for the baby white tigers.  My strategy right now is very simple - I have downloaded and am reading the manual for my graphics program - gasp! There is a whole section on the use of the alpha channel! Maybe the answer lies there. This is harder than I thought!

Alpha Channels

Bird in Flight

Here is an example borrowed from a friendly website, featuring my Totem Animal, the Robin in flight. 

You can see the sprite sheet has been assembled from 22 individual frames. The image dimensions of 782 × 1024  are in this case 1014 = 2^10  (a power of 2) but 782 is not a power of 2. 

Section 3: Animation Tools

Next let's look at TexturePacker which can be downloaded here . There are free  versions for Mac, Windows and Ubuntu.