[Animation] Animation Nation


Recommended Posts

Ok, so it seems you liked my little birdies, thankyu!

 

It's time to get dirty with animations the way you do.

 

I'm a newbie to Spriter and i have to say...it's a brilliant tool!

 

Just touching a little I managed to do this:

 

https://dl.dropboxusercontent.com/u/49907104/skybirds.rar

 

Is in the Spriter format, as I see the (amazingly made) beanlets uploaded this way.

 

They're far from over, but I thought maybe you could guide me, and correct anything thats wrong (sizes, number of key frames,etc...)

 

PS: dont have a name for them yet, so i call them brown, green and humming XD Anyone lend me a hand with this? :)

Link to comment
Share on other sites

Ok, so it seems you liked my little birdies, thankyu!

 

It's time to get dirty with animations the way you do.

 

I'm a newbie to Spriter and i have to say...it's a brilliant tool!

 

Just touching a little I managed to do this:

 

https://dl.dropboxusercontent.com/u/49907104/skybirds.rar

 

Is in the Spriter format, as I see the (amazingly made) beanlets uploaded this way.

 

They're far from over, but I thought maybe you could guide me, and correct anything thats wrong (sizes, number of key frames,etc...)

 

PS: dont have a name for them yet, so i call them brown, green and humming XD Anyone lend me a hand with this? :-)

 

Humming didn't have an animation, but I assume it's because it's not finished or anything.

 

The only suggestion I have is to maybe make the brown idle animation loop a little smoother. Other than that, that's fantastic work!

 

Link to comment
Share on other sites

@simplex

I'm currently turning Wilson (the one in the corner on the main screen) into Winnie, but I'm running into a problem. It's not wanting to load the "corner_up" bank and build at the main screen. Do you know a way to remedy that?

 

Edit: Nevermind, I think I'm going to cheat and just loop a player animation. :p

 

Here's a disturbing image of the transformation:

 

EB8etoQ.png?1

Link to comment
Share on other sites

@simplex

I'm currently turning Wilson (the one in the corner on the main screen) into Winnie, but I'm running into a problem. It's not wanting to load the "corner_up" bank and build at the main screen. Do you know a way to remedy that?

 

Edit: Nevermind, I think I'm going to cheat and just loop a player animation. :razz:

I don't know what you're talking about. I don't get what you mean by "it's not wanting to load [...] at the main screen", nor do I know what this "corner_up" bank is.

Link to comment
Share on other sites

I don't know what you're talking about. I don't get what you mean by "it's not wanting to load [...] at the main screen", nor do I know what this "corner_up" bank is.

 

