Misj'

I don't know if this has been reported in the past, but here are some stray observations about combining texturepacker and spriter (Win8.1, Spriter R5): images that are in the 'root folder' of your spritemap cannot be swapped. Right-clicking an image to replace a selected image in the project does not do anything. Right-clicking and holding the selected image itself doesn't either. image that are in a 'folder' in your spritemap do work. pivot points given to images in the spritemap (at least those in a folder) aren't stable. I set 38 files in 8 folders (in a single spritemap) and when I finished I found that most/all had reverted back to 0,0. Upon saving-and-loading the project file I noticed the same. when double-clicking a folder in my spritemap I get the pivot-point popup. While setting the pivot-point for an entire folder would could be useful, this does a. not have an effect on child images (so I can't set the pivot for all images in a folder), and b. does not match the normal behavior of folders. Adding sprites to my spritemap (in texturepacker) did not affect my test-animation; so repacking a spritemap (and adding sprites later on in a project) should not cause any problem based on my quick and dirty test. EDIT: I also noticed that sometimes the image disappears when I try to swap it (with another instance in the spritemap). It happened several times, but I couldn't reproduce the steps causing it. Sometimes it returns when I move back and forth to a keyframe...sometimes it doesn't. Sometimes when playing the animation in a loop for several times it suddenly puts the images of the last frame on all frames. The data itself is not corrupted since when I save, close the app, and open it again it shows the correct images in the correct folders Whenever I open up a project in spriter that has a (texturepacker) .json file in it, I get repeating errors alerting me that 'there is no disk in the drive. Please insert a disk into drive ...' (in my case drive S, K, I, and G), and I have to press cancel for about 10 times for each drive-letter (so 40 times before the project loads).

