Jump to content


  • Content Count

  • Joined

  • Last visited

  1. 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 spr
  2. 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
  3. 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 u
  4. 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
  5. 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?
  6. 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 sect
  7. 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 dim
  8. 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.
  9. 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 th
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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?
  15. 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 spec
  • Create New...