Candidate for final file format (expanded)

lucid · May 13, 2012

download the format description in SCML

(or scroll to the bottom of this post for visual overview)

I'll only document the new additions here that weren't explained/discussed in the previous thread, which also explains the way the description is organized, and the purpose of public review of the final file format candidate.

First I'll list the minor changes, and the things that were added or changed according to yesterdays consensus:

There are two main additions to the format in this description: character maps, and tweening.

Please read these descriptions before commenting, because there are very specific reasons for doing things in the way they're done. Of course if after hearing the reasoning you'd prefer a different approach, I'm all ears. Also feel free to comment on anything that was changed based on yesterday's discussion. Nothing is set in stone. Also, you'll notice a poll there on the Y/Angle issue. I realize it's relatively minor to multiply these values by -1 to adapt it to the other way, but this was split down the middle yesterday, so a poll seems the simplest way to decide.

Character Maps

The concept is simple, but powerful. Each character map is a named set of rules with which to replace images (and in the full format sound effects and subentities). These can be used for alternate clothing on characters, or entirely different versions of characters that share the same animation data.

Each 'character_map' has a name, an id, and any number of 'map' entries.

As of now, the Spriter editor itself will use actual physical folders, but these can represent spritesheets, or even just virtual folder structures implementation side. For those curious, we do plan to add in editor spritesheet support at some point, but I'd prefer we keep that discussion separate. The idea here is that folders provide a simple way of dividing up images(and other files) for use in character maps.

Each 'map' entry can specify either a 'folder', a 'file', or both. 'folder' only will replace all images in that folder, with images of the same name in the 'target_folder'. 'file' only will replace every file in every folder with the filename 'target_file' in the same 'folder'. 'folder' and 'file' will replace one specific 'folder'/'file' with another.

Spriter will allow artists to preview multiple character_maps in the editor, and will apply them in order. In most cases order doesn't matter: Apply 'CowboyHat' character_map, and then 'Reptile_Skin' character_map. Going by the obvious assumptions it wouldn't make a difference what order they're in. Clever animators/developers could create unique combinations however, where the second map applies to the results of the first, so an "armor" character map will add armor to the character, and an "evil" character map will change a character to their evil version. If you apply both, for instance with "armor" going first - the "evil" character map could apply some of it's maps to the folders already used in the "armor" character map, so there could be an evil version of the armor used.

There should probably be a default 'character_map', and a way to specify in that 'character_map' and others whether certain 'file's and 'folder's should be invisible. I didn't specify any method of indicating this in this description, but if anyone wants to weigh in on their ideas for this, feel free to.

Also, important to note here is that Spriter will allow you to name and specify character maps, even if the files and folders don't actually exist. This will allow user modding and DLC. For instance, you could name a character_map "UserShirtMod" and specify that the 'folder' "shirt" should map to the 'target_folder' "MOD_shirt". At game time, the developer would simply replace the string for the folder "MOD_shirt" with a folder or spritesheet the user specifies in the game. Implementations with a high level of abstraction, such as game authoring tools, should support runtime replacement of folder names in character maps.

Tweening/Pivot Points

First you should notice that pivot points for each image are now specified in the 'folder'/'file' entries. These are useless without tweening, and that's why they were left out of the Beta Format export option.

Next, there are now two types of 'sprite' entry in the mainline:

The second type of 'sprite' entry includes a 'timeline' attribute and a 'key' attribute. If you find the 'timeline' attribute is present, you know this refers to a persistent sprite(one that can be tweened) and refers to a 'timeline' for this specific persistent 'sprite'. Before moving on to how the tweened sprites are represented in the file, I want to preface this with an explanation of 'if you need a separate timeline for tweened sprites, why not just use the same for nontweened as well, and just specify no tweening?'.

In other 2D animation packages I've used, there is almost invariably an issue where either:

Let's say an animator wants create a magical tweened sorceress animation, and maybe add some cool looking frame by frame sparks and magic dust starting on frame 20. Should Spriter require them to specify each of these little sparks to be nontweened? Should the file format show each of these 30 sparks that exist only for a single untweened frame or two on it's own timeline?

I went through several iterations of the file format. Over an over there was a problem with each method unless I explicitly separated them in the file format. Tweening, specifically with the flexibility of not requiring tweening for every sprite, and also with the flexibility of not requiring every keyframe to be a tween key for every 'sprite', simply works best if they have their own separate representations in the file format. Any other method either bloats the format to take up much more space, removes flexibility, or requires Spriter to do at least some guessing as to what the animator intended.

Lastly, please don't be concerned if you've never done the interpolation math necessary to translate these speed curves and keyframes into actual positions, angles, etc. It's not difficult, and pseudocode will be provided that performs the math necessary in the final file format description.

That being said, the 'timeline' entry refers to a 'timeline' element, which appears in the file after the 'mainline':

Most of what you see there is exactly the same as the regular entry for sprite in a key. This entire timeline will be dedicated to the 'sprite' entries that refer to it. I'll list and explain the new attributes here, and also for attributes familiar from the normal 'sprite' entry, but which now have additional considerations:

name

x,y,x_scale,y_scale,r,g,b,a,angle

time:

curve_type:

c1 and c2:

folder and file:

pivotx and pivoty:

angle and spin:

mainline_key:

Also, note this is still not the complete file format, not only to avoid being overwhelming and confusing, but also because what is decided here with tweening applies to most of the rest of what's in the file format. The next release will include the entire format, which contains action points, collision boxes, sound effects, variables, and subentities.

Thanks everyone. Here's the visualization of everything listed so far:

Thinksquirrel · May 13, 2012