As some of you know, I'm not a fan of image deformation in animation; because too often you get what I call: rubber-band animation (not always though, and when used sparingly it is a really powerful tool). And that is also one of the reasons why I haven't played around with it over the last several versions (I looked at it shortly when it was first implemented, but that's about it). However, based on bwwd's posts I decided to look whether this experimental feature was as problematic on my system as it is on his. So here are my experiences: 1. when I add an object as a skin to the project, and immediately delete it, then it will move to the (0,0) position of my project and be stuck there. I can't move it anywhere else...but I can still rotate the object. Doing so will, however, crash Spriter. 2. when I add an object as a skin and double-click it to go into skinning mode; do nothing, and then delete it, then it will be gone from my canvas...but still be in my z-index pane. 3. adding a segment will also create a name element in the z-index pane. This might be intentional, but it just seems weird to me. 4. when optimizing my control-point positions my image sometimes disappeared from the canvas. So while image deformation has to me personally a VERY low priority, I understand and agree with some of the frustrations bwwd is venting. The problem isn't the feature in itself, or even its rudimentary user interface...but the fact that after less than an hour I said to myself: I can't set up a sample project to even test this feature and give feedback. And if I were bwwd, and would consider this an essential feature for my approach to animation, this would be reason enough to move away from Spriter; which would be a shame. Just my thoughts... edit: I also get the same crashes when using bwwd's project file and first select the upper part of the character head (whead.png) and then the jaw (wjaw.png) with the head still selected.

Some things I noticed with texture-packer integration (Windows 8.1) 1. I did a quick (and dirty) test with a character build solely out of packed textures and hit Save As Resized Project (And Images). The ideal result would be that each of the textures would be extracted from the original pack, resized individually and then repacked (if texture packer is installed) or stored as individual images (if texture packer is not installed). As it stands, however, the packed images are simply ignored and are not saved together with the resized project in the new folder...thus making the resize option useless for projects using texture packed files. 2. When you want to pack the textures form Spriter and have Texture Packer installed but the path not added to %PATH%, Spriter asks for the folder containing the Texture Packer executable. The dialog that pops up, however, is a 'save'-dialog, and as a consequence when you select the executable it asks if you want to overwrite it. There is no problem selecting the file, and everything will work...but it's a bit confusing (and scary). 3. Double-clicking a packed sprite shows the 'set pivot' dialog, but the preview is not showing the sprite itself. When you are inside the .json file and double-click the folder-up icon (..) the same 'set pivot' dialog pops up (presumably for the .json file). That's all the time I currently have to test things...

It's really a question of workflow...I prefer to plan out my animations beforehand (outside of Spriter). And as a result - in general - all my body-parts are known and of the correct size and orientation. For me the current default way is much more convenient, because I have a lot more times when I want to add an object to a single frame (or all/some frames beyond the current key) than to all frames. Changing this default behavior would negatively impact my workflow (almost to the point of Spriter being unusable for me), and I would strongly advice against changing it. That being said, I think the paste-to-all-keys might be important enough not to be 'hidden' in the pull-down menu (or even as a very small icon in the edit toolbar). Furthermore, I also agree that there should be a clearly visible option to add (or remove) a body-part to all key frames or all key frames beyond the current mouse position.

Cheers. The reason I probably never noticed is, because I tend to store images (that I want to stretch or squash) at a zero degree angle; so x- and y-stretches distort the image as expected. But if 90 degrees is best practice, what's the advantage over 0 degrees?

small (kinda stupid) question related to the use of skins...or more importantly, the orientation of the sprites. I was wondering, in your animation-pack as well as the getting started guide you rotate the images 90 degrees. It was once indicated that this had to do with Spriter's scaling function (though I don't know whether this still applies; actually, most of my sprites are not in a perpendicular position and I've never encountered any problems with the scaling). Up until now, this had little to no impact on the workflow. However, since with skins you can only add additional horizontal sections, the orientation of sprite becomes much more relevant to those people who want to use that feature, since it determines how the mesh can be shaped. So my question is: is it still best-practice to rotate sprites 90 degrees prior to use (and why)?

Of course because those maps are computer generated :D. No one has time to make normal maps by hand. This is what I find the most interesting of spritelamp...it would allow me to easily create artistic normal maps. If those are done right, all my reservations go away (although artistically I prefer ambient lights with highlights and minor shadows over dark due to the absense of light...but that should be achievable with the right shaders and ambient lights) For a.: It is quite easy if you think in 3D (because every common lighting model works with 3 dimensions, it does not matter how many dimensions (2 or 3) your rendering engine is using). Give your nose and your face different z values and the rest will be done by the illumination model in your engine.But would that work when dynamically reordering parts? - Would that require dynamic z-values, or could we use the z-order to correct this?On that note...would the light be applied on each part separately or on a pre-constructed character. Yes, I know this doesn't matter from an artistic point of view, but it does matter...

I do like the idea behind spritelamp, I think it's closer to the artist's workflow. It is just too early for me to be confident... When it works I'll be all for it, as I see some nice possibilities. I'm just not sure yet.

While I see the potential of dynamic lighting through normal maps, I am not yet convinced. I tried to like it for 2D art, but it does feel a bit computer generated (not just the examples shown here)...and that is just not a look I'm very fond of. I know this can be solved spending more time on the normal maps, and some different lighting algorithms. But I just wanted to raise my concerns. I also have to say that for my particular art-style, I think 'simple' rim lighting would suffice. When you look at this image (I'm linking to a copy on the internet and hope Double Fine won't mind) you see the results of hand-drawn rim lighting that is subsequently added to the character based on the location and colour of the lights. I also think this would be a bit easier to calculate on mobile devices than full normal mapping. I'm not saying rim lighting is the way to go, and that normal maps are a waste of time. It was just something I wanted to bring into the mix. I do wonder how best implement normal maps with modular animation. Simple use-case: I have a nose on my face. The nose is a separate object (for whichever reason). How would I ensure that a. the heights of the nose and the face match up, and b. how would I make modules cast shadows upon other modules (nose on face)? - Otherwise the perceived depth might break the illusion. just some thoughts...

Hi, I've tested it both with some of my own files as well as with tombmonkey's Mantis-girl and Plant-girl (to make sure it wasn't something in my workflow that caused it). I've re-downloaded his project-files to make sure everything was exactly as it originally was, and have only loaded in the projects (from a freshly started Spriter); the only action I did in spriter was setting the onion-skinning distance (to make sure that it would contain a couple of frames). Below I've added the timeline from the Mantis-girl 'stand' animation, and indicated the length of my onion-skinning distance (i've copied the red line and brightened it a bit to make it a little clearer). The decrease in performance is across the board as far as I can tell; although it is of course more obvious when more frames are drawn and when these frames are more complex. I've emailed you two short avi-movies to show the difference in performance on my system.

I haven't had much time to play with version B5.9999991 (using a project from B5 that uses not new features), but two things I noticed with the onion-skinning: a) the overall performance of onion-skinning is much slower than in B5. In B5 when moving from one key to the next (using the '2'-key) the onion-skins (encompassing 3-4 keys) are drawn almost instantly (there's a small flicker). In B5.999991 they are slowly building up. Sometimes moving to the next of previous frame (using '1' or '2') is a bit unresponsive/lagging response while the onion-skins are build up; b) with the onion-skinning on, when I select an element, or rotate and element, or move an element, the onion-skinning often disappears. If it does stay visible, it disappears when I either click the canvas or press ctrl-Z to undo.

