Mesh deformations in 2.0

Solar2D Advanced Graphics
#1

I’ve just ran into the new Spine Kickstarter #2 and they have some really cool features. That one interesting me is the mesh deformations.

They mention this is going to be supported in Corona 2.0 which is GREAT news, the problem is I think this is incorrect.

Can someone from Corona give a look at this:

http://www.kickstarter.com/projects/esotericsoftware/spine-features

And tell me if this kind of deformation will be possible, especially the inner vertices and adding new ones to the mesh. As far as I understood you can only deform the path which only includes the vertices on the border, am I wrong?

#2

That would be truly amazing!

However, since only quadrilateral distortion is supported at the moment, I think it’s not going to be possible  :(. 

#3

When I last read that page they specifically said Corona would not be supported for that.

I see they’ve changed that text, and now have:

Note spine-corona will be able to support the new features once their Graphics 2.0 API is released.

This is factually incorrect - there is nothing in Graphics 2 that will allow them to do what they want. That is not to say it wouldn’t be possible in the future, but G2 currently lacks an important feature to enable it, something Walter tells me is called affine transformations (the ability to distort the quads but without perspective ditortion being applied, merely a linear one).

I should really knock up my own distortable 9-slice thingy to test, to let other people see where the ‘errors’ (not an error as such, just undesired side-effects in this particular case) creep in.

I think the reason they claim to be able to do it is for the very same reason I made the same mistake initially with the quad distortion - assuming the internal distortion within an image would be linear, not perspective.

#4

@rakoonic, I’m almost certain you are right but I don’t understand the language :slight_smile:

Sorry I have very little experience in 3D programming can you explain what you are saying but a bit more basic? I really want to understand it…

#5

I just got an official reply from Nate at esotericsoftware:

quote---------------
If Corona only allow the vertices of a quad to be adjusted then we can still support FFD there, but only for images that have only 4 vertices. There may be other restrictions, eg they may not allow us to change the texture coordinates of the vertices. In this case you would have to use the 4 corners of your image instead of being able to place the vertices inside the image.
end quote-----------

#6

Hi qtt, I think Nate is correct, acording to this:

http://docs.coronalabs.com/guide/graphics/3D.html

It says “more complex effects”

#7

Nate is clearly talking without specific knowledge of Corona - so as it stands I’m still confidant that I’m correct.

That does *not* mean Corona won’t make some changes (indeed, I’ve talked with Walter about this, and we both hope that a way can be found), but as it stands, Spline won’t work.

It isn’t the subdividing that is the problem (you just use an image sheet to generate the slices and stick them next to each other), it is the deformation. You can make the outer edge of an image any shape you want, but it is the internal deformation, as done by OGL, that is the issue.

I’ll try to give an example:

Say you have an image.

You split it, using imagesheets and sprites, into a left half and a right half.

You now create 2 sprites, one from each half, and position them on screen, so you are looking at the whole image again.

Now, you want to deform this image along the middle line (IE the right hand edge of the left slice, and the left hand edge of the right slice).

You can indeed do this fine using the .path property, and as long as you move the ‘paired’ points on each image the same amount, it’ll be ‘fine’.

OK now, so far so good.

Now, move one of the other corners. IE from the left edge of the left half, or the right edge of the right half.

This is where it goes wrong.

The joined edge in the middle will now look wrong. The two halves won’t match up, breaking the single image ‘look’ of the two sprites.

This is because of the perspective distortion. I have an example here:

lvvgL8d.jpg

Note how the edge between the two floor tiles doesn’t match up, despite the smaller squares all being the same size? This is because of the perspective effect. THIS is what currently goes wrong, and prevents Spine from doing what it claims - or rather, doing it without large graphical glitches.

It isn’t Nate or anyone lying, it is just them not understanding the current (and I stress ‘current’) limitations placed on quad distortions by Corona / OGL. I won’t argue more here as frankly I’m ambivalent about the whole Spine thing, but if I find time I’ll knock up a small demo to illustrate the point. Just do bear in mind that the Spine guys are talking about Corona without actually having looked at G2 and its capabilities and limitations.

#8

Ok @rakoonic, I understand what your saying now :slight_smile:

But I think this is the smaller issue, the bigger issue is that you cannot create a mesh of vertices and bind it to a texture. You do not control the triangolation and therefore you cannot do any of the deformation described in the video. except the most simple case of a quad.

I’m not talking about having a sprite sheet and split it to images, that’s not a good solution, first because you are limited to rectangular images and cannot freely add vertices, secondly performance… I’m currently running into a performance limit with the spine runtime and I do not want to think what toll it will take if I try to manage so much more that in lua…

The way this is done in libGDX and probably in other engines is you create a low level mesh and let OGL do the hard work… What you are suggestion moves a lot of work to the CPU which won’t run fast enough for sure…

#9

Oh sure, but I imagine that they would be planning on implementing it loosely using a grid definition - it would be a limitation but it would allow a decent amount of flexibility. However, even that isn’t possible for the reasons I stated above. But yeah, I went back to the page and see what you say - they are definitely claiming you can do the ‘any point’ deformation.

It does raise the issue of being able to tweak UV coordinates specifically (either at the sprite level or the frame generation level) which would be a very useful feature indeed *hint hint* walter :wink: A new image sheet frame definition method that is just a set of 4 points instead of them having to be rects would be cool. Or a .UVpath property on an image that works as offsets like the .path property :smiley:

#10

That would be truly amazing!

However, since only quadrilateral distortion is supported at the moment, I think it’s not going to be possible  :(. 

#11

When I last read that page they specifically said Corona would not be supported for that.

I see they’ve changed that text, and now have:

Note spine-corona will be able to support the new features once their Graphics 2.0 API is released.

This is factually incorrect - there is nothing in Graphics 2 that will allow them to do what they want. That is not to say it wouldn’t be possible in the future, but G2 currently lacks an important feature to enable it, something Walter tells me is called affine transformations (the ability to distort the quads but without perspective ditortion being applied, merely a linear one).

I should really knock up my own distortable 9-slice thingy to test, to let other people see where the ‘errors’ (not an error as such, just undesired side-effects in this particular case) creep in.

I think the reason they claim to be able to do it is for the very same reason I made the same mistake initially with the quad distortion - assuming the internal distortion within an image would be linear, not perspective.

#12

@rakoonic, I’m almost certain you are right but I don’t understand the language :slight_smile:

Sorry I have very little experience in 3D programming can you explain what you are saying but a bit more basic? I really want to understand it…

#13

I just got an official reply from Nate at esotericsoftware:

quote---------------
If Corona only allow the vertices of a quad to be adjusted then we can still support FFD there, but only for images that have only 4 vertices. There may be other restrictions, eg they may not allow us to change the texture coordinates of the vertices. In this case you would have to use the 4 corners of your image instead of being able to place the vertices inside the image.
end quote-----------

#14

Hi qtt, I think Nate is correct, acording to this:

http://docs.coronalabs.com/guide/graphics/3D.html

It says “more complex effects”

#15

Nate is clearly talking without specific knowledge of Corona - so as it stands I’m still confidant that I’m correct.

That does *not* mean Corona won’t make some changes (indeed, I’ve talked with Walter about this, and we both hope that a way can be found), but as it stands, Spline won’t work.

It isn’t the subdividing that is the problem (you just use an image sheet to generate the slices and stick them next to each other), it is the deformation. You can make the outer edge of an image any shape you want, but it is the internal deformation, as done by OGL, that is the issue.

I’ll try to give an example:

Say you have an image.

You split it, using imagesheets and sprites, into a left half and a right half.

You now create 2 sprites, one from each half, and position them on screen, so you are looking at the whole image again.

Now, you want to deform this image along the middle line (IE the right hand edge of the left slice, and the left hand edge of the right slice).

You can indeed do this fine using the .path property, and as long as you move the ‘paired’ points on each image the same amount, it’ll be ‘fine’.

OK now, so far so good.

Now, move one of the other corners. IE from the left edge of the left half, or the right edge of the right half.

This is where it goes wrong.

The joined edge in the middle will now look wrong. The two halves won’t match up, breaking the single image ‘look’ of the two sprites.

This is because of the perspective distortion. I have an example here:

lvvgL8d.jpg

Note how the edge between the two floor tiles doesn’t match up, despite the smaller squares all being the same size? This is because of the perspective effect. THIS is what currently goes wrong, and prevents Spine from doing what it claims - or rather, doing it without large graphical glitches.

It isn’t Nate or anyone lying, it is just them not understanding the current (and I stress ‘current’) limitations placed on quad distortions by Corona / OGL. I won’t argue more here as frankly I’m ambivalent about the whole Spine thing, but if I find time I’ll knock up a small demo to illustrate the point. Just do bear in mind that the Spine guys are talking about Corona without actually having looked at G2 and its capabilities and limitations.

#16

Ok @rakoonic, I understand what your saying now :slight_smile:

But I think this is the smaller issue, the bigger issue is that you cannot create a mesh of vertices and bind it to a texture. You do not control the triangolation and therefore you cannot do any of the deformation described in the video. except the most simple case of a quad.

I’m not talking about having a sprite sheet and split it to images, that’s not a good solution, first because you are limited to rectangular images and cannot freely add vertices, secondly performance… I’m currently running into a performance limit with the spine runtime and I do not want to think what toll it will take if I try to manage so much more that in lua…

The way this is done in libGDX and probably in other engines is you create a low level mesh and let OGL do the hard work… What you are suggestion moves a lot of work to the CPU which won’t run fast enough for sure…

#17

Oh sure, but I imagine that they would be planning on implementing it loosely using a grid definition - it would be a limitation but it would allow a decent amount of flexibility. However, even that isn’t possible for the reasons I stated above. But yeah, I went back to the page and see what you say - they are definitely claiming you can do the ‘any point’ deformation.

It does raise the issue of being able to tweak UV coordinates specifically (either at the sprite level or the frame generation level) which would be a very useful feature indeed *hint hint* walter :wink: A new image sheet frame definition method that is just a set of 4 points instead of them having to be rects would be cool. Or a .UVpath property on an image that works as offsets like the .path property :smiley:

#18

Hi, I’m Nate. I’m ridiculously late to this topic. :frowning: Still, better late than never I suppose.

Unfortunately it appears that rakoonic is right, Corona does not deform images in the expected way. For example:

jIRrHtZ.png

What this means is that Spine can support 4 vertex meshes as planned, but the way the image deforms in Corona will not match how it deforms in Spine.

This is extremely surprising. My apologies for not finding this sooner, but I never would have thought this would be the case. The docs even show “meshes” using multiple deformed images, but this is not going to work right with Corona’s deformation.

Does Corona support linear scaling? If not, when or will it?

.

#19

Hi, I’m Nate. I’m ridiculously late to this topic. :frowning: Still, better late than never I suppose.

Unfortunately it appears that rakoonic is right, Corona does not deform images in the expected way. For example:

jIRrHtZ.png

What this means is that Spine can support 4 vertex meshes as planned, but the way the image deforms in Corona will not match how it deforms in Spine.

This is extremely surprising. My apologies for not finding this sooner, but I never would have thought this would be the case. The docs even show “meshes” using multiple deformed images, but this is not going to work right with Corona’s deformation.

Does Corona support linear scaling? If not, when or will it?

.