Thanks for the expanded preview! It definitely helps to see a larger picture.

Regarding the Y axis and clockwise/counterclockwise stuff, I have no preference, as long as the file format uses one standard throughout. Those sorts of things are really easy to fix implementation-side, and they should be consistent with the Spriter application itself.

I'm still not sure if character maps need both folder and file entries. I understand that having a folder replacement pattern can be useful in the editor, but I don't think it needs to be part of the file format. I think it would provide much more clarity to the format to just have replacement paths for the character map - Spriter itself could support replacing whole folders, or matching file patterns when a folder isn't specified, but the SCML would output each file replacement explicitly. As far as mod support, that is very game-specific, but it wouldn't be hard to do the same thing in a game implementation. Another suggestion I'll throw out there would be to have a glob pattern using any number of asterisks (*) for character maps. This would also allow you to support deep folders easily, too.

That said, this is only my opinion, not sure what the consensus is.

As for tweening, are there any plans to support custom animation curves? I know my artist is waiting on this - to support this in the current file format you'd only need to add a curve type "custom", with c1 and c2 representing raw in and out tangent angles. Of course, the Spriter application would need a curve editor for an artist to make use of this in Spriter itself. If you have plans to support custom curves, it would make sense to implement it in SCML first.

Also, do c1 and c2 only have one significant decimal digit?

I also noticed that the mainline_key value is for the Spriter editor only. Will we need to implement that with our export plugins for Spriter to correctly open our files?

I may have missed it earlier, but you mentioned sub-entities. Could you elaborate on what you mean by that and how those would work, from a design perspective?

Sorry for all the questions! Just hoping to keep the discussion going.

Liking what I see more and more; I can see why you want to separate the mainline/timeline for good support both with and without animation curves. You've definitely put a lot of thought into the SCML format, which in my opinion is one of Spriter's greatest strengths.

djkat · May 13, 2012

Ok, looks well thought through as far as it goes but I have some questions:

1. Are sprites all in global space or in a tree structure with inheritance? If they are all using global coordinates instead of local space that means that inverse kinematics and procedural stuff will be impossible no? I think this is a huge deal and would really break the whole file format if it doesn't enable tree structured sprites where child nodes inherit the transforms of parent nodes.

