Jump to content
Mike at BrashMonkey

Please post feature suggestions here.

Recommended Posts

Will I have to do the whole 'lighting profile' thing for every frame of an animation?

Alas, yes. Sprite Lamp has no magic to offer regarding animation, only lighting - if you were drawing ten animation frames before, now you have to draw ten sets of lighting profiles.

There's no doubt that this increases the art workload, but in our experience (this is a sample size of only one artist, however) it doesn't increase it as much as you'd think. We've found that drawing a set of the images Sprite Lamp requires usually takes about twice as long as drawing a single traditional image. This is because a lot of the work is 'reusable' - a normal workflow with Sprite Lamp involves sketching out the shape of the image, then adding a layer to the image for each lighting profile, and adding shading to those layers. I'll be posting a timelapse video of Halley drawing a set of lighting profiles soon, to show how the time gets divided up.

In the end though, Sprite Lamp definitely increases the time you'll need to spend on art for a given project - whether it's worth it to achieve a particular look is up to you.

So, unless your game has very few frames of animation, have a lot of people to work on assets or have all the time in the world, sprite lamp is quite useless regarding animation, specially with work from software like spriter where the main purpose is to have animations running at high fps and cut corners regarding manwork.

On the other hand, I see this to be quite handy to create some nice lighting effects in backgrounds and other non animated assets, again it depends on the art style of the project.

Share this post


Link to post
Share on other sites
So, unless your game has very few frames of animation…

Replace the word "frame" in your quote with "image". I think that answer is written in the context of frame-based animation. For the kinds of animations we're doing here, a lighting profile for each body part should be enough. (It seems sort of similar to how Double Fine's Broken Age handles lighting.) But as others have said, handling that is more a feature request for an engine than for Spriter.

Share this post


Link to post
Share on other sites

Hi everyone,

Trumgottist hit the nail on the head. lighting methods like those used in Sprite Lamp could work very well with Spriter based animations... the light information images would be created per body part image, NOT per entire specific frame or keyframe...so the additional workload per animation is really not too great, and for people who want/like the effect, it could well be worth it. It could definately be used to creat effects that the vast majority of people would find beautiful...it's really up to the art direction and visual style of any particular game in general...

Obviously we can't promise when support for such lighting effects might show up, per Spriter implimentation (game engine-side) or somehow within Spriter itself, but its definately something we'll eventually pursue after the critical features are rock solid, general workflow is really fun, fast, and flexible, and Spriter's full 1.0 feature set is supported acorss all major authoring systems.

cheers everyone,

Mike at BrashMonkey

Share this post


Link to post
Share on other sites
So, unless your game has very few frames of animation…

Replace the word "frame" in your quote with "image". I think that answer is written in the context of frame-based animation. For the kinds of animations we're doing here, a lighting profile for each body part should be enough. (It seems sort of similar to how Double Fine's Broken Age handles lighting.) But as others have said, handling that is more a feature request for an engine than for Spriter.

Umm no, think about it, sprite lamp depends on having iluminated images from all 4 angles to get a good effect, if you where to make these 4 for a body part for use in spriter, as soon as you rotate the body part the lighting will be all wrong and sprite lamp will produce an erroneous normal map, the body parts will be hit by light in all the wrong parts and the 3D effect will be lost and become a mess.

They are going to integrate sprite lamp to spine so I'm curious is they do something inside sprite lamp to fix the issue I mentioned above, since you would need to recalculate the normal map every time a part is rotated.

Share this post


Link to post
Share on other sites
Umm no, think about it, sprite lamp depends on having iluminated images from all 4 angles to get a good effect, if you where to make these 4 for a body part for use in spriter, as soon as you rotate the body part the lighting will be all wrong and sprite lamp will produce an erroneous normal map, the body parts will be hit by light in all the wrong parts and the 3D effect will be lost and become a mess.

If your interpretation is right, it seems quite badly designed. Isn't a large point of the thing to be able to rotate things freely and have the lighting automatically adjust? But for all I know, you may be right. I haven't really read up on sprite lamp, only given it a cursory glance, so I'm not going to argue against you.

Share this post


Link to post
Share on other sites

Maybe for some backlight effects it would be nice but that could be implemented in spriter so body part would blend lit and unlit bodypart, depends where light would be.Im just wondering if it would look right if bodypart would rotate , it would need to detect rotation and switch slowly for example from top to right side during body rotation.

Share this post


Link to post
Share on other sites

Trixtor you seem to understand more of this than most of us.

Just a question, if each individual part of your fat guy had a normal map, could you calculate the lightning so that it makes sense?

From my understanding of normal maps, if the arm for example has a normal map, if the light on top of it, and you rotate the arm, the "top" part of the normal map would be always illuminated, no matter the rotation.

Share this post


Link to post
Share on other sites

hey tombmonkey,

yes of course, it is usual normal/bump mapping as you would use in a 3d environment (of course simplified since you drop one dimension). If your engine uses a proper bump map implementation, you should not worry about illumination issues.

