Thinksquirrel

2D Toolkit support sounds great :D I'm currently at Unite - Once I get back, I'm interested in implementing support for Unity's new native 2D system in 4.3. Spriter looks like such a good fit for that system, and the other 2D system developers will be working with it as well.

@CptDefault: Just wanted to say, awesome job for continuing this! I've been pretty busy and hadn't been able to get back into Spriter...glad to see someone be able to take the project and run with it. I've updated the links on the main page to your fork for now - I'll take a look and update the main repository as well. Glad to see the main library cleaned up a bit also. I'm thinking we could reach out to some developers that may be interested in getting Spriter to work with their tools. 2D Toolkit comes to mind - they have a robust editor API that can be taken advantage of.

Hey Elliot, I would check out the dev branch on the main repo. What has been done I've finished the methods that parse SCML into an object hierarchy (it follows the format specification you linked). So no direct file reading is needed at the moment. That said, it's been a while since I've been able to look at the code (been very busy with work here), so I may have missed a few things. What needs to be done [*:3onb01zt]Updating the modules. Each module takes the general object hierarchy and actually implements it as sprites and animation data. More specifically: [*:3onb01zt]Updating the NGUI and ex2D modules [*:3onb01zt]Creation of a tk2D module [*:3onb01zt]The creation of SCML write methods (this is lower on the priority list, it allows for SCML export of a Unity hierarchy)

Hey guys, Progress has been pretty slow. Two other projects that I've been working on have held me up a lot longer than I anticipated. I'll finally be wrapping one of those up within the next two weeks or so, though. From the road map, I've actually finished reading SCML files in their entirety, including a4 features + things that haven't been added to Spriter yet (check the development branch on GitHub), but haven't been able to get to the actual modules yet. I should be able to finally start work on this in the coming weeks, and get the default module out there (skinned meshes + a texture atlas). Remember, I am accepting pull requests on this - if someone wants to tackle updating the NGUI and ex2D modules earlier, for example, that would be very much appreciated.

Nice. Is there any way this could work with the SuperPNG plugin rather than Photoshop's native PNG save feature? Not sure how scripting in Photoshop interacts with plugins. Here's some more info about SuperPNG: http://www.fnordware.com/superpng/

Hey guys, No example project just yet. The main API for reading SCML into generic objects is done (including bones), but none of the implementations. I'm currently working on shipping an update to a different product of mine - after this I should have some time to get back to Spriter work.

Texture swaps are best handled through character maps, which basically allow remapping of one image (can be atlased or not) to another. Creating character maps would be done on the Spriter side (once it's available), and I have plans to support them with the default Unity implementation.

I'm currently working on an importer for Unity that uses C# and the XmlDocument API. You can check it out on github: https://github.com/Thinksquirrel-Softwa ... dapi-unity - development branch Only real requirements for the importer itself are just mscorlib, a Vector2 data type (this one uses Unity's Vector2), and System.Xml.dll.

Hey Nekete, The current version actually exports to native Unity animations already - I will be making a default module for the new version that doesn't require any plugins and makes an animated skinned mesh, though. These will also use native Unity animations.

Check out the Cocos2d-x plugin here: viewtopic.php?f=3&t=870

Hey guys, Work has finally cooled down somewhat so I finally have some time for this. Here's the current roadmap: Initial work [*:32bi4ykf] Create a set of base classes and different I/O modules - similar to the current setup, but simplify methods to make more "sense" [*:32bi4ykf] Shared SCML read/write - getting this to work correctly is the #1 priority Modules - this work can be done concurrently by multiple parties. We want to focus on modules which have already been created (with the exception of the default) [*:32bi4ykf] Default I/O module - creates a hierarchy, atlas, and a skinned mesh. [*:32bi4ykf] Wizard/GUI [*:32bi4ykf] Progress bars, visual indicators [*:32bi4ykf] NGUI module update [*:32bi4ykf] Wizard/GUI [*:32bi4ykf] Progress bars, visual indicators [*:32bi4ykf] ex2D module update [*:32bi4ykf] Wizard/GUI [*:32bi4ykf] Progress bars, visual indicators [*:32bi4ykf] 2D Toolkit module [*:32bi4ykf] Wizard/GUI [*:32bi4ykf] Progress bars, visual indicators [*:32bi4ykf] Other modules Since I can't currently devote as much time as I would like towards this project, I will be looking for contributors/maintainers for the various modules once the core system has been rewritten. If interested, please check out the associated GitHub issue here. Feel free to ask any questions or offer suggestions as well.

