EsotericSoftware / spine-runtimes

2D skeletal animation runtimes for Spine.
http://esotericsoftware.com/
Other
4.35k stars 2.89k forks source link

Mesh doesn't work with Corona #339

Closed Aly2412 closed 8 years ago

Aly2412 commented 9 years ago

Hi everyone. I try to use Spine with Mesh in Corona but it doesn't work. I try to fix some small bugs like : forgeting require MeshAttachment in AttachmentLoader.lua, calling SkeletonData.findSkin instead of SkeletonData:findSkin in SkeletonJson.lua, or something like that. But it has some huge bugs with array index, attachment verticles, v.v.v, in SkeletonJson.lua. It seems that the one who ported it from other languages didn't remember to change start index from 0 to 1. And in Lua, table doesn't have length method, it requires using #table to get its number of children.

I tried to fix as many errors as I can. But function:

... local ffd = map["ffd"] if ffd then

...

in Skeleton.lua has too many bugs with Lua which I don't have enough experience in Spine to fix them. Please take a look at this. Thanks for reading.

codynguyen commented 9 years ago

Hi,

Is there anyone from Esoteric interested in solving this? The problem's been posted on the forum for 6 months now: http://zh.esotericsoftware.com/forum/viewtopic.php?f=9&t=2873

At least please give us a heads up on the timeline of this runtimes or when it can be fixed.

Thank you very much

NathanSweet commented 9 years ago

Very sorry for the delay. We talked via email but I'll also put it here for others.

Please see here: http://esotericsoftware.com/forum/viewtopic.php?f=11&t=3690&p=17990 Corona is unable to render meshes. The update on the issue is that the Corona guys have acknowledged the problem and I have worked with them so they understand what Corona needs to support rendering meshes. I'm afraid the ball is in their court at this point.

I haven't yet implemented rendering for any game toolkit using Lua, so the spine-lua mesh code has not been validated. There are likely typos and minor problems. It is not possible to render meshes with Corona. LOVE can do it, but I haven't had time to implement the rendering there.

Aly2412 commented 9 years ago

Thank for your reply.

I have checked Corona forum, but it seems they still doesn't support it. If you have contacted with them, please let us know your ( and their ) plan about it.

And about the Lua Runtime, don't worry. Many of your user will help to fix it :)

JaredSartin commented 9 years ago

@NathanSweet How goes the Lua work? I can't seem to get Love to render meshes with your current setup:

Error: spine-lua/SkeletonJson.lua:267: attempt to call field 'newSkinnedMeshAttachment' (a nil value)
stack traceback:
    spine-lua/SkeletonJson.lua:267: in function 'readAttachment'
    spine-lua/SkeletonJson.lua:171: in function 'readSkeletonDataFile'
    main.lua:35: in main chunk
    [C]: in function 'require'
    [string "boot.lua"]:374: in function <[string "boot.lua"]:244>
    [C]: in function 'xpcall'
NathanSweet commented 9 years ago

LOVE has the capability as a game toolkit to render meshes, but I haven't had time to implement mesh rendering there.

ggcrunchy commented 8 years ago

Hi.

I suspect I have the machinery necessary to do this in Corona, or am at least close. By the looks of it, the uvs and world vertices are all updated already by the runtime. Does "support rendering meshes" entail anything more than dealing with those (indexed, of course)?

If not, I might give this a go.

pharan commented 8 years ago

Mesh support requires that you can push your own vertex data (positions, uvs, and preferably vertex colors) as well as triangles (not just quads).

ggcrunchy commented 8 years ago

I'm getting there, but a little stuck. (I have skinned meshes rendering, just not 100% there: a coherent textured square that seems to be bending away from the bone, though not as if simply flipped. So I could probably submit some spine-lua fixes in the near future if nothing else.)

Is there a guideline for figuring out x and y here, before rendering (I saw some thing like skeleton.y + bone.y in one of the runtimes, but this doesn't seem to concur with what I've needed to hack manually).

If my uvs' v coordinate seems to be flipped, might this indicate something?