But you may get some smoothness issues between every body part (too sharp edges, falloff issues, etc.), depending on your art style (if you have sharp edges for each body part those issues will not occur, I think). This can be bypassed with the new skinning feature of Spriter, i.e. instead of creating e.g. three sprites for the arm (upper, lower, hand), you create just one sprite for the whole arm, split it in to three skin parts and attach a bone to each part. Of course the engine, you are using, has to support the skinning feature.

If you could send me some normal maps for your flower/gras girl, I could create another demo video to show you guys how dynamic lighting would look like with bump maps per bodypart.

I may also write a simple application which has the ability to load an SCML file, link the corresponding normal maps to the sprites and illuminate animations with those normal maps. This would remove unnecessary work for future Spriter builds (since this topic has absolutely nothing to do with animations).

I think this was enough off topic for this thread :D.

- Trixt0r

Share this post


Link to post
Share on other sites

Here is the file with normals:

http://www.sendspace.com/file/zf2hsx

I know it's probably gonna look hideous for reasons like: the character wasn't designed to work with dynamic lighting, it's hard to get a decent normal map with just 1 height map (this is why sprite lamp is awesome for 2D artists) and because I rushed the making a bit; but I'm still very curious to see how it looks.

Maybe Mike can move all the sprite lamp discussion to its own thread in the open topic section of the forum.

Share this post


Link to post
Share on other sites

Ok getting back to suggestions for Spriter.

How about some VERY primitive drawing tools inside spriter? A pencil, eraser and bucket tool would be enough. This because sometimes I'm missing a part, or a part needs some modifications and it's usually very hard to know how to make the missing part/make modifications when working with isolated parts in another program.

Having some basic drawing tools inside spriter would allow me to sketch a new part/make modifications, see it on the animation on the fly, and then go to my graphic program to make said part properly.

Share this post


Link to post
Share on other sites

Display pivot X, Y when rendering PNGs

This is a big one, in my current project I have been asked to rendered to png, and the issue I have is that I don't have a way to know where the pivots are for the rendered images, so this is gonna lead to a lot of guesswork and wasted time.

My suggestion would be, either show me where the pivot X and Y would be in the rendered images on the Export dialog, or have Spriter output a .txt file with the coordinates in relation with to the trim rectangle.

My problem is that I render pieces separately ( mask the character with a magenta character map, render the sword, etc ) so I need everything to match perfectly, I had to resort to setting the trim rectangle to the size of the largest sprite on all pieces of an animation, and this lead to a lot of blank space on the images.

Share this post


Link to post
Share on other sites

We wanted to use a stop motion style of animation for our game and I think the only way to turn off tweening in the editor is to select Instant on keyframes one by one. It should be possible to not only make Instant the default but change the curve type of more than one keyframe at a time.

Share this post


Link to post
Share on other sites

-Timeline is by default 1/1000 but it shows only weird values like 490 or 980, i think it should show them more logically like 0/250/500/750 if timeline is 1000.

-When importing new bodypart sprite or skin, spriter could ask do we want to paste bodypart to all existing keyframes if more than one keyframe exists, because its a bit weird right now and its only on one keyframe, should be on all by default, there are very very rare situations when you would want new bodypart only on one keyframe, default behaviour should be changed so it paste new bodypart to all keyframes, at what position? The one you dragged it on screen and let mouse button go, then you can reallign position on all other keyframes yourself, thats more convenient way.

- Autosave current project to spriter folder(not overwrite original file) so we could always get backup, from spriter folder, would be good if save woulkd contain 2-3 undos if something went wrong we could undo last actions to fix it.

Share this post


Link to post
Share on other sites
-When importing new bodypart sprite or skin, spriter could ask do we want to paste bodypart to all existing keyframes if more than one keyframe exists, because its a bit weird right now and its only on one keyframe, should be on all by default, there are very very rare situations when you would want new bodypart only on one keyframe, default behaviour should be changed so it paste new bodypart to all keyframes, at what position? The one you dragged it on screen and let mouse button go, then you can reallign position on all other keyframes yourself, thats more convenient way.

No. There are many scenarios where you would want a part only on the current frame, while pasting on all is mostly for when you failed to set up your character properly before starting to animate.

- Autosave current project to spriter folder (not overwrite original file) so we could always get backup, from spriter folder, would be good if save woulkd contain 2-3 undos if something went wrong we could undo last actions to fix it.

Ctrl + + is there for a reason.

Share this post


Link to post
Share on other sites

Pasting on all keys by holding shift when importing bodypart for example is for adding new body parts you just drawn, its small thing, there is option in menu to paste copied key to all keyframes (doesnt work with skins now tho) i dont do entire character with all possible bodyparts and animate it, i just do basic one versions of body parts with no mouth and hands variations then i test the character and if its fine then i draw different hands , swords/weapons, mouths or eye blinks if character comes out nicely, sometimes i also get back to old characters and i add new stuff to them, i know one instance when you would want to have bodypart on single keyframe is regular frame by frame animation, from reading posts here i see a lot of people dont see it as comfortable default behaviour and they ask how to import new bodypart so its on all keyframes.Especially when starting with software, you dont create entire character, you test it first, and current behaviour scares off a bit if importing bodypart works only for current keyframe, that was first thing that put me off.