The API itself is actually only input/output and doesn't have many features on its own. It's meant to be used in tandem with other Unity plugins, for the most part. I'm working on the rewrite for the new SCML version as I get the time - I can look into importing from Spriter into Smooth Moves.

Hey Fabian, I've had this on hold for now until I get a chance to work on supporting the new Spriter file format - I haven't been able to test out the ex2D implementation too much as of yet. Feel free to open up a more detailed issue on GitHub though, and I can check it out. There's also a known bug that seems to affect rotations for either the first or last frame (causing jitters in loops sometimes). Not sure if it affects the ex2D version, but in the NGUI version I've had to do some manual tweaking after import.

Nice! Would love to see a demo =) I've been holding off on this for a bit until the new file format is finalized, since it will require some restructuring. Once it is, I'd like to get it working with even more 2D systems.

I usually think of 0 degrees as oriented to the original image. So if the arrow is pointing right in the image, 0 degrees will be pointing right, if it is pointing up, 0 degrees will have it pointing up. Eager to see the final file format - I have a few more comments but I want to hold off on them until everything is seen in its entirety. Note: The following only applies if say, a developer has mod support for their game, and uses a modified version of the SCML specification, and would like to publish that modified specification to their community. If they are using the default SCML specification, they could just direct users to the official SCML spec and won't need to worry about any licensing issues. I'm pretty sure this is the route most developers would take. Also a disclaimer, I am not an attorney so I may be incorrect about some of this, and it obviously depends on the licenses in question. About SCML licensing - I'm not exactly sure which license will fit you best. You may want to look into a documentation license. Also, keep in mind you may want to make sure the license you choose is compatible with both commercial licenses, and strict copyleft licenses so that it can be integrated in both fully open source documentation, and commercially licensed documentation. Your ideal license has restrictions on its distribution - it doesn't allow anyone to sell an SCML spec. That makes it incompatible with strict copyleft. Thus, anyone with open-source documentation may run into issues. They will likely need to have the documentation of their SCML specification separate from the rest of their documentation, and may run into other problems. On the commercial side, they would need to take extra care to not include the specification within their software itself. For example, if someone includes the documentation of the SCML format (the version specific for their game) within their manual under "Modding ", and package it and sell it with their game, that is technically a license violation. If you want to restrict the sale of the specification, you need to make it clear that you want to restrict the sale of the specification (and derivatives) under the purposes of being a specification, and not packaged with a product - something fairly hard to do. I think that in this case, having a tool like Spriter and a central body already in control over the main SCML format will already help stop fragmentation. It will also keep other parties from trying to monetize the SCML file spec itself - they could try, but would be very unlikely to succeed with a free version of the specification available from you guys.

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.

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.

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.

I think for the most part things look good. Sorry for the wall of text, but I have a few concerns. 1: I agree with the above comments with regard to the folder structure. I'm not sure why folders would need to be important for the data format. The folders themselves don't seem to provide any information at all, other than that they are folders and what their name is - something which is very easy to figure out from a path string. It seems to add more unnecessary complexity compared to just specifying file paths with the standard separator "/". The keyframes could just reference a file ID. An example as to why this isn't the best idea: Let's say I have a script that I run on my SCML files as part of my import process into my engine. This script changes goes to all of the files, places them in a path Art/_____.png , without any folder structure intact. It then changes the references in the SCML. Say this import process is because my engine doesn't support any subfolders for art assets, and art has to be in a specific folder. If you introduce folders now instead of just paths, this import process just isn't easily done. The underlying engine needs to either conform to the SCML standard for no important reason, or the SCML needs to have a fairly significant rewrite on import to fix broken folder references. If there are just references to file paths, it's quite trivial to just change those as part of an import process. 2: I understand that tweening isn't supported fully in this format, but there is still the issue of enabling and disabling an sprite: If you have a moving sprite in one keyframe, and then not in the next keyframe (implying that it has been disabled), there is no way to tween the position from one frame to the next, and it will stop moving between the two frames. This causes a jitter effect, which is very noticeable if the spacing between keyframes is large. To solve this, each sprite in a keyframe should have an enabled/disabled toggle. That way, that sprite can still have position information to tween for the next frame, but can be disabled once it reaches that position. It wouldn't be required that every frame has every sprite; sprites that don't change from a disabled state would still not be present. For a real-world example: I have an in-development linear tweening mode in this demo using Unity - the issue can be seen here in the walking animation if you slow down the time. http://dl.dropbox.com/u/33426743/Sprite ... Unity.html The candidate format still doesn't solve this issue. Everything else seems set to support tweening (happy to see z-index got in there as well). Overall, good stuff! The format seems pretty extensible (for example, keys could a to go along with the sprites).