2. Tweening between images not possible except by hand? (it is a very cheap operation to tween two frames in a shader but a lot more expensive on mobile platforms at least to do them by hand (drawing two frames on top and tweening the alpha values between keyframes).

3. No mention of blending modes. We use additive rendering for a effects a lot (such as glow) but I could see usecases for other kinds of blending.

4. Empty / dummy nodes for connecting sprites dynamically to a hand such as a weapon or particle systems possible? Again, unless the system enables sprite hierarchies with inherited transforms this might not even be possible / useful?

djkat · May 13, 2012

Regarding pivot points:

I would like to suggest never using pixels anywhere, it is easy to understand but many developers want to be able to have different resolutions on their images for different platforms (for example 1024x1024 sheets for iPad/PC and 512x512 for iPhone etc.)

Unifying coordinates to an internal coordinate system makes most sense, that way no matter the resolution of an image, the size of a sprite would be the same on the screen.

lucid · May 13, 2012

I'm still not sure if character maps need both folder and file entries. I understand that having a folder replacement pattern can be useful in the editor, but I don't think it needs to be part of the file format. I think it would provide much more clarity to the format to just have replacement paths for the character map - Spriter itself could support replacing whole folders, or matching file patterns when a folder isn't specified, but the SCML would output each file replacement explicitly. As far as mod support, that is very game-specific, but it wouldn't be hard to do the same thing in a game implementation. Another suggestion I'll throw out there would be to have a glob pattern using any number of asterisks (*) for character maps. This would also allow you to support deep folders easily, too.
That said, this is only my opinion, not sure what the consensus is.

so instead of a character map's map entry specifying a single folder attribute, it would specify each file explicitly? other than that I see what you're saying, and am curious what others think as well on that particular

As for tweening, are there any plans to support custom animation curves? I know my artist is waiting on this - to support this in the current file format you'd only need to add a curve type "custom", with c1 and c2 representing raw in and out tangent angles. Of course, the Spriter application would need a curve editor for an artist to make use of this in Spriter itself. If you have plans to support custom curves, it would make sense to implement it in SCML first.

Spriter's going to have a curve editor to customize at least the limited c1,c2 method.

Just to be sure I was clear in how I mean to use those values:

If you wanted a quadratic curve that looked exactly like a linear you would have a value of 0.5 for c1(0.00000 for ease in, 1.00000 to ease out),

If you wanted a cubic curve that looked exactly like a linear, it would be 0.33333 for c1 and 0.66666 for c2(0.00000 for c1 and 1.00000 for c2 to have ease-in/ease-out). higher order curves could just have c3, c4 etc if people want that. You're suggesting tangent angles as an alternative representation? Also, when you say custom animation curves, do you mean something beyond specifying control points similar to this? I don't think it's a good idea to get too complex like being able to specify a curve that moves forward and backward, or beyond the next key, but again, I'm open to input on this front as well

Also, do c1 and c2 only have one significant decimal digit?

just an oversight. same number of significant digits as the other things(5 for now)

I also noticed that the mainline_key value is for the Spriter editor only. Will we need to implement that with our export plugins for Spriter to correctly open our files?

just put in there for completeness sake. It should be totally unnecessary for plugins that display spriter animations. might be useful for people creating scml generation tools

I may have missed it earlier, but you mentioned sub-entities. Could you elaborate on what you mean by that and how those would work, from a design perspective?

this will be more important once bones are in there, and will be fully elaborated on in the next and final expanded review(they are a revision of the 'container' concept in procedural.pdf, which explains them more thoroughly) but basically anywhere you can put a , or anything you can do with , you'll be able to do with an entire (which contains s). Right now the files we've been looking at contain one , but they can be contain more than one. They will be listed in the 'folder'/'file' element structure as well, so referenced entities can be in separate files. Subentities(just entities referenced in an animation) will be listed in the same entry with s to determine their zorder, and their keys will have an attribute and a attribute. These can be used to create hierarchical animations, and also to create complex procedural object relationships. The document above goes into detail about how this can be useful, but as far as implementation side, you'll basically just be doing the same thing you're doing to animate the entire character, but taking into account angle/rotation/etc, to rotate the entire entity as a single object. If you're thinking this through all the way, you might wonder if this means you'll have to skew/distort sprites. In the editor the artist will not see them distorted, and they should not behave this way, until distortion is supported by the editor, where it will be an extra option. Distorting sprites is the last thing on the todo list, and I think it'll be best to wait to even define exactly how that will work in the file format, though I designed what's there so far to definitely have room to add this without having to change anything editor/implementation side, and only add to it instead.

Sorry for all the questions! Just hoping to keep the discussion going.

definitely ask as many as you have. that's what this is for. the more questions/suggestions the better.

Liking what I see more and more; I can see why you want to separate the mainline/timeline for good support both with and without animation curves. You've definitely put a lot of thought into the SCML format, which in my opinion is one of Spriter's greatest strengths.

good, I was a little worried people might see that as redundant. and thanks

1. Are sprites all in global space or in a tree structure with inheritance? If they are all using global coordinates instead of local space that means that inverse kinematics and procedural stuff will be impossible no? I think this is a huge deal and would really break the whole file format if it doesn't enable tree structured sprites where child nodes inherit the transforms of parent nodes.

there will be a tree/bone structure discussed in the next update to this candidate/review thing. Because there's so much to consider, I thought it best to review it in phases like this, but it's definitely going to have a tree structure. As far as whats there for now, until we involve parenting, the idea is that the 0,0 position is your character or effects actual location on screen. So if a "sword" sprite has 100,100 for x and y, and your character is at 80,60, the sword should be drawn at 180,160

2. Tweening between images not possible except by hand? (it is a very cheap operation to tween two frames in a shader but a lot more expensive on mobile platforms at least to do them by hand (drawing two frames on top and tweening the alpha values between keyframes).

I probably wasn't clear in the description, and I'll edit it if anyone else got confused, but for now all I meant is you have one image, and that image remains and rotates/scales/moves according to the key, but at the next key you can swap it out for a completely different image. subentities will let you take hand drawn transition images, and automatically tween them, and in the far future we'll also have shape tweening. I've thought of the crossfading alpha so one image fades out while another appears as well. I was planning to add that option later, but I think it's sort of a niche option that won't be useful in most animation, so I was planning to add it further down the line since there's so much on the table right now, and it's probably low on the animators' priority lists.

3. No mention of blending modes. We use additive rendering for a effects a lot (such as glow) but I could see usecases for other kinds of blending.

yes. this was in the original Spriter as well. To be honest it's an accidental omission. I was going to start out with only additive as an alternative, but I guess now's as good a time as any to see if there is a high demand for any additional modes.

4. Empty / dummy nodes for connecting sprites dynamically to a hand such as a weapon or particle systems possible? Again, unless the system enables sprite hierarchies with inherited transforms this might not even be possible / useful?

Action Points allow you to specify and animate arbitrary points. I was going to have dummy sprites down the line that had width/height/angle in addition to the positions(and variables, but we'll get into that next update) that action points allow, but it makes much more sense to rename action points, and just give them the option to not contain either position/angle/scale data. These will be listed as just another animated object that the programmer/game has access to along with other animation data, and will have the same tweening options.

Also the subentity system will allow you to fully animate a very complex weapon, like the portal gun with it's little robot arms, and blinking lights, or a gatling gun, and choose animations to play, which would obviously be very different for those two guns. What's even cooler about that system is that you could allow for DLC and usergenerated content, without the animator anticipating the additions. as long as they have that "fire" animation, or whatever else you need, the implementation can dutifully do whatever it's supposed to.

Regarding pivot points:
I would like to suggest never using pixels anywhere, it is easy to understand but many developers want to be able to have different resolutions on their images for different platforms (for example 1024x1024 sheets for iPad/PC and 512x512 for iPhone etc.)

Unifying coordinates to an internal coordinate system makes most sense, that way no matter the resolution of an image, the size of a sprite would be the same on the screen.

gotcha, right now the coordinate system is based on pixels, but this can obviously be ignored and viewed as the internal coordinate system. But would you still prefer the the pivot points be specified in a ratio of the image width/height, from 0.00000 to 1.00000. I think it's a good idea in light of what you said anyway. At least in the way I would implement it if I were creating a plugin or API, it would skip one or two math steps to use 0 to 1 ratios

djkat · May 14, 2012

Hi, thanks for your answers, I understand what you are saying, sorry for sending so many questions, I just want to give my feedback on what I believe is important. :)

Regarding pivot points, yes relative values are better I believe but should not be 0-1 since you might probably want to use pivot points outside the image in some cases.

Feature request: User defined tags that can be added for sprites, keys, folders and images, this would enable us to set game specific tags on sprites for example, such as blending modes, adding particle effects etc without having to edit the xml file by hand or having another file accompanying the animation file. It would also enable us to build in our own features before an official feature is added to Spriter. In Spriter it would be "pretty easy" to have a text window where you could add these tags and make sure they are loaded/saved when you modify a file.

Regarding tweening of images, the main use-case I have used/seen this is for effects such as explosions, animated fire, etc. It just looks a lot better with much fewer frames of data if you can tween but it is not a make or break feature at this point. It will be quite easy to add myselfin our engine if you would consider adding user defined tags mentioned above.

Cheers,

Daniel

lucid · May 14, 2012

no problem with lots of questions. it's better because A: It helps me understand developer's needs that fall outside our development experience, and B: I love talking about this stuff anyway

the 0.0 to 1.0 limit was just the same copy paste typo from yesterday. 0 and 1 wouldn't be lower or lower limits limits to the pivot point ratio thing.

as far as the tagging thing: it hasn't been showed yet in the format description, but there will be variables that can be animated (frame by frame or tweened). Strings, ints, or floats will be possible (obviously strings can't be tweened). Also, for numeric variables, max and minimum values can be tweened as well. These can be attached to specific frames, or action points, or collision boxes. Since you stated it'd be useful for sprites, I suppose they should be able to be attached to those and all other entities as well.

Thinksquirrel · May 14, 2012

Just wanted to +1 relative positioning plus a custom tag system here as well. If the programmer on a team needs it, the artist can add a tag + a value to a sprite, and it would show up in the xml alongside the other sprite data. You could even add tags for keyframes, and entities.

As for blend modes: Blend modes in the SCML would really be a suggestion since it's ultimately up to the engine to support what it can - I would recommend...

[*:1q3h7axh] Alpha Blended (the default you have now)
[*:1q3h7axh] Additive
[*:1q3h7axh] Multiply
[*:1q3h7axh] Solid (ignore all alpha values in an image and render a solid texture, don't know just how useful this would be but could be nice to have in the SCML for performance reasons)

Those are the basic ones that should cover most things. More specific cases like vertex-lit blended, premultiplied alpha, etc should be handled in an engine's shader (and could even be suggested with a user tag).

EDIT: Just saw your new post about variables. I suppose a tag would be the same as a string variable. I think it's definitely important to be able to tag most things in the file though as opposed to just sprites.

protheonX · May 14, 2012

Each time I look over the current candidate format structure I think "If I were editing this by hand would I know what it means and can I intuitively add an attribute that isn't present?" If I didn't already know what C1 & C2 were I might be confused. Since they only deal with the curve_type could they be named curve_control_point_1 or curve_c1? The same goes for pivotx and pivoty. If I were just trying to type them into a SCML file I would probably try x_pivot and y_pivot because that is how the scale and z order attributes are named.

I realize these are minor things but everyone has been hitting the big issues of how things work so I thought I would look at usability of the format outside the editor. Oh and I agree relative pivots points and blend modes are good ideas.

timpart · May 14, 2012

Character Maps

I prefer using numbers to specify files / folders

What is the special value to mean not applicable. This would be the default for the attribute. I'd suggest 0, but you might have other ideas, like -1.

download the format description in SCML
Each 'map' entry can specify either a 'folder', a 'file', or both. 'folder' only will replace all images in that folder, with images of the same name in the 'target_folder'. 'file' only will replace every file in every folder with the filename 'target_file' in the same 'folder'. 'folder' and 'file' will replace one specific 'folder'/'file' with another.

I'm not sure I understand your explanation of replacement. I use target to mean something that gets stuff transferred to it and hit / replaced, but you seem to be saying it is`the source of the files.

To make an entire folder vanish you could either have a special attribute, or perhaps set the source folder to null, but specify a destination folder. (I've avoided using the word target here.) Could do the same for a particular file as well perhaps.

Tweening

I appreciate why you want to have two different viewpoints. The first is time based and shows what things are around at each point in time. The other is thing based and shows what happens to that thing at each point in time (and is convenient for tweening).

I am slightly concerned about the names you have come up with though (two sprites and two keys with different attributes) I'll give this more thought.

Apart from showing how the z hint discretely changes over time does the second sprite type actually add anything apart from convenient cross referencing? Presumably by going through the timelines for each tweened object it is possible to reconstruct where its key frames appear in time. (This is another very good reason for specifying time from a start point rather than a series of intervals)

The mathematician in me would be curious to see the tweening formulae in more detail. From the looks of it it is possible to do


                   Velocity        Acceleration     Change in Acceleration
1 (linear)         Constant              0                    0
2 (quadratic)      Varying           Constant                 0
3 (cubic)          Varying           Varying               Constant

So these would cover a variety of physically realistic situations.

Regards,

Tim

lucid · May 14, 2012

[*:f45c434e] Alpha Blended (the default you have now)
[*:f45c434e] Additive
[*:f45c434e] Multiply
[*:f45c434e] Solid (ignore all alpha values in an image and render a solid texture, don't know just how useful this would be but could be nice to have in the SCML for performance reasons)

Ok, I'll put as many of those as I can in editor, and for anything else, a 'custom...' option to write in your own. I think it'd be better to have the blending mode(even when custom) separate from the the variable system

Each time I look over the current candidate format structure I think "If I were editing this by hand would I know what it means and can I intuitively add an attribute that isn't present?" If I didn't already know what C1 & C2 were I might be confused. Since they only deal with the curve_type could they be named curve_control_point_1 or curve_c1? The same goes for pivotx and pivoty. If I were just trying to type them into a SCML file I would probably try x_pivot and y_pivot because that is how the scale and z order attributes are named.

I realize these are minor things but everyone has been hitting the big issues of how things work so I thought I would look at usability of the format outside the editor. Oh and I agree relative pivots points and blend modes are good ideas.

agreed, next iteration I'll make sure the position of the x_, etc in those compound names is consistent

Character Maps
I prefer using numbers to specify files / folders

What is the special value to mean not applicable. This would be the default for the attribute. I'd suggest 0, but you might have other ideas, like -1.

I like -1, personally, I prefer 0 indexing whenever possible, as most languages use 0 indexing for arrays. This is for making the target folder n/a for invisibility I'm guessing you mean

I'm not sure I understand your explanation of replacement. I use target to mean something that gets stuff transferred to it and hit / replaced, but you seem to be saying it is`the source of the files.

To make an entire folder vanish you could either have a special attribute, or perhaps set the source folder to null, but specify a destination folder. (I've avoided using the word target here.) Could do the same for a particular file as well perhaps.

what I mean is, source and destination. You have a file called "arm" in the "normal" folder. The target folder is "zombified", so if the charmaps had "normal" as the (source)"folder", instead of displaying '/normal/arm.png' when that character map is applied, it would display '/zombified/arm.png'

Tweening

I am slightly concerned about the names you have come up with though (two sprites and two keys with different attributes) I'll give this more thought.

Apart from showing how the z hint discretely changes over time does the second sprite type actually add anything apart from convenient cross referencing? Presumably by going through the timelines for each tweened object it is possible to reconstruct where its key frames appear in time. (This is another very good reason for specifying time from a start point rather than a series of intervals)

Though we now have the 'z_index' as part of the 'sprite' entries, many developers(myself included) will be ignoring that value, and just drawing each item as it appears in the list.

pretend the two types of sprite entry are called 'sprite' and 'refsprite'(for the new one that references the separate timeline)

you would have a simple list like this

and that key within would have a complete list of every that should appear at any given time. It's of course possible to just go through and read all the zindex values, and go through a separate pass and render and order everything, but I do think it's much simpler to have them all in the same list this way, even if it's redundant to the devs who'll use z_index value. It's the best of both worlds without much extra filesize. Something I hadn't considered originally was SAX parsers, which a few devs expressed their concerns about through email. Different set of requirements, but I think having redundant ways to determine things like z_index, or the way the "refsprite"s list the key, even though you can step through each time in the 'timeline' and determine your current key anyway. Anything to ease implementation is worth it as long as it's not bloating things significantly. Also, if anyone's thinks we should have a separate name aside from to refer to this second that only has the timeline/key references, that's fine as well.

The mathematician in me would be curious to see the tweening formulae in more detail. From the looks of it it is possible to do
                   Velocity        Acceleration     Change in Acceleration
1 (linear)         Constant              0                    0
2 (quadratic)      Varying           Constant                 0
3 (cubic)          Varying           Varying               Constant
So these would cover a variety of physically realistic situations.

This was going to be my recommended method of handling tweened values. Any mathematical or hardware accelerated equivalent is of course fine, and if anyone has a more efficient, or more readable suggestion, I'd of course like to hear it. I'll just use C++ here instead of pseudocode. Also, there are obvious ways this can be reduced and made more efficient, since there are so many 0's and 1's involved, but this is the most clear way to present the logic/math behind it:


//t is a time value between 0 and 1 

float linear(float a, float b, float t)
{
     return ((b-a)*t)+a;
}

float quadratic(float a, float b, float c, float t)
{
     return linear(linear(a,b,t),linear(b,c,t),t);
}

float cubic(float a, float b, float c, float d, float t)
{
     return linear(quadratic(a,b,c,t),quadratic(b,c,d,t),t);
}

now assuming t=(currenttime-keytime)/(nextkeytime-keytime)

start and end could refer to x values, y values, r,g,b)

anything except angles, which require the extra consideration for crossing the 0/360 border)

so for linear curves:

linear(start, end, t);

for quadratic

linear(start, end, quadratic(0.0,c1,1.0,t));

and cubic

linear(start, end, cubic(0.0,c1,c2,1.0,t));

In the actual editor, I think there should be an actual visual graph version of the curve, but here's a simple HTML5 demonstration of the different speed curve types. A and B are drag droppable. Click the curve type, and drag the sliders to adjust c1 and c2:

html5 speed curves

timpart · May 14, 2012

OK here's my attempt to understand the tweening things as an entity relationship diagram. Arrow at end of line indicates a many relationship. The names in the boxes are my own inventions in some cases. Underneath the bottom row of boxes I've put the tag names used in SCML, one row for the untweened ones, another for the tweened ones. Looking at where the two tags named key have ended up I think it explains my confusion in thinking they were both the same thing.

charlieman · May 15, 2012

About the folder/file structure and swapping, what if instead you kept it as the simple list of images, and added "name" and "set" attributes? Several images could share a name but be from different sets, so there are some "head" images where one belongs to the "normal" set, another one to "armored", "evil", etc.

It's basically moving the functionality from the parent element to an attribute in the image.

Would this work with what you have in mind?

lucid · May 15, 2012

@charlieman, that should work just as well.

@timpart I'm not sure if this will answer your question or not, but here's the way I visualize it:

mainline contains a list of every sprite that should appear in that key, untweened sprites contain all of their x,y,etc data right there in mainline key, while the tweened sprites contain references to their x,y,etc data in a separate timeline

the boxes containing other boxes aren't meant to represent element containing relationships. This is merely to illustrate that both keys are there to display certain data. Its mostly the same data for both tweened and untweened. The difference is that untweened sprites have the data locally, and tweened sprites get the data from a separate timeline.

timpart · May 15, 2012

Thanks for the reply lucid, I think we are talking about the same thing. Where my diagram has an arrow the object at the end of the arrow appears within the object at the other end in the XML, and nested within the other object in your latest diagram.

My box labelled Key Image (perhaps that would better be named keyed image) represents the postioning etc of an image at a key point in time, and how to tween it (or not) to the next point in time. The snag in representing it in XML terms is that it would end up within two different things which is impossible. However in memory it is perfectly feasible to include in two different lists and for it to have pointers to each of its two parents.

I would suggest to you that your (first) sprite tag and your key tag within timeline both represent the same concept.

You have added the (ref) sprite tag and the mainline_key attribute of (timeline) key to get around the problem that an object can't be inside two things at once. You happen to have divided the occurances into two places depending on whether they are untweenable or mostly tweenable for convenience, but I think they are the same thing and could be given the same tag name. (would still need the ref sprite and the other attribute to overcome the difficulty of things being within two things at once)

Have I managed to explain a bit more clearly what I mean? I'm not suggesting that things are forced into non tweened viewpoint or tweened viewpoint, but rather both simultaneously,

lucid · May 15, 2012

@timpart,

I actually misread it a few times before I understood what you meant. It's important the file format be as clear as possible, so we want to make sure to get this right. The reason I named it 'key' was because it was a choice between semi inaccurately naming it 'key', and missing the 'sprite' aspect, or naming it 'sprite', and missing the 'key' aspect. The sprite doesn't have time values, but the key does. More importantly, in the mainline, keys are the things that are arranged in an order that represents time, in the mainline key if there are several 'sprite's in a row, they are all to be displayed at the same time and their order is determining their draw order. So I actually do see it from your perspective as well now, but I think it's important we take both problems into account for the final naming.

Also, I should have included it in this release, but I was trying to expose only tweening related things to keep things simple. In that second type of 'key' that is more like a 'sprite', there is a 'type' attribute, that will have a string value like: sprite, collision box, bone, etc.

Any ideas on a name for it, or do you think it should just be called 'sprite',regardless of the time aspect.. Or do you think it's fine with the 'type' attribute?

Also, is the concept confusing or difficult to understand aside from the potential for better naming, and does it sound workable? Is it something you could easily implement, or at least as easy as you'd expect a tweening animation system to be? If so, I'll post another expansion, while we continue to think of a better name. I said I'd release everything else next, but let's just make sure bones are easy to understand as well, before we throw in everything else.

lucid · May 15, 2012

This is how bones will work:

basically it lists the bones in an order where the full tree can be read in one pass. if anyone prefers it, we can actually have the bones have their children as child elements, so people keeping the XML DOMs as their only data can already have them in an actual data tree, if they prefer to work that way.

the implementation should store each bone's position/angle/scaling/etc data for each 'id', and any subsequent bone that contains that id for the 'parent' attribute should rotate around, be scaled by, and positioned according to the angle/scale/position of the 'parent'. those new positions/angles,dimensions should be used by any other bones that have it for a 'parent' as opposed to the values stored in the file.

you'll also notice that it contains an alternative reference version as well, just like the sprite object.

This is worthy of note because the usual way bones are used, they are permanent, at least for the course of the animation. this would be the reference version. Bones have the same options to bring a referenced or unreferenced bone in and out of existence on any keyframe. making characters like this, that pull random objects out, where you don't necessarily want to have this as part of the skeleton at all times, but might still benefit from skeletal animation:

the same goes for characters that change shape and limb configuration frequently or even occasionally:

also you'll notice because parenting is specified per mainline key, bones and other objects can be re-parented at any keyframe. So objects can be removed from holsters, or characters like robots or Ms. Fortune from skullgirls(the cat girl in the screenshot above, can remove her head and hold it) can remove their limbs, and the animator doesn't have to do anything except reparent the object at that keyframe.

for bones that are not in the persistent referenced timeline, Spriter will eventually let you choose to remove nontweened bone information as an export option. if the animator is just using bones to help them animate frame by frame. the game would be wasting processing power by calculating bone information

also, notice that sprites contain the 'parent' attribute as well

timpart · May 16, 2012

Some thoughts on the parents of bones (and sprites)

I'm a bit concerned that there seems to me to be a combining of two concepts.

The underlying bones and their rigging

The bone at a particular moment in time in a key frame

So when a parent attribute refers to an ID that ID is of what exactly? ID of a bone within that key frame (which only exists for that key frame) Presmably that has to be resolved to the underlying bone for use in future frames. Or is it the ID of the bone itself? How to sprites handle this when they can be contained within bones or groups? Need to have one series of IDs not a series per type in this case.

If a parent is specified in a bone / sprite inside a key frame does that indicate a change of parent? So if you don't specify that attribute the parent is unchanged? You have specified a default of none, but that isn't the same thing. Possibly need two values, one for unchanged, the other to mean set to none.

I don't see how the alternative of specifying parents all the time would work, as as soon as you had gone through a reassign parent animation and returned to a normal animation the parentage would be put back again.

So assuming you aren't doing that , how do you set up the default rigging in the first place?

I'm also a bit surprised that you are having bone, sprite specified within (mainline) key. These are all specifying how something is changed at that moment in time. Can't you have a single object supertype instead? (Or I'd call it keyed object as it is only the object at that time)

Dr9 · May 16, 2012

Great work so far. It's awesome to see how much momentum and interest this project is gathering.

Question and a comment.

If a sprite part is supposed to dissappear mid animation (or appear for only part of it - to put it another way) should this be accomplished with the alpha channel flipping 0%->100% mid animation? The only other way I could see this is Z-order but you can't take for granted that whatever is rendering won't have tearing or a slowdown in painting that would show what's underneath.

Regarding the file format and directory. I think the lack of support for packed spritesheets is problematic for some devices. Specifically the xbox360 - but every system benefits from lowering the file IO and having one large sheet to pick sprites from. I wrote a winforms application to extract the files and regenerate a spritesheet along with the mappings. I'd rather see support for the x/y within the format, at least as optional fields. I can see how the proposed format could be coherced into that using the other XY (size) values and the same image file. On that note, I don't see any attributes specified as optional unless I'm not reading this correctly.

timpart · May 16, 2012

I was wondering how to make something vanish as well. Perhaps set x-scale and y-scale to 0 so it is zero size?

If objects on screen can receive mouse clicks, then something of zero size wouldn't but a totally transparent object might.

Also since the format only gives moments in time, duration of something is implied by the next key frame encountered. For things like sparks from an enchantress's wand, does the mainline animation define their duration, regardless of how many tweened animations are happening in parallel? If nothing special is happening in the mainline, but a tweened thing reaches a key frame, does the mainline need a key frame at that point as well (one that would be the same as the previous one presumably)?

Thinksquirrel · May 16, 2012

In the previous format, vanishing would happen by a sprite being listed in one keyframe and not the next. That won't work for tweening though, so I'd like to know how that is handled with a tweened sprite. I'd preferably like to have a toggle for a sprite being visible or not, that way you can still instantly turn off a sprite, yet still tween its position and other parameters up until that point. Overall sprite visibility should definitely be a separate attribute from scale/opacity though, for performance reasons mainly.

A good way to handle this would be:

A "hidden" attribute - if a sprite isn't listed, it's implied that it is hidden. If a sprite is listed, but has a hidden attribute = true, it is hidden at the time specified in the keyframe, but every attribute is still tweened right up until that point. If a sprite is listed, and doesn't have a hidden attribute, or the hidden attribute is set to the default (false), it is just a normal, visible sprite. That way, you still get the benefit of not having a bunch of extra sprites in the SCML file, but it imports the important information needed for tweening.

Another thing mentioned above - I think you should rename tweened sprites and keys - having the same names are honestly confusing, and I think it would be much better to have something like "refsprite" "tweenkey", etc (those example names are horrible, but I'm sure someone else can think of something better). That way when reading the SCML file, the parser will know from the get-go what type of sprite to expect before it reads further into the file.

lucid · May 16, 2012

hi everyone. Had to reinstall windows due to a failing hard drive. I'll be back with responses to these things. I definitely agree on the rename, but I'll explain ideas behind bone parentage/untweened duration/zorder/etc when all this updating is over - Either later tonight or tomorrow morning

thanks for all the input

charlieman · May 17, 2012

I was wondering how to make something vanish as well. Perhaps set x-scale and y-scale to 0 so it is zero size?
If objects on screen can receive mouse clicks, then something of zero size wouldn't but a totally transparent object might.

Will spriter manage mouse events? I guess it would make sense for touch screen devices...

Maybe we can get ideas from CSS, it has a pointer-events property. I think from there I can see 3 possible values that could work with spriter:

none: The element is never the target of mouse events; however, mouse events may target its descendant elements if those descendants have pointer-events set to some other value.
visible:The element can be the target of a mouse event when the visibility property is set to visible and the mouse cursor is over the element.
all: The element can only be the target of a mouse event when the pointer is over the element. The value of the visibility property do not effect event processing.

This visibility would be the hidden attribute Thinksquirrel proposed.

On the other hand, this could be simply set in the custom properties for the sprite some people where proposing and manage it entirely on the game engine.

lucid · May 17, 2012

Some thoughts on the parents of bones (and sprites)
I'm a bit concerned that there seems to me to be a combining of two concepts.

The underlying bones and their rigging

The bone at a particular moment in time in a key frame

I'll explain the idea in a little more detail. The same way Sprite can exist on a per keyframe basis or on it's own permanent tweenable timeline, the bones can as well. Each timeline key(not mainline) has an equivalent mainline key. So each mainline key specifies the current Zorder, and the current bone parentage. This means at any keyframe a bone can be reparented, or the skeleton can be reconfigured to have more or less bones. On the surface it might seem this is flexibility for the sake of flexibility with no real useful purpose. I believe however that lacking the ability to reconfigure bones in any arbitrary way at any time is part of the reason every time you see something animated by bones you think "oh look, it's bone animation", without having to know what program they used to make it. Keep in mind, it's not like the artist has to manually set up the parentage each frame, it will carry over from the previous frame. They will just have the freedom to do so if they wish.

So when a parent attribute refers to an ID that ID is of what exactly? ID of a bone within that key frame (which only exists for that key frame) Presmably that has to be resolved to the underlying bone for use in future frames. Or is it the ID of the bone itself? How to sprites handle this when they can be contained within bones or groups? Need to have one series of IDs not a series per type in this case.

If a parent is specified in a bone / sprite inside a key frame does that indicate a change of parent? So if you don't specify that attribute the parent is unchanged? You have specified a default of none, but that isn't the same thing. Possibly need two values, one for unchanged, the other to mean set to none.

There's an example of how id's a parent's are used. The parent element/child element structure reflects the hierarchy of the bones, which is mirrored by the 'parent' elements.

Also I agree there should be a way to specify unchanged, to avoid waste, especially in cases whether the bones don't change at all. It should just be one value perhaps for the entire skeleton (on that keyframe) that contains the 'key's 'id' for the last change. This way, if there is a change on key 2, but not on keys 3 - 10, on frame 11, you don't have to manually iterate through each key to find the last changed configuration.

I don't see how the alternative of specifying parents all the time would work, as as soon as you had gone through a reassign parent animation and returned to a normal animation the parentage would be put back again.

So assuming you aren't doing that , how do you set up the default rigging in the first place?

I'm also a bit surprised that you are having bone, sprite specified within (mainline) key. These are all specifying how something is changed at that moment in time. Can't you have a single object supertype instead? (Or I'd call it keyed object as it is only the object at that time)

See above. Personally, even from my limited hobbyist animation experience, the lack of freedom with bones and parentage (particularly adding and deleting bones) is to be expected, but in those cases where you do want to make a shape changing character, or weapons that change hands, all of the sudden you're doing some time consuming workaround, that would have taken a moment or two if you could just change the parentage at any moment.

Great work so far. It's awesome to see how much momentum and interest this project is gathering.
Question and a comment.

If a sprite part is supposed to dissappear mid animation (or appear for only part of it - to put it another way) should this be accomplished with the alpha channel flipping 0%->100% mid animation? The only other way I could see this is Z-order but you can't take for granted that whatever is rendering won't have tearing or a slowdown in painting that would show what's underneath.

Regarding the file format and directory. I think the lack of support for packed spritesheets is problematic for some devices. Specifically the xbox360 - but every system benefits from lowering the file IO and having one large sheet to pick sprites from. I wrote a winforms application to extract the files and regenerate a spritesheet along with the mappings. I'd rather see support for the x/y within the format, at least as optional fields. I can see how the proposed format could be coherced into that using the other XY (size) values and the same image file. On that note, I don't see any attributes specified as optional unless I'm not reading this correctly.

Spritesheets will be supported for now, think of folder/file, as spritesheet file/image. I haven't put it in this file format yet, but there will be a flag at the beginning that specifies spritesheets or subfolders. As far as in editor creation of spritesheets, that may be added at some point, but in the meantime I will add support to export to and import from and existing spritesheet creation program. Even without that support however, it should be simple for the developer to interpret folders/files, as spritesheetfile/image entry, and then combine the individual images into spritesheets after they're done in spriter.

I was wondering how to make something vanish as well. Perhaps set x-scale and y-scale to 0 so it is zero size?
If objects on screen can receive mouse clicks, then something of zero size wouldn't but a totally transparent object might.

Also since the format only gives moments in time, duration of something is implied by the next key frame encountered. For things like sparks from an enchantress's wand, does the mainline animation define their duration, regardless of how many tweened animations are happening in parallel? If nothing special is happening in the mainline, but a tweened thing reaches a key frame, does the mainline need a key frame at that point as well (one that would be the same as the previous one presumably)?

In the response above I mentioned that for every timeline key there is one mainline key (more than one timeline key can share the same mainline key). You get the drawing order from the mainline key. If the object is not present in the mainline key, it is simply not drawn. There won't be an extra value to check for invisibility, it just won't be there.

Another thing mentioned above - I think you should rename tweened sprites and keys - having the same names are honestly confusing, and I think it would be much better to have something like "refsprite" "tweenkey", etc (those example names are horrible, but I'm sure someone else can think of something better). That way when reading the SCML file, the parser will know from the get-go what type of sprite to expect before it reads further into the file.

I agree. I think sprite_ref, or sprite_timeline are fine, and then do we keep the names of the and 'key'?

I think anything specific to certain games (what if it's a ps3 game?) should be avoided, but in the next version of the file format I post, I've added optional to everything, and to all animateable objects

. So you could add any number of tags to something like or or anything else that will be useful to have in the file, and included with your animation data

timpart · May 18, 2012

Parent ID

I think I didn't make my question about what does the parent ID contain clear enough. I am perfectly happy with the idea of having parents and swapping them around as needed.

From you previous comments you intend having groups as well as bones. They're two different types I think as bones act a bit differently to groups, though groups might be a super type of bones.

Suppose a sprite has a parent. You want to put its ID into an attribute. Bones have IDs, groups will have IDs too. If bones and groups have separate ID sequences then when a sprite refers to a parent ID , that is ambiguous as we don't know if a bone or a group is intended.

I would suggest that the way round this is to make bones and groups have a common ID sequence.

Supertype

As I mentioned before I would go further than just a common sequence. Create a super type "object" that has sub types of sprite, bone, group, collision box etc etc. Then rather than specifying different tags for sprite, bone, group, collsion box within mainline key with virtually identical attributes, just have an "object" tag which refers to the actual thing it is. That makes the format more flexible for adding things in the future. (A few sub types like axis aligned collision boxes can't be rotated, and action points have no change if rotated since they are points.)

All objects would have a common ID sequentce, and the parent of an object would be another object.

You have partly gone down this route already by making both ref bone and ref sprite point to a timeline. So timeline is what happens to an object over time. Instead you could have had a sprite-timeline and a bone-timeline. (I'm not suggesting that you do.)

Sprite vs Timeline Key

I suggested that these two are the same concept. You pointed out that you have put a time on Timeline Key but not Sprite.

As a counter argument I would suggest that the time attribute is something redundant (but very useful) that you have put on the Timeline Key. If you were to get rid of it (I'm not suggesting you do) you could still find out what time the key happened, by following the link to the mainline key, in the same way that a sprite knows what time it happened by looking at the mainline key it is contained in. Equally you could put an unneeded attribute of time onto the sprite.

Tim

Sign In

Candidate for final file format (expanded)

Y direction and Angle Direction 24 members have voted

1. Y direction and Angle Direction

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members

Y direction and Angle Direction
24 members have voted