Saving with undo is different than editing a file with text editor to fix it and looking for the problem for half of the day.

These things dont break anything, they just keep you more secured.I would like also question when restarting spriter if we want to load previous project but looks like it doesnt remember anything from previous session, even recent projects are older than should be.OR just at least remember last directories, because everytime i create new project im taken to spriter folder and have to browse myself again to my pictures folder, i have folder with all characters in it and its not spriter folder.

As for bad workflow and failing to setup character on beginning... sometimes i think i dont need a bone, then i change my mind cause it doesnt work like expected but im in the middle of animation and i have to paste to all keys, for now im learning actually what not to do in spriter.

Share this post


Link to post
Share on other sites
When importing new bodypart sprite or skin, spriter could ask do we want to paste bodypart to all existing keyframes if more than one keyframe exists, because its a bit weird right now and its only on one keyframe, should be on all by default, there are very very rare situations when you would want new bodypart only on one keyframe, default behaviour should be changed so it paste new bodypart to all keyframes
No. There are many scenarios where you would want a part only on the current frame, while pasting on all is mostly for when you failed to set up your character properly before starting to animate.
Pasting on all keys by holding shift when importing bodypart for example is for adding new body parts you just drawn, its small thing, there is option in menu to paste copied key to all keyframes (doesnt work with skins now tho) i dont do entire character with all possible bodyparts and animate it, i just do basic one versions of body parts with no mouth and hands variations then i test the character and if its fine then i draw different hands , swords/weapons, mouths or eye blinks if character comes out nicely, sometimes i also get back to old characters and i add new stuff to them, i know one instance when you would want to have bodypart on single keyframe is regular frame by frame animation, from reading posts here i see a lot of people dont see it as comfortable default behaviour and they ask how to import new bodypart so its on all keyframes.Especially when starting with software, you dont create entire character, you test it first, and current behaviour scares off a bit if importing bodypart works only for current keyframe, that was first thing that put me off.

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.

Share this post


Link to post
Share on other sites

I base my experience on working with skins so, its easier with sprites and you can just paste to all keys, doesnt work with skins now so maybe thats why i got the impression its needed to paste to all keys when importing, but i agree its hidden too much in menu, using shift when importing bodypart could paste it to all frames but it wouldnt be connected to anything so... maybe it is better to paste it to first frame, then setup and assign it to bone and then paste to all keys.

I guess different software means different workflow.

---

When setting up skins i found out default arrow position is to create new points vertically like this :

qDoDw4R.png

I think it should be opposite and we should create new points horizontally because most characters we create stand on their feet and all body parts go from top to bottom not from left to right, so now i have to always adjust the skin by moving points around to create new segments horizontally, i create segments on joints mostly, is this behaviour created because you have to rotate spite bodypart images in 90degree angle for better stretching ? If yes then why rotation code isnt changed so sprites doesnt require rotating them in 90degree angle ? Also if stretching problem is with sprites, then why skins are affected by 90degree rotation problem , that problem doesnt exist with skins i guess ?Or is it becauyse people dont have to have to make rotated and nonrotaded bodypart for skin and sprite bodypart ?

Its not a big deal but takes time to change the points location, would be nice if we could choose horizontal or vertical placement of new segments.

Share this post


Link to post
Share on other sites

It would be great if we could put our own custom metadata in scml files manually and have it be preserved by the editor. Basically any "unsupported" xml data should be preserved by Spriter on load and save. This way for example we could put a "defaultspeed" attribute on animations that could be used by the game. Or manually create our own special timeline keys for triggering or manipulating whatever we need without editor support.

Share this post


Link to post
Share on other sites

Hi

Just wondering, am I able to make for example the head of my character to follow my mouse ? Or in platformer sprite pack example, the gun able to follow the mouse angle ? Or maybe touch angle.

Is it possible in spriter ?

Share this post


Link to post
Share on other sites

I have been working with spriter and construct 2 for a few months now. This is an example of one of my characters at near actual size, showing the bones:

mutantzombie.jpg

When I drag this into the construct layout and run the debugger, it shows that my frame rate drops about 20 fps from 60+ to 40. When I drag another instance in, the frame rate drops to 15 fps. The image is obviously large so I've tried reducing it down to less than half of it's original size. This greatly reduces the size of the individual images but doesn't change the amount of burden on the processor. Is the problem that my models are too complex? Are there too many bones? Could it be the transparency layer of the shadows? I've heard that that can use up a lot of processor power. I don't know if there is anything you guys could do on your end to minimize the amount of processing power needed but, if you could, that would be great! Thanks for all of your hard work. I love spriter and am looking forward to the next release!

Here are my specs:

AMD Phenom II N970 Quad-Core Processor, 2200 Mhz

AMD Radeon HD 6470M Graphics card

8 GB DDR3 RAM

Share this post


Link to post
Share on other sites

Hi PSI,

Cool monster...If you send me the Spriter project (scml/scon and images) I might be able to suggest optimizations. ( email to mike@brashmonkey.com )

You don't have tons of transparent space around each body part image do you? How big is the actual image file (in pixels) per erach body part?

cheers,

Mike at BrashMonkey

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...