Spriter2Unity workflow suggestion!

[SkeletalRavenArts]

sorry that am posting this here but am still getting used to using forums ( noob ) 

 

so! 

 

I have been working with Spriter2Unity for a while and I have noticed something very critical to optimizing Spriter to work with Unity better! 

 

In Unity, when using a texture map ( graphic ) it will do a Draw call ( which is pulling that graphic from the game database ), I have noticed something when I use Spriter2Unity, it draw call all the parts of what ever graphic that was made inside spriter into the frame, meaning ( if a character is made out of 20 parts, it will cost 20 draw calls ) for a cellphone game 100 draw calls is a bit too much so 20 is too much for a single character on screen.

 

the solution is! 

 

Unity can slice a single texture sheet to many parts for sprites use, and lets say a map for 4000x4000 has like 100 sprites all these sprites will be a single draw call! but in different batchs. 

 

still a SINGLE draw call! so! if there is a way that we can make spriter slice parts from a single sheet, that will even improve the workflow drastically.

 

for editing, a person can just open a single file, color pick and edit on the fly but when having so many stuff in different small files it will be a bit tought to edit stuff.

 

tell me what you think guys!

[RunnerPack]

I haven't used Spriter2Unity, and I know very little about it, but Spriter already supports texture atlases (via TexturePacker integration), so it seems like it shouldn't take much to implement this (in fact, I'm surprised it isn't already supported).

[Dengar]

Or you know, you could just use Unity's Sprite Packer and solve the issue that way.

 

I haven't used Spriter2Unity, and I know very little about it, but Spriter already supports texture atlases (via TexturePacker integration), so it seems like it shouldn't take much to implement this (in fact, I'm surprised it isn't already supported).

 

The previous version of Spriter2Unity wasn't being supported by anyone, and the current one is only like a week old. I don't actually know anything about TexturePacker or how it works or even that it existed.

That being said, with Unity's Sprite Packer being a thing that exists, inegrating this isn't very high on the priority list. There are still a whole lot of unsolved graphical issues that need fixing, and some other actually useful features that need supporting.

I am also the only one doing active work on it, and I'm doing all this in my spare time, for free, so I'm sorry for not having implemented every little detail for you.

[Mike at BrashMonkey]

@ Dengar,

 

Here is an example Spriter file in which the second animation is  created entirely from images taken from a single texture-atlas created in Texture Packer, in case it becomes useful to support this.

https://dl.dropboxusercontent.com/u/61721248/GreyGuyAtlas.zip

 

@ SkeletalRavenArts,

Here is a link to the documentation for Unity's built in Sprite Packer utility, which by the sound of it should completely solve the optimization issue without forcing you to work with texture atlases while actually creating the animations.

http://docs.unity3d.com/Manual/SpritePacker.html

 

Cheers,
Mike at BrashMonkey

[Dengar]

Thanks Mike, I really appreciate having all these samples to work with.

[Mike at BrashMonkey]

You're doing a great service to all Spriter users, including myself, so please, if you need anything don't hesitate to ask and I'll do my best to accommodate.

 

Cheers,
Mike at BrashMonkey

[RunnerPack]

Or you know, you could just use Unity's Sprite Packer and solve the issue that way.

 

 

The previous version of Spriter2Unity wasn't being supported by anyone, and the current one is only like a week old. I don't actually know anything about TexturePacker or how it works or even that it existed.

That being said, with Unity's Sprite Packer being a thing that exists, inegrating this isn't very high on the priority list. There are still a whole lot of unsolved graphical issues that need fixing, and some other actually useful features that need supporting.

I am also the only one doing active work on it, and I'm doing all this in my spare time, for free, so I'm sorry for not having implemented every little detail for you.

 

I'm sorry, Dengar. I wasn't very clear. I'm not currently using Unity (although I plan to in the future, so I'm very grateful for your work on updating S2U), so I'm not fully aware of what features the two versions of S2U support. I've been following your thread about it, but, again, as someone only vaguely interested in using it in the future, not as an active developer. I was actually referring to the old version when I wondered why it didn't support atlases. It was not meant to be a critique of you or your work. Sorry for the confusion.

 

BTW, just as you were not aware of TexturePacker, I was not aware that Unity has its own atlas-generating utility. If it works with Spriter assets (either now or in the future), then I probably won't even mess with TexturePacker (unless I make sprites for use outside Unity, of course).

[SkeletalRavenArts]

Or you know, you could just use Unity's Sprite Packer and solve the issue that way.

 

 

The previous version of Spriter2Unity wasn't being supported by anyone, and the current one is only like a week old. I don't actually know anything about TexturePacker or how it works or even that it existed.

That being said, with Unity's Sprite Packer being a thing that exists, inegrating this isn't very high on the priority list. There are still a whole lot of unsolved graphical issues that need fixing, and some other actually useful features that need supporting.

I am also the only one doing active work on it, and I'm doing all this in my spare time, for free, so I'm sorry for not having implemented every little detail for you.

 

 

@ Dengar,

 

Here is an example Spriter file in which the second animation is  created entirely from images taken from a single texture-atlas created in Texture Packer, in case it becomes useful to support this.

https://dl.dropboxusercontent.com/u/61721248/GreyGuyAtlas.zip

 

@ SkeletalRavenArts,

Here is a link to the documentation for Unity's built in Sprite Packer utility, which by the sound of it should completely solve the optimization issue without forcing you to work with texture atlases while actually creating the animations.

http://docs.unity3d.com/Manual/SpritePacker.html

 

Cheers,

Mike at BrashMonkey

Thank you so much! super helpful and will make workflow super fast and good!!!!

[esDotDev]

Just to clarify this, all you need to do to enable batching, is select the sprites within the folder, and assign them a "Packing Tag" property, this will cause them to be batched together in a single draw call.

[Dengar]

It actually just smushes all the textures together in a new graphic file that's hidden away in the Libary folder somewhere. And then draws them from that.