I've just released this. See the new thread here: viewtopic.php?f=3&t=534&p=1219

Spriter Data API Overview The Spriter Data API is an object model in C# that follows the SCML (Spriter Character Markup Language) specification. It abstracts reading from an SCML file, allowing developers to easily integrate Spriter into their own applications. This version of the API is written for the Unity game engine (http://unity3d.com). The plugin passes all of Timpart's Spriter Test Suite version 0.2. Demo NGUI/Spriter Demo This demo shows the "Monster" example, with varying pivot points between animations and bone animation used. Downloads Spriter Data API NGUI Implementation for the API - NGUI required (the free/evaluation version also works great) Download both of the above repositories and place them into the Assets folder in your Unity project. NGUI Free vs NGUI Full To use the full version of NGUI, open "Spriter-NGUI\Editor\SpriterDataNGUI" and comment out line 34. Make it look like the following: //To use the full version of NGUI, comment out the following line. //#define NGUI_FREE Usage Make sure the Spriter project you're importing is inside the Assets folder. Whilst there's nothing stopping you selecting another directory it's likely to break the plugin. Unity should now have a "Spriter" menu option, to the left of "Window" and "Help". In here you will find "[NGUI]Create New Character". This will create the character using Unity's legacy animation system. From here there is no reliance on any of the scripts in this project beyond the colour helper. Future Goals Automating the import process when the .scml file is updated. Extending the project to work with 2DToolkit and/or ex2D. Adding a (non-recommended) mode of operation with no toolkits Known Issues Sprites are sometimes a few pixels off from where they should be. I'm investigating this but haven't found the cause. Opening the example scene might cause sprites to flicker when they change. Re-importing solves this. Half the commit messages were written with "R3" compatibility. I meant "B3". Whoops. SCML Version Current SCML Version: Beta file format Acknowledgments Special thanks to: [*:9nw3g1x7]Michael Lyashenko of Tasharen Entertainment for help with scripting support for NGUI [*:9nw3g1x7]The ex2D devs for guidance in the atlas creation process. [*:9nw3g1x7]Mike and Edgar of BrashMonkey for support, as well as making both Spriter and the SCML format. [*:9nw3g1x7]CptDefault for doing a lot of work to update the API for compatibility with the latest Spriter version. License The Spriter Data API is licensed under the MIT License.

Hey guys, I've created a C# Import/Export API for Spriter in the Unity engine. This abstracts all of the SCML data into objects, and provides methods for importing/exporting Spriter data into other systems. A developer using the API would not need to worry about parsing SCML files at all. It currently uses a few Unity data structures (such as a Rect and Vector3s), but these are fairly standard and can easily be implemented for other environments, such as XNA. For the first API implementation, I've created import functionality for NGUI, and am working on implementations for other popular 2D packages. All of the sprites are automatically added to an atlas (trimmed to fit), padding is applied to trimmed space, and a character object is automatically created with all animations. One-button import: The final character is only 1 draw call, depth sorted, and can even be combined with an existing atlas. Animation data is converted into Unity's native animation format; of course, this can be changed depending on the importer implementation. Here's a Web Player example scene. There are a few animation tweaks and artifacts that still need to be taken care of: Web Player Demo Let me know what you guys think!