Also, when are regionU2 and regionV2 to be set? I'm not seeing anything relevant in the JSON file I was given nor in the C# runtime I've been comparing against now and then. I defaulted them to 1 so that I would get what seem to be reasonable uvs, but wonder if there's a step I'm missing.

Apologies for the vague questions. If there'd be a better or more direct way to field them, I'm open to it.

NathanSweet commented 8 years ago

The runtimes are currently being upgraded to v3. They are all done except spine-js and spine-lua. spine-js will be next, so you may want to submit a PR for spine-lua else you may have some conflicts to resolve.

It sounds like you have run into Corona's perspective scaling.

Since spine-lua hasn't been used for mesh rendering, it may need adjustment. Most runtimes receive a slot and use slot.bone.skeleton.x/y to access the skeleton position (which is the 0,0 world coordinates in Spine). The vertices are transformed and added to the skeleton position.

Region UVs are usually set by AtlasAttachmentLoader. Since Lua toolkits don't have great support for texture atlases (Corona is especially bad at this), this hasn't been fleshed out in spine-lua.

pharan commented 8 years ago

@ggcrunchy Different engines seem to accept different UVs. (DirectX and OpenGL have opposite V values. This also results in a funny thing between XNA and Unity. They share the same spine-csharp runtime, but they also have opposite V values.)

If you're seeing flipped UVs, depending on your engine or which code you're using as reference, you may have accidentally ported some things.

ggcrunchy commented 8 years ago

@pharan I guess that was a bit of a silly question. Since the non-meshes looked right, I didn't investigate very far. :smile:

@NathanSweet I was definitely unaware that atlas attachments were involved! I'll give those a look.

This actually uses a custom solution motivated by some additional render texture support that recently landed (on that note, what atlas shortcomings are you running up against?). I have a couple texture-based mesh techniques and then a fallback that I implemented along with them, the latter being what I'm trying to use. (Small test project is here with a short summary here. The test project expects a newer daily build, though the fallback shouldn't require anything too recent.)

When I get the chance I'll submit a PR.

Thanks!

NathanSweet commented 8 years ago

An atlas is not necessarily a grid and regions need to be looked up using names.

ggcrunchy commented 8 years ago

I might have this working--I had an off-by-one error in an indexing operation, should have been bone = skeletonBones[bones[v] + 1], didn't have the +1--sans color (shouldn't be hard, just haven't done it), though I think I'll try to gather some more examples to throw at it.

Is it fine if there's an extra (x, y, weight) triple in the array, or is that evidence of a problem? (Are these details spelled out somewhere besides code?) I'm wondering if I have the index off there too, despite the results appearing fine.

NathanSweet commented 8 years ago

All the data should be used, you shouldn't have an extra entry. Weighted mesh data isn't in the JSON export format documentation, but the WeightedMeshAttachment class serves as an example.

jonbro commented 8 years ago

is this being worked on, or are you looking for a pull request on this? I can take a stab at the implementation for love, it seems pretty doable. I have no idea about corona or any of the other lua runtimes, but I am happy to match the api for the other platform agnostic bits of code. I am guessing c# is the reference implementation?

pharan commented 8 years ago

@jonbro spine-libgdx is the reference implementation. It's what Spine editor runs on. If you understand C# better, it's the closest thing to that, except spine-csharp is more agnostic of the game framework since spine-libgdx uses libGDX classes and spine-csharp is shared between XNA and Unity.

Feel free to try your hand at an implementation. You might have better insight into what's available as a user.

New features are still being added to the editor so we're probably going to bunch porting those to the runtimes when it's ready.

ggcrunchy commented 8 years ago

@NathanSweet Whoops, didn't see this. Hmm, well, I'll try to reexamine it at some point.

For what it's worth, my results all look plausible, apart from a hiccup on the last frame (the animation loop seems to be off... I see code that handles that, but wasn't able to puzzle anything out).

Most recent results: project (The different tests are loaded in main.lua.)

@jonbro While not a very enlightening title (was just one line in the commit), I've got the strictly Lua part of my changes pending here, if you'd prefer to shave off some boring debugging effort. :smile: