From what I can tell (haven't tried it yet) it's a skeletal animation system for bitmaps. You create all your bitmap images in any external editor you want to, it reads them in based on a folder structure. It'll export all the animation data as XML.
The problem with this system is it actually makes animations that look like shit. Seriously how many flash games have you seem made with good animation using the flash armature system. Armature systems are good in conjunction with a frame system, but not really when it is only an armature system. Look at vanilla wares stuff for example.
Yes it can work well for bosses because they tend to not turn.
You can put in feature requests on their forums while it's early. A couple of things I asked for are a graph editor, image atlas packing, and frame-based sequences on the skeletal hierarchy (which is I guess what you're talking about Muzz).
Combined with frame per frame animation to do this type of sprite art. The way I see it you will be able to have a bit more control than just a better skeletal tweening. Such as extra bones you can weight to make subtle breathing animations and whatnot. Could probably do something to rig scrolling through a texture that's a sprite sheet as well.
So in a sense it wouldn't be that hard to accomplish most of this in Blender already, at least in terms of sprite output. It still wouldn't work with vectors, and wouldn't have whatever they explained as a framework for being light on computer resources.
hello everyone. This is Edgar for the Spriter team. Thanks for the interest.
We're completely flooded with emails, etc at the moment, so I may be a little slow to reply, but I'll do my best to get back here and answer any questions. I apologize if this is a little tl;dr, but I'll try to be answering all the questions I saw reading through this thread.
First, about the animation style, it isn't just for tweened animation. In 1.0 you will be able to toggle tweening for any given part (this includes collision boxes, action points, and variables as well). You can currently have any number of parts on each frame(try the beta linked under the video at kickstartspriter.com), and parts don't have to be related to parts in other frames, so complex frame by frame turns can be created by any number of different parts per frame, and if you want to mix the two, you'll be able to tween parts that also swap out to a different image at a certain keyframe.
The XML based format we're using is designed for extremely quick implementation on any platform using the platforms' native sprite or textured polygon drawing techniques. We are working on giving a description of the file format (as it currently exists in the beta), just to prove the concept of quick implementation, and we planning on releasing the filespec before the end of our kickstarter.
As for the future possibilities shown at the end of the video, and at the bottom of the description, which most people (including me) compare to ubiart, like image deformation, and 2d skinning, we will work out the final implementation if we get beyond our funding goal, and after completing 1.0. And we'll be working with developers in the community across all platforms, to ensure that deformation works on as many platforms as possible, most likely providing tradeoff choices in export, where you can choose larger diskspace "baked" deformation, or more compact, but more CPU-intensive realtime deformation, and of course, hardware accelerated compute shader based deformation is also a possibility, if a developer wants to have a go at it.
Finally for the procedural animation, that will probably surprise people with the ease of implementation. Prior to beginning Spriter, I had made a proof on concept that ran on the original Droid from motorola, back when Droids were pretty slow. Please feel free to ask more questions, and direct anything urgent or immediate to lucid@brashmonkey.com. Any tech support on the beta should be directed to Brashmonkey.com/forum. Thanks again!
Replies
Wish inkscape would hurry up with their animation update. :poly117:
I was planning on frankensteining Blender into a tool like this. Hopefully time saved
You can try it out for yourself, both a beta of the new version and the lite old version are available at: http://www.brashmonkey.com/index.htm
Here's some tutorials for the old version:
[ame="http://www.youtube.com/watch?v=Pfhlsfc-EDM"]0_intro.wmv - YouTube[/ame]
[ame="http://www.youtube.com/watch?v=WgDfR2F89uk"]1_interface.wmv - YouTube[/ame]
[ame="http://www.youtube.com/watch?v=DaegDEK30n8"]2_menus.wmv - YouTube[/ame]
[ame="http://www.youtube.com/watch?v=MYPrGjYhH1Q"]3_preferences.wmv - YouTube[/ame]
[ame="http://www.youtube.com/watch?v=1k_yhd7hAig"]4_col_rects_actionpoints_and_variables.wmv - YouTube[/ame]
Yes it can work well for bosses because they tend to not turn.
http://www.albinal.com/wp/2012/02/2d-in-blender-2-6-tutorial-part-2/
Combined with frame per frame animation to do this type of sprite art. The way I see it you will be able to have a bit more control than just a better skeletal tweening. Such as extra bones you can weight to make subtle breathing animations and whatnot. Could probably do something to rig scrolling through a texture that's a sprite sheet as well.
So in a sense it wouldn't be that hard to accomplish most of this in Blender already, at least in terms of sprite output. It still wouldn't work with vectors, and wouldn't have whatever they explained as a framework for being light on computer resources.
We're completely flooded with emails, etc at the moment, so I may be a little slow to reply, but I'll do my best to get back here and answer any questions. I apologize if this is a little tl;dr, but I'll try to be answering all the questions I saw reading through this thread.
First, about the animation style, it isn't just for tweened animation. In 1.0 you will be able to toggle tweening for any given part (this includes collision boxes, action points, and variables as well). You can currently have any number of parts on each frame(try the beta linked under the video at kickstartspriter.com), and parts don't have to be related to parts in other frames, so complex frame by frame turns can be created by any number of different parts per frame, and if you want to mix the two, you'll be able to tween parts that also swap out to a different image at a certain keyframe.
The XML based format we're using is designed for extremely quick implementation on any platform using the platforms' native sprite or textured polygon drawing techniques. We are working on giving a description of the file format (as it currently exists in the beta), just to prove the concept of quick implementation, and we planning on releasing the filespec before the end of our kickstarter.
As for the future possibilities shown at the end of the video, and at the bottom of the description, which most people (including me) compare to ubiart, like image deformation, and 2d skinning, we will work out the final implementation if we get beyond our funding goal, and after completing 1.0. And we'll be working with developers in the community across all platforms, to ensure that deformation works on as many platforms as possible, most likely providing tradeoff choices in export, where you can choose larger diskspace "baked" deformation, or more compact, but more CPU-intensive realtime deformation, and of course, hardware accelerated compute shader based deformation is also a possibility, if a developer wants to have a go at it.
Finally for the procedural animation, that will probably surprise people with the ease of implementation. Prior to beginning Spriter, I had made a proof on concept that ran on the original Droid from motorola, back when Droids were pretty slow. Please feel free to ask more questions, and direct anything urgent or immediate to lucid@brashmonkey.com. Any tech support on the beta should be directed to Brashmonkey.com/forum. Thanks again!