Corona is the only runtime not supporting meshes?

Spine
#61

I’ve been considering this idea for a while, just posting it now. There are quite a few things that a simple interface like that would open up, in my opinion, even if the implementation might be “use at your own risk” for a while.

At the moment, something like meshes really does need SDK support, not so much because of the implementation itself, but that the objects need to be in the hierarchy to be of any use.

(I’m not exactly volunteering to do meshes, though I would be pretty thankful if I was suddenly able to do a few other things listed in that link.  :slight_smile: )

#62

Yes, this is great news. I’d expect some sort of display.newMesh ?

#63

It will be something like that.

#64

I hope not. Imagine a skeleton with many different mesh attachments. Usually not all are visible at the same time. Are all the mesh scene graph objects created up front for every skeleton instance? Are they created as needed? Are they destroyed when no longer in use? The skeleton would have to jam the visible scene graph objects in the scene and shuffle them around as their draw order changes. All of this adds complexity and hurts performance. It is avoided by using a MeshBatch type of implementation like I described above. It is very simple and removes all the unnecessary layers, and not just for Spine rendering.

#65

Certainly it will be counter productive to come up with a solution that doesn’t take real world use into account. Esoteric are handing the design of this on a plate. Is it safe to believe that Corona engineers are working in tandem with Esoteric on the implementation of this feature?

#66

May I respectfully request that we don’t speculate and wait until we actually release this?

Thanks

Rob

#67

I’m sure the Corona guys will do what they feel is best considering all the goals they have.

Composition of multiple scene graph objects has overhead. It’s quite common for frameworks where use of a scene graph is mandatory to need to do lower level rendering to bypass that overhead. Also, by far the biggest drawback to using a scene graph is that it couples the model and view. In this case the model is the Spine data. We have all the data for what we want to render, it’s just a matter of giving it to Corona for rendering. Using multiple scene graph nodes for rendering means the data gets spread across many scene graph nodes. This same pattern repeats for other rendering, so a lower level batching API would be widely useful. Plus, it’s likely this functionality already exists behind the scenes, it’s just a matter of exposing an API.

#68

how is it going?

#69

We are making good progress.

Rob

#70

If fact, here is more information on the progress: https://forums.coronalabs.com/topic/63441-displaynewmesh-preview/#entry329267

Rob

#71

Download latest build or Corona and new Spine runtimes, and enjoy Mesh attachments in action.

Beware it’s in open beta. Test well before shipping to production.

#72

Fantastic work, can’t wait to try some tests.

#73

 
Thanks. Also, big thanks to [member=‘Esoteric Software’]. However, Corona being first user of Spine Lua runtime, there are a lot of problem there connected to mesh manipulations. That code never had chance to be properly tested before today, really.

There is open issue on Spine’s github to fix it https://github.com/EsotericSoftware/spine-runtimes/issues/601

I will help as much as I can (I already am, as you can see from the issue)

#74

Well, thanks to the recent arrival of the texture canvas resource and some pointers from the staff concerning shaders, I recently started a mesh implementation. Building on this, as of last night I have some Spine meshes rendering, using a few assets kindly provided by sirmania : link

It’s still a bit lacking: there are no per-vertex colors (I’m not sure I have anything to test this with, at the moment) nor FFD (I believe I’ve got a mesh that uses this). Also, the draw order needs fixing somewhere. Otherwise, you might be good to go. (The mesh stuff is implemented in mesh.lua and the impl directory. It’s a bit messy and not well-commented or -documented!)

These aren’t straight-up display objects, so various properties like rotation, scaling, and so on probably won’t work quite as expected, if these are even relevant. Perhaps as I refine the mesh object I could address some of them, or maybe something official will land down the road.

I’ve made a pull request of the non-Corona-specific bits to the Spine crew, so possibly that will make it in soon. We’ll see what they want to do about the rest.

I think I’ll leave it a few days before giving FFD a go. In the meantime, let me know of any weird results.  :slight_smile:

EDIT : Some of that other stuff (more or less) works now too.

#75

Found time to get into Mesh animations in Spine. Seeing some great early results.

Question vlads or anyone up with the Corona runtime. If you print to the terminal during skeleton:createImage it outputs the number of attachments in the spine object being created. But printing in skeleton:createMesh causes the terminal to output the attachments endlessly. I don’t know how skeleton:createMesh works but is that normal?

To be more specific, the current code outputs every attachment in the spine object endlessly in the terminal.

function skeleton:createMesh (attachment, meshParameters) print("mesh = ", "examples/spineboy/images/" .. attachment.name .. ".png") local mesh = display.newMesh(meshParameters) mesh.fill = {type="image", filename="examples/spineboy/images/" .. attachment.name .. ".png"} return mesh end
#76

Hello,

Thank you for adding meshes support. It is fantastic!

I’ve been playing with the new spine runtime. With the spine-boy-mesh example I had no problems, but when I try the “raptor” example some error occurs. Maybe I’m missing something, but it might be a bug of the beta version. Did anybody try to load this example? This is the error:

ERROR: Runtime error /Users/pauors/Documents/01 Projectes/spine-corona/spine-lua/MeshAttachment.lua:88: attempt to perform arithmetic on local 'vy' (a nil value) stack traceback: &nbsp;&nbsp; &nbsp;/Users/pauors/Documents/01 Projectes/spine-corona/spine-lua/MeshAttachment.lua:88: in function 'computeWorldVertices' &nbsp;&nbsp; &nbsp;/Users/pauors/Documents/01 Projectes/spine-corona/spine-corona/spine.lua:225: in function 'updateWorldTransform' &nbsp;&nbsp; &nbsp;/Users/pauors/Documents/01 Projectes/spine-corona/examples/raptor/raptor.lua:47: in function \</Users/pauors/Documents/01 Projectes/spine-corona/examples/raptor/raptor.lua:38\> &nbsp;&nbsp; &nbsp;?: in function \<?:169\>

Now we are animating our own character. Let’s see how it works. Thank you.

Pau Ors

#77

Hello, [member=‘pau7’] and [member=‘kilopop’]! There is an open bug on spine-runtime repo to fix Lua runtimes. Corona is first Lua runtime to ever support meshes, so there are some issues with it. Comments to that bug also contain some hacks to make Raptor example works.

I will take a look on why meshes are constantly being re-created. Anyway. I would suggest to avoid using meshes intensively - they are computationally expensive. Use in moderation.

#78

Hey guys, just so you know if you are using the latest version of Spine the mesh support will not work. They are in the process of updating the runtimes. If you rollback the version of Spine you are using to the version before (you can do this in the menu) it should work.

#79

It seems they’ve changed the name of the “ffd” container in the output JSON files to be called “deform” in the latest version of Spine. It is pretty easy to make it work again - just go to SkeletonJson.lua file in the spine-lua folder and change row 469 

from

local ffd = map["ffd"]&nbsp;

to

local ffd = map["deform"]

Now even the newest version of spine should work with meshes again. 

#80

You that have successfully used meshes - which version of Spine were you using?