NateS

I know how it is to have computer pains, I've been through a lot. I highly suggest an Imak SmartGlove. I can't use a computer without it. I've been using them for maybe 7 years, they are great. I like the one with the thumb. I also use a Kensington Expert Mouse, which is a trackball that has a scroll ring. Normally you lose the scroll wheel with a trackball, which would be unacceptable, but this one is great. Pinching a mouse is never good, the trackball and especially the glove really helps. Ergonomics are of course important: knees 90 degrees, elbows 90 degrees, no armrests on your chair. One last little 2c, the rowing machine at the gym is the absolute best treatment for back pain from sitting at a computer. It works your rhomboids and is the one exercise that makes the most difference. Best of luck!

Are all properties keyed together?

Ok. I looked at the HTML5 example and this seems like a very limited way of defining curves. Maybe a chart would make it more clear. Here is Softimage: The chart shows all the keys for the whole animation. Pay attention only to the white line. The first red dot is keyframe1, the second red dot is keyframe2. The leftmost black dot is c1x,c1y defined relative to keyframe1, and the rightmost black dot is c2x,c2y defined relative to keyframe2. With these 4 values you can define a complex curve between keyframes, which is extremely useful. The x-axis is time, the y-axis is property value. Some of my questions in my first post still aren't answered. Eg, how do keyframes work? Are all properties keyed together?

I guess I still don't understand how c1 and c2 are used. I have a feeling it doesn't matter, because the best thing to do is support linear with no values or bezier with 4 values: cx1, cy1, cx2, cy2. :) Animation with only linear would be a huge inconvenience.

Hi, I'm Nate, co-author of libgdx. I've been building a skeletal animation framework lately. I'm not building tools to build animations, etc. I am building the framework to load skeletons and skins and run animations. I've built tools so Softimage can be used to design skeletons, skins, and animations. Some day it would be nice to have a loader for the Spriter format, which brings me to this thread. A couple notes on Spriter's file format with general ramblings mixed in... * IMO, skeletal animation should be in from the start. It will affect the file format, how you do animations, etc. * cx1 and cx2 using 0 to 1 is good, but not cy1, cy2. Imagine frame1's value is 0 and frame2's value is 0, but the bezier interpolation is a bell curve. How do you get useful values from this curve? Probably you plan to use the y value on the bezier curve to scale the difference from frame1 to frame2, but in this scenario frame1 and frame2 are the same, so this interpolation doesn't have any affect. It is more powerful to plot cy1 and cy2 in the value space, probably relative to frame1 and frame2's values. Now the bezier curve knows the scale and the numbers are more useful. Otherwise you force animators to use extra keyframes. * Less is more. I would only bother supporting linear and bezier interpolations. Maybe stepped (instant). * It seems all keyframes have all properties? This limits animators, requiring many more keyframes. It makes some animations difficult, as it can be hard to insert a keyframe in the middle of a rotation when fancy interpolation is used. It would be more powerful to animate x, y, scalex, scaley, rotation, etc separately. If this is how it works by omitting properties from keyframes, it would make parsing the format easier to list the properties separately. Eg, {bone:{rot:[{time:123,value:45},{time:456,value:90}}],x:[{time:123,value:10}]}. This is how applications need to load the data to apply animations, so the file format should make it as easy as possible. * Not sure why elements have IDs? The editor shouldn't affect the file format. Ideally the number of references to objects elsewhere in the file is kept to a minimum. * JSON > XML. :) JSON doesn't have unnecessary features, is easier to read, is smaller, is easier to parse, and libraries that parse it are smaller. * Here is how I organize things: I have a "skeleton", which is the bone positions and each bone has any number of "slots". The slots are ordered to define the drawing order. I have a "skin", which is the images and their offset position, scale, rotation for each slot they can go in. I have a "model" (in code only) which has a skeleton and manages state, such as what images are in what slot. Programmers tell the model what slots have what images, and the model draws the images in the right order at the bone locations. I have an "animation", which has keyframes for bones (for each property) and slots (set image, clear image, color). The animation can pose the skeleton of a model. If it helps, my file format looks like this: http://pastebin.com/raw.php?i=bsLbscqf * It seems lots of features are getting packed into the file format (reparent bones, etc). I have a feeling that with so many libs that need to implement running animations built with Spriter, many libs will only have a partial implementation. Eg, my implementation is not based on Spriter, but it is a fully capable 2D skeletal framework. I'm probably not going to add some features Spriter supports, but Spriter could still be useful for building animations for my framework. Maybe Spriter could toggle features based on compatibility with the target library (eg, disallow reparenting).