Sorry, I should elaborate. I decompiled the corner_dude animation (the Wilson that normally appears in the corner.) and recompiled it (and replaced the sprites with Winnie's, or at least I was in the progress of doing so...) and it would not load at the main screen. The log was complaining about not being able to find the bank or build (which I had named "corner_up")

 

It doesn't matter, though, since I've successfully got it to load the regular Winnie animations and there is practically no difference. :p

Link to comment
Share on other sites

With regards to questions about animating the Manta:

 

(Not sure who to quote, here, since a bunch of you were talking about it. ^^; )

The way I've theorised to be best for animating snakey things like that in Spriter fluently, is to take advantage of the "skin" mode, where instead of solid images being parented to the bones, the bones can be used to drive deformation.

I have no doubts that the engine does not support skinned textures, but the skin animation can be exported from Spriter as an image sequence, and brought back in - we can then switch the image out, much like we would with, for example, a facial expression, and animate it in a flipbook of switching symbols, like a more traditional frame-by-frame animation.

Of course, the simple rotate/translate/scale animation can be done as normal, and should be combined with the flipbook-type-stuff for efficiency.

 

Since it's relevant. =)

Link to comment
Share on other sites

@simplex

Do you know how I would use krane to decompile equippables? When using it on things like hats and armor, the recompiled result is always quite absurd when implemented in-game.

Swappable builds work differently. Cheerio put in a hack in the scml compiler to allow compiling them, though I haven't checked it with krane decompiled builds/anims to make sure it works.

How and what did you decompile?

Link to comment
Share on other sites

Swappable builds work differently. Cheerio put in a hack in the scml compiler to allow compiling them, though I haven't checked it with krane decompiled builds/anims to make sure it works.

How and what did you decompile?

 

I decompiled the beefalo hat, and I decompiled it like anything else, since it has an anim.bin.

Link to comment
Share on other sites

Try duplicating the "anim" animation and renaming the copy "BUILD_SWAP".

 

So, that works for the front view, but whenever you turn, it always stays on that image.

 

I wish this kind of thing was more accessible to animators and modders.

Link to comment
Share on other sites

So, that works for the front view, but whenever you turn, it always stays on that image.

 

I wish this kind of thing was more accessible to animators and modders.

I don't believe there's much to be done. Swappable builds work very differently, and the scml compiler has only very basic support for them, via this "BUILD_SWAP" hack. If I were to rewrite the scml compiler from scratch, I could implement a system handling this in most cases (though not all; swappable builds rely on some things that don't fully match Spriter's format), but otherwise it should be treated as a missing feature in the scml compiler, which I have no intention of implementing due the large amount of code which would need to be rewritten.

Link to comment
Share on other sites

I don't believe there's much to be done. Swappable builds work very differently, and the scml compiler has only very basic support for them, via this "BUILD_SWAP" hack. If I were to rewrite the scml compiler from scratch, I could implement a system handling this in most cases (though not all; swappable builds rely on some things that don't fully match Spriter's format), but otherwise it should be treated as a missing feature in the scml compiler, which I have no intention of implementing due the large amount of code which would need to be rewritten.

 

Of course, it's not your responsibility. :razz:

 

I hope Klei will eventually address this. (They might be able to, considering multiplayer.)

 

@simplex

Do you know of a way to check the player's facing direction? I'm looking at the locomotor component, and it does use direction, but I don't see any way of returning the value of direction.

 

I think that an equippable could be rigged up to change its BUILD_SWAP animation (by switching to a different build) when the player's direction is changed.

Link to comment
Share on other sites

@simplex

Do you know of a way to check the player's facing direction? I'm looking at the locomotor component, and it does use direction, but I don't see any way of returning the value of direction.

GetPlayer().Transform:GetRotation()
But this in itself doesn't mean anything, it's just the rotation with respect to the coordinate system. You need to compare this to the camera's direction (TheCamera:GetHeadingTarget()) to determine what's the perceived rotation. But keep in mind the camera's rotation is flipped with respect to entities' rotations (i.e., if the player's and the camera's rotation differ by +-180 degrees, then they point to the same direction, i.e. the player is facing up).

 

I think that an equippable could be rigged up to change its BUILD_SWAP animation (by switching to a different build) when the player's direction is changed.

This doesn't look like a proper solution to me. Not in the sense that it wouldn't work, it just might, but it's way too hackish and circumstantial. I think we should just ignore swappable builds, unless there's something that can be done at the Spriter level (Malacath's wand Spriter project might be of use).

Link to comment
Share on other sites

GetPlayer().Transform:GetRotation()
But this in itself doesn't mean anything, it's just the rotation with respect to the coordinate system. You need to compare this to the camera's direction (TheCamera:GetHeadingTarget()) to determine what's the perceived rotation. But keep in mind the camera's rotation is flipped with respect to entities' rotations (i.e., if the player's and the camera's rotation differ by +-180 degrees, then they point to the same direction, i.e. the player is facing up).

 

This doesn't look like a proper solution to me. Not in the sense that it wouldn't work, it just might, but it's way too hackish and circumstantial. I think we should just ignore swappable builds, unless there's something that can be done at the Spriter level (Malacath's wand Spriter project might be of use).

 

 

Fair enough, it is certainly hackish.

 

The spriter wand project works fine for equippables that have no sense of direction. For things like armor and hats, it doesn't really work.

Link to comment
Share on other sites

@debugman18

I can't extend krane to decompile the build.bin and anim.bin in shop_basic, because they don't have the hash table at the end. If it weren't for that, it doesn't look like it'd be very hard to do so, but without it I can't possibly decompile them. That's the same reason why I can't decompile builds renamed with Matt's build renamer.

Link to comment
Share on other sites

@debugman18

I can't extend krane to decompile the build.bin and anim.bin in shop_basic, because they don't have the hash table at the end. If it weren't for that, it doesn't look like it'd be very hard to do so, but without it I can't possibly decompile them. That's the same reason why I can't decompile builds renamed with Matt's build renamer.

 

Ah, alright.

 

I was thinking I could piece together the shopkeeper into his animations, if necessary. So that'll likely be what happens.

Link to comment
Share on other sites

Ah, alright.

 

I was thinking I could piece together the shopkeeper into his animations, if necessary. So that'll likely be what happens.

Wait, scratch that. I should be able to work without the hash table, I just won't be able to preserve the original animation and animation symbol names and compatibility with animations in the original animation bank (without decompiling them as well; though compatibility with those is usually lost anyway).

I just don't know when I'll have the time to implement that.

Link to comment
Share on other sites

Wait, scratch that. I should be able to work without the hash table, I just won't be able to preserve the original animation and animation symbol names and compatibility with animations in the original animation bank (without decompiling them as well; though compatibility with those is usually lost anyway).

I just don't know when I'll have the time to implement that.

 

It's not a major issue right now. Like I said, I can piece together an animation from the atlas, but even that can wait.

 

Oh, as for the video, I rerecorded a large chunk of it without the freeze overlay (although I'm going to keep it for a couple of small scenes). I'm editing right now, and as soon as that's done I'll upload it.

Link to comment
Share on other sites

@debugman18

shop_basic.zip

shop_farm.zip

I added support for legacy build and animations to krane. It also supports legacy textures, due to that having been added to ktech and them sharing code.

EDIT:

@debugman18

The shop_farm Spriter project above only has the animation "anim", found in its anim.bin, where it just remains static. The following is the shop_farm project including the animations found in shop_basic:

shop_farm_extended.zip

which I obtained via:

$ krane --build shop_farm UpAndAway/anim/shop_basic.zip UpAndAway/anim/shop_farm.zip /path/to/shop_farm
But we don't need to duplicate the anims in both places. The recompiled anims from shop_basic should be fully compatible with a recompiled shop_farm build.
Link to comment
Share on other sites

@debugman18

I tweaked a bit how legacy builds and anims are handled. Now I'm using the hexadecimal ids of symbol names (and other things) instead of giving them consecutive numbers. This should ensure interoperability of recompiled builds and banks, as in the case of shop_basic and shop_farm, at the cost of legibility. The animation symbols (i.e., the image folders) can be renamed, but if so they must be given the same name in all builds using the bank.

shop_basic.zip

shop_farm.zip

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.