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.)