sonder
-
Posts
19 -
Joined
-
Last visited
Content Type
Forums
Store
Gallery
Downloads
Posts posted by sonder
-
-
IK locking does not interact well with scaling. See these screenshots:
-
This interface could be a little more usable.
-
Custom curve dialog's titlebar is "Dialog"
Selecting keyframes and trying to change all of their curve types at once still doesn't work as expected. Been waiting for this since B5.
-
We're still on version 5, but I guess this applies to 5 or 6. We are debating if we should split our main character into several scml files since she needs to have tons of animations that change on each level. The issue with splitting is obvious when you consider that all the images need to be loaded again for each scml wasting VRAM - all the much worse since her body parts are pretty high definition. I could around this by making the engine load each file once, but it would require a bunch of work and could lead to complications down the line with conflicting images.
I think that the right thing is to have a single scml file for the character. My partner (mprart) is concerned that Spriter 5 might barf if the scml file gets too complex, so I wanted to find out as much as I could to see if maybe is something that has been worked on in version 6 and maybe I should just update the Spriter support to version 6 instead of wasting time with the workaround. Or if 5 can handle it fine, if no one has had any issues with very complex files in Spriter 5.
-
We're still on B5, but I've been noticing some issues with timelines and keys belonging to images that have been deleted remaining in the scml file. I was wondering if this has been fixed in B6+?
-
[strikethru]Thanks Lucid, unfortunately that didn't work.[/strikethru]
I know that characterinfo is being used on the "root" bone for sure - a debugging sessions showed that all the other bones have the -1.0 scaley propagated.
I think it has to be a problem in the bone transformation stage but I'm not sure if it's a problem with my code or the psuedocode.
This is some Forth code. I know it's unlikely, but see if you can make some sense of it. (mini cheatsheet: keywords and symbols are executed from left to right with no exception, ( ) just means a comment, ! means =, @ means "fetch value", and p is short for fixed-point)
: unmapFromParent ( struct = spacialinfo ; parentinfo destinfo -- )
locals| dest parent |
angle @
scale 2@ p* 0< if 360.0 swap - then
parent >angle @ + dest >angle !
scale 2@ parent >scale 2@ 2p* dest >scale 2!
( a @ parent >a @ p* dest >a ! )
parent >px 2@
px 2@ or if
px 2@ parent >scale 2@ 2p*
parent >angle @ 2rotate 2+
then
dest >px 2!
pivot 2@ dest >pivot 2!
;I'd show you the bone transform code but it bears pretty much no resemblance to the pseudocode.
edit: oh, oops! I was supposed to check the parent scale wasn't I. standby.
edit2: OK this is what happened when i fixed that. ScaleY=1: https://www.dropbox.com/s/mmvutqlf1xbwi ... .13.04.png ScaleY=-1: https://www.dropbox.com/s/zjrq9zhuiat06 ... .13.06.png
I'm starting to wonder if I'm supposed to be using ScaleY ... shouldn't ScaleX be the one? I only did that because the source animations are "rotated" and I can't even remember what my logic was there.
edit3: Success. https://www.dropbox.com/s/3506il73pt613 ... .18.24.png
Indeed I was supposed to be using ScaleX all along and your fix seems to have worked.
-
Bump
-
Yeah, about the conditional parenting I believe that's what the code is doing, but I'll double check that.
Strangely I think that vertical flipping (via scalex, so actually horizontal rotated) is working but not horizontal (via scaley). Maybe it could be an issue with unmapfromparent? You've tried flipping in both directions?
This code here:
if(currentRef.parent>=0)
{
parentInfo=transformBoneKeys[currentRef.parent].info;
}
else
{
parentInfo=characterInfo;
}under updateCharacter()
should use the CharacterInfo as the parent data for everything without a parent. This means that top level bones, and sprites that have no parent bone should all be flipped as you'd expect, which in turn would propagate down through all child bones flipping/scaling/rotating/moving the entire character, whether or not the character uses bones and sprites, just sprites, or a mix of unparented sprites, and bones
-
So you can see what I'm talking about, here's unflipped
https://www.dropbox.com/s/sn3v0rvvsoord ... .43.40.png
and flipped (negative y scale ... it would be x but the model is animated "on its side" for reasons I don't really understand but the animator said this was best)
-
I suspect that the code in scmlreference does not support flipping because setting either scale parameter negative in characterinfo only flips each piece individually rather than the entire model. I'm just confirming if this is the case and looking for suggestions or possible workarounds. Or if I'm missing something.
Edit: Anyway I don't think we want to flip the images, the shading (side-lit) gets flipped too which looks bad. What we need is a way to flip the bones...
-
Can someone explain this function to me - what is its purpose and when should it be called?
-
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.
-
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.
-
There are more discrepancies, like when you say "for o in blah blah" in a part and then forget to refer to "o"
And in other places I think you return the TimelineKey class when you should be using SpriteTimelineKey or SpatialTimelineKey, not sure.
It's been a big heavy going for me unraveling how everything is supposed to work together. It's a pretty good doc though.
-
I'm not sure if there's any demand for it, and my project is marching forward, so for the time being I'm going to not worry about this and just concentrate on getting it to work in the game in Forth.
-
Great question sonder!
Not yet but very soon Spriter will support variables that can be set per frame which could be used for anything like triggering specific pixel shaders, triggering vertical or horizontal velocity, causing the spawing of other objects etc in the game. The limit is pretty much your immagination. ;)
cheers,
Mike at BrashMonkey
Cool.
I had an idea the other day on a way to tween shader parameters or the like with Spriter right now - use a named reference to a hidden or offscreen object and tween its alpha, scale, rotation, x, y, etc and then read those in the renderer. It's a "cheat" but I think it would work...
-
Does Spriter support animating "unsupported" properties, like say a parameter of a pixel shader?
-
Hi - new to Spriter. I'll be creating a Spriter implementation for SwiftForth for this project: http://www.mprart.net/the-lady/ - when it's at a certain maturity level I'll create a thread for it.
Anyway, I got the idea while looking at the developer docs, it seems to me a generic DLL could be created that could create and process its own data structures per frame, and the client application would call a function that would do a frame's worth of processing, returning a pointer to a "display list" that would tell you what sprites to place where, in what order and with what transformations. Maybe it could go a step further and implement screen-space culling and potentially other useful features. This way, anyone using any language that can use C calling convention DLL's would be able to make use of all of Spriter's features.
Would anyone have any interest in this?
Spriter R7 Bug Thread
in Spriter
Posted
That's what I'm doing though, creating keyframes. In fact I don't plan on using tweens at all, just keyframes. (Or if I do use tweens, I'd adjust every frame by hand.)
Any time a parent of an IK locked bone is scaled, the IK locked bone is correct until you let go of the mouse button. It then snaps to a seemingly unpredictable angle where the end point's position isn't respected. It's consistent, though, so it must be some simple bug in the math.