A bunny

It should also have the ability to make UT release Unity 5 today, and in perfect condition. No bugs.

Oooh, I'd like to work toward some kind of blendtree/animation state manager type solution. I remember a discussion about trying to tie the spine runtime to mechanim once the new unity 5 scripting stuff hits. Do you have any plans to work on something like this at some point? Any thoughts on what direction you'd go? I'm going to work on something like this in the near future (not sure whether I'll go mechanim) and would definitely be interested in helping out if you think something like this could make a good addition to the runtime (and if you want any help).

As long as I'm making large random requests, one thing I'd really like to see in the runtime is drawing code in SkeletonRenderer which can draw characters with only front facing meshes, even when the animation is flipped. I know this is pretty random, but it's something that completely resolves multiple lighting issues in unity. Actually, I already have working code for non-mesh animations, but meshes seem like a huge headache. I wonder how tough it would be for Nate to do it :p

Yeah, waiting for new mechanim features in 5 seems like the most logical approach at this point. I'm trying to resist putting time into building my own system right before a better one becomes more easily possible.

On the subject of forward facing meshes, I feel like I should be really clear (not sure how well I'm communicating, I only slept a few hours last night...) What I want is for the meshes that get created in SkeletonRenderer to all be facing the same direction, rather than a mixture of front faces and back faces with cull off used in the shader. The main reason being that all the advice I've found about getting shadow receiving fully working on backfaces in unity has simply said "don't use backfaces." It also seems to fix some issues with the current deferred lighting and with projectors as well. Spine anims with projectors are cool!

Anyway, doing this for regular quads is easy

if you rearrange the order of the quad vertices so you're going counter clockwise instead of clockwise, backfaces become frontfaces. Then all you have to do is flip the UVs*. Doing this for mesh attachments seems like more a challenge, but I haven't really dug into the mesh attachments rendering code enough to say what the difficulties actually are. I think it just looked complex :p

*You also have to take into account attachments which are rotated in the atlas, which meant I had to add a bool field to another class, if I remember right. If anyone popping in here wants the non-mesh attachment code, let me know and I'll post it.

Oh, I got one.

You remember the problem we tried to solve where we wanted a character to be rendered in front of and behind another renderer? You made the renderer check for * to force the drawOrder list to break up into extra submeshes. The whole thing with the hero on the raptor?

I tried doing it the other day and I couldn't figure it out so I couldn't help out that one guy who wanted to do it.

So, if not actually improving the implementation (by not resorting to the non-rendering material), maybe just some kind of clearer documentation or a more obvious way to use it?

Hey mitch, looking forward to trying out the attributes! It'll be a few days because I have to get around to updating to the newest version of spine. I'll post feedback when I get there.

Thanks for all the work you do.

A flexible and effective loader/unloader for Atlas Texture~
In current runtime:

1. we can not load texture flexibly and preload texture MANUALLY for reducing battle loading time.
2. Can not dispose huge mount of atlas textures actively... the MaterialsTextureLoader.Unload block is empty
   and found nothing about unload any more.

Words can't describe how exciting this is

Mitch, when you plan to push it into repository? We want this feature a lot :-)

Hmm... and what is that big feature? :-)

I won't spoil Mitch's surprise, but it's pretty damned cool! :happy:

That looks great!

Do you think there are any significant performance differences (memory or cpu) on mobile devices for the baked native unity animations vs animating via spine runtime?

Wow... nice feature. :-) Thank you Mitch :-) How far are you guys with shadow solution? :-) From your screenshot I understand that you are working on 3D shadows. but we also need like 2D shadow solution. That means we have flat sprites on which we need to cast shadows like they are 3D. Any idea how to simulate it?

I mean if I use 3D shadows and I have just flat sprite behind a spine animation I will always get whole shadow and my sprite from toes to head. But what is more needed is (try to imagine that the sprite behind is something like a ground) to simulate like that sprite is 3D with some z depth.

Thanks for this!

Can't tell you how excited I am. Perfect timing too, I was just about to hack together my own controller.