The four things that I currently miss most in Spriter (that would make my workflow a lot more convenient) are 1. having an image-sequence or avi-file as a reference on the background. I plan out most of my animations the old-fashioned way (using DigiCel Flipbook), and I like to do a lot of frame-by-frame tweaking, so having such a reference would be a real timesaver. 2. convert the timeline from miliseconds to FPS and vise versa. I use the classical approach of animating on twos (or for fast animations on ones), and that means that I currently set the time-line to 24, set the playback speed to 2%, and stretch it back to 1000 when the animation is done. This works, of course, but it is a work-around. 3. I would love to see a small animation chart when I select an object so I can quickly evaluate the position of the extremes and relative positions of the inbetweens, similar to the way it would be in classical animation. This could already be partly achieved by showing the timeline of the current selected object(s) above the general timeline. 4. actually applying the property of extreme or inbetween to a frame would be useful to me, because I fist set the extremes and then tweak the inbetweens. Removing an inbetween will have much less impact on the animation than removing an extreme, so it would be useful for me to lock/unlock the extremes. Also having the inbetweens automatically adjust to changes in the extremes close to it (it would still require some manual tweaking) would speed up the process when I suddenly decide to change the position of an arm later on in the project. For me animation-applications are not about automation but assistance. and I approach them from a classical handdrawn tradition; which - for me - has proven to provide the most lively characters.

actually, that is not entirely true. A lot of animators will tell you that animations without follow-through and stretch-and-squash will look stiff. A lot of animators will also tell you that simple cut-out animations are stiff. But that is not the same as saying that animations without deformations (let alone automated deformations with tweening) are stiff. In its current state (Beta 5), it is very well possible to make dynamic animations in Spriter by combining tweened modular animations with a more classical frame-by-frame hand-painted approach. In the quick and dirty animation below, the fast movement of the cat and the follow-through animation in his hair can hardly be considered stiff (timing is a bit off though...I'm still getting used to a millisecond timeline rather than a classical 24 f/s timeline, and there is some opacity that of course doesn't translate to the GIF). Some say that hand drawn phases are never that smooth and stand out too much. But I think the above animation shows that this is a misconception. Even more so, the follow-through as shown here is not achievable using deformations of the original png, and drawing them (digitally) only took a few minutes total which might actually make it faster than optimizing deformed frames. Let me be clear, I'm not necessarily against deformations, they have their uses, and when applied carefully (especially for more generic (sub)-animations) they can be a very valuable addition to any animation-package; I even proposed an idea how they could be made compatible with engines that don't support them without having to cripple oneself by using pre-rendered full-frame PNGs. What I really don't like about deformations though, is, that it often results in rubber-band/elastic movements that look very unrealistic, automated, and - in my opinion - boring. Your He-Man animation is a good example of both the potential strengths and the huge weaknesses of this approach. What I am wondering though is this. You have a piece of software that you really like (Stickman), it does exactly what you want as far as I understand. Why not stick with that? - Because you seem to want to move to either Spriter or Spine in the future (considering that you are very passionate about defending why both should implement this feature), but I don't really see why you'd want to make that move if what you have works for you.

That would be soon enough :) I would also love to see (way beyond 1.0) the option to add notes to frames (textual or handwritten) to make it easier for another team-member to review the animations. By the way...what happens when I were to open a file created in the PRO version in Spriter Free? - Specifically regarding these advanced features?

For the deformations, please also include a 'save' option that converts an scml file containing such deformations into one that doesn't; and where the deformed components are individually saved as images. So if you have a characters where only the belly-sprite is deformed, a sequence of (deformed) bellies should be exported; rather then exporting the while composited character. This would allow for deformations to be (sort of) used in engines that don't support them, while keeping the memory-footprint within reason. (or if that is somewhat unfeasible, please give us the option to turn off specific (advanced) features to make sure features that are incompatible with certain engines are not accidentally used in animations for these targets.)

I had some time to play around with Spriter, and found the following: A. To test some things, I was setting up the hierarchy of a cat-character (top image), and suddenly I noticed that some of my sprites didn't want to be attached to bones (while most do so perfectly well). So I get the following: I select one or multiple sprites from the hierarchy pane, and drag-and-drop them onto the corresponding bone (Bottom row, first image). This seems to work nicely (Bottom row, second image). However, if I click the main panel (or re-open the scml file), the sprites are 'thrown' back to their original place (Bottom row, thirds image). B. When setting up the character I also found that the following occurs when you use (too many?) sub-folders. I have the following file-hierarchy (sorry, the names are in Dutch): The leg folder (Benen) has two sub-folders: Links (left) and Right (rechts). These too have two sub-folders: Voor (front) and Achter (back). Each of these folders have both sprites and a sub-folder containing the sprites for each foot (Voet). Now, when I select one of the sprites from a foot in the main panel (image below, red outline shows its position in the palette pane), and right-click on it. Rather than getting a selection of its siblings in its own sub-folder (Voet), I get to select from the sprites in the parent-folder (Voor). C. A VERY minor thing I noticed: I have a number of sprites in my work-folder (let's say: head, eyes, nose, mouth, neck, chest). I then opened Spriter to create a new project, and directed the application to this folder. The sprites will show up nicely in the palette. I then - while the application is open - start to organize my folder, and I create two subfolders (head and body), and place 'head, eyes, nose, mouth' in the head folder, and 'neck, chest' in the body folder. Spriter will now update the palette live. However, since the sub-folder 'head' and the sprite 'head' shared the same name, the subfolder will get the head-sprite as its icon. Until I restart Spriter of course. D. Also - and I think I already mentioned this one, but am a bit to lazy to check my previous post - changing the Z-order using the keyboard in the main panel is live, doing the same when the z-order-panel is active is not; and the Z-order will not update (neither in the list, nor in the main panel) until the main panel is selected.

Yesterday I was playing around with an animation, and I had the character blink for a few frames. This, of course, was easy enough by just swapping out the sprites. But it made me realize that then combining more complex hand-drawn animations with modular animation, it would be a lot easier if the timeline/key frames for sprite-swapping were separate from the one for body-part movement. So yeah, that's something I would love to see sometime in the future.

Ok, now I understand your point/limitation. I normally prefer to draw a few extra frames for certain body-parts and do the stretch and squash manually using hand-drawn animation; I like the control I get when doing it that way (plus there's a lower chance of making it look rubber-band-like), and it fits perfectly with Spriter...But I can understand that for some many animations it's much easier and faster to have an automated approach that will result in a nice, dynamic, movement without the need to draw additional body-parts. As I said: I just wanted to understand where your limitations came from, to see how it would affect me. So thanks for the clarification.

From the tone of your post I have the feeling I offended you, and if so then I apologize for that, because it was not my intention. Neither was it my intention to attack your opinion (or do I feel that I did). I just asked a genuine question, and give my opinion based on my own experience. For me, there is a lot of freedom already in the software to steer away from simple (and stiff) cutout animations (e.g. by using multiple hand-sprites, dynamic bones, etc), while keeping the memory footprint of these animations low. Still, I would love to see some of the animations you made recreated in spriter to give me a better idea of the 'walls' you run into to make the animation as dynamic as possible. I really just want to understand your limitations (in case I ever run into them). ps. if you would be willing to share some of the basic sprites I would also love to give it a go myself just to better understand your point. Because I'm curious by nature (of course we would have to do that in a different thread ;) ).

Hi Bwwd, while I'm not entire opposed to deformations (and even if I were, I have no say in the things spiter implements ;) ), they are to me only as useful as the (game) engine that supports them. In most cases you do not want spriter to export each frame as a .png-file, but you will want to use the .scml file combined with the character-parts. As a result, many advanced deformations could not be used in many engines. Personally I'd rather use multiple sprites and animate deformation by hand where needed (so strictly speaking combine it with classical animation). This gives me the most freedom and best control (and should allow for dynamic animations)...but that's just a personal taste. Anyway, I'm curious as to how you would implement it, while ensuring that the output is compatible with as broad a set of game engines as possible (in my opinion that means that I should work with at least CSS3) without having to use pre-rendered frames....because I might be missing something (due to my lack of hands-on knowledge with stickman)

Cheers, that helped!

a few things I noticed when playing around (in Windows 8): - I created a quick test character and rigged him with bones to test dynamic re-rigging. So I chose to have him take off his hat (which consists of two separate parts -one in front and one behind his head- that are perfectly aligned but have a different Z and different image-dimensions). The animation itself is 803 frames long, but the timeline is 1000 frames. The re-rigging takes place on the second key. When I go to any frame after the last key, the hat get distorted as shown in the image below. I think I only noticed it after I loaded the project again. - changing the Z-order of an element using Ctrl-Up, Down, Left, or Right doesn't update (neither in the Z-order panel, nor in the central view) until I click the central view (clicking any of the other panels doesn't initiate the update). - setting a transition to 'instant' rather than 'linear' doesn't seem to have any effect. - possibly not a bug but a design-decision, but when I zoom in using the mouse-wheel, then change the zoom using the keyboard, and then use the mouse-wheel again to zoom, the zoom starts from to the last zoom set with the mouse-wheel rather than the current zoom-factor (set through the keyboard).

Since I didn't read all the previous suggestions, I hope I'm not repeating someone. One thing that I was missing is 'animation specific sub-folders' (for lack of a better term) as depicted in figure 1 (lower-part). By default the right-mouse button menu would reveal sprites the usual way, but when there's a sub-folder that has the same name as the current animation the sprites in its respective sub-folders would automatically be added as well. Some of my (test) animations (figure 2) have elements that are specifically created for that animation and would only clutter up the right-mouse button menu when I put their respective root-folders (figure 1, upper-part, red outlines). I can already quite easily put them in their own 'animation' folder, select the element, and right-click the sprite in the sub-folder; and this works quite well. But I don't really like going through the file palette. Also, when I then set the right-mouse button menu to 'object', these animation-specific sprites will still clutter up the menu even when I'm in a different animation where this image isn't used. I really like the default behavior most of the time, but for some special animations I would really like an automated filter of relevant images. figure 1: figure 2: