Big nasty bug-- Cannot modify vertices.

AAnnaB · 8 lug 2020

Hi there, I did find another post about this same bug, but it was from over a year ago and I did not see a resolution.

In my scene, certain meshes cannot be modified, but some can. For instance, I CAN modify the mesh for the body, and I CANNOT for the head. All settings on these meshes are identical as far as I can deduce. But on the body everything works fine, and on the head I cannot delete vertices or move vertices. The transform tool simply will not move (as if locked), and if I attempt a delete I just get the error "vertex could not be deleted".

I am aware I can reset the mesh, but it would take a very long time to rebuild the meshes and re weight them, so that is not an efficient workaround. I have emailed my scene file to contact@esotericsoftware.com withe the title of this post as the subject line. Our company pays for an enterprise license so a prompt response would be very much appreciated.

Thank you!

AAnnaB · 8 lug 2020

Nate · 8 lug 2020

We received the project and can reproduce the problem, thank you. We'll let you know as soon as we have more information.

The problem was that some mesh vertices were on the edge of the image. There were internal vertices on top of hull vertices for the head and both ear meshes. To see it, go to Edit Mesh, then uncheck deformed. Eg, here is the left edge of the head:

Immagine rimossa a causa della mancanza di supporto per HTTPS. | Mostra Comunque

We adjusted your vertices and emailed you the modified project, which you'll be able to edit as normal. Eg:

Immagine rimossa a causa della mancanza di supporto per HTTPS. | Mostra Comunque

I'm not sure how your meshes got this way, but Spine detects collisions in order to enforce the mesh topography rules (eg, that the orange or blue edges cannot cross). We've adjusted this detection for v4.0 so your original, problematic project can be edited there.

If this occurs again, you may be able to fix it yourself by deleting the problematic vertices or edges. When the mesh somehow has been saved with a collision, you won't be able to delete vertices if after the deletion it still has a collision. However, you can delete vertices if afterward there is no collision, so you can delete all the problematic vertices in one deletion, then recreate them. In some cases it may be enough to delete just the internal (orange) edges, which is always allowed, then move the vertices so they aren't on top of other vertices or edges, then recreate the internal edges.

AAnnaB · 8 lug 2020

Hi there. I have sent you another few emails...sorry for the long train...in the end your fix mostly worked in that I can now move the vertices. However, now there is an issue where the pixels are like...sticky to the vertices even when in "modify" mode, and also I cannot get the edge of the mesh to move far enough that it is actually outside of the image in certain areas...while in other areas I can. So the edges of the mesh are permanently cut off. So they are still pretty broken and un-modifiable. Can you please take another look at the scene and let me know if you can repair this?

Nate · 8 lug 2020

Your meshes appear to have the shape you want in setup mode and in Edit Mesh mode when Deformed is checked. However, if you uncheck Deformed then you will see that the vertices are probably not in the right places.

You can never move mesh vertices outside the image. I think there may be some confusion about the undeformed vertex placement. The "undeformed" vertices are the UVs, which is where on the image the vertex takes pixel data. The "deformed" vertices are the actual mesh vertex locations, which is where the vertices are because you translated them or used weights to translate them. Maybe this helps:
Meshes - Spine User Guide: Deformed

Usually you don't want your meshes deformed in the setup pose because usually the mesh image was created to already look as it should in the setup pose. To remove the deform, select the mesh and click Reset, though this will also remove the weights and keys. Note this is not inside Edit Mesh mode, the Reset button in Edit Mesh there will reset your mesh to 4 vertices.

How did you create these meshes? It looks like you are trying to reuse an existing mesh with a new image? Since the vertices are crushed against the side of the image, there's nothing we can do to recover the original mesh. Do you know what steps you took to end up with a mesh with crushed vertices? By crushed I mean look at the left and right edges (and the top a little):

Immagine rimossa a causa della mancanza di supporto per HTTPS. | Mostra Comunque

I can't think of when Spine would do that to a mesh. Also, Spine should disallow creation of a mesh with collisions.

If you want to use the same mesh with a different image, you can use linked meshes. If you want to use the same mesh as the foundation for a new mesh, you can duplicate the mesh, rename it so it uses a different image, and then edit the vertices as needed.

AAnnaB · 8 lug 2020

Your last sentence "If you want to use the same mesh as the foundation for a new mesh, you can duplicate the mesh, rename it so it uses a different image, and then edit the vertices as needed" is exactly what I am trying to do.

I have two characters which are extremely similar. They have slightly different contours but the exact same assets in general. It's just two cats. In the past we have always been able to take a scene that has two extremely similar characters, re-link the image path to a new image folder with different images (again, very similar images but with slightly different contours), and then make small modifications to those meshes to adjust for the difference in contours. Of course this means that we do not have to completely re-do meshes, weighting, and animation for two nearly identical characters that need nearly identical animations. Which is great.

This time, initially the meshes were totally locked, and now as you see they are still not working correctly. This is a brand new problem we have never faced before. This exact same process has always worked for us in the past until this new update...we've done it literally hundreds of times.

UPDATE: Ok so I did figure out a way around the issue, but it does in fact verify that it is an issue with the update. I was working in the newest version- that is 3.8.96. I realized I could try to revert to a previous version, and then try to use "import project" to bring the newer scene in rather than actually trying to open it. I did that and am pleased to say I was able to get the scene into the reverted version. I re-did the process of relinking the images and this time it worked great. No locked meshes, no sticky pixels. So yeah, it is definitely something with the update. For now we will all revert and stick to the old version...could you please update me by email when you know the issue is resolved so that we don't get too far behind? It would be very much appreciated.

Sorry that I didn't bring up the relinking of images in my original post- if that was the cause of the issue then I can see where it would have steered you wrong.

Thank you for your help

Nate · 8 lug 2020

I'm glad that going back to 3.8.95 lets you stay productive. It's strange though because there shouldn't be any changes in 3.8.96 in this area. There were changes to how images are loaded, but not with meshes or mesh vertices specifically.

Aha, I think I reproduced the problem with these steps:
1) Open spine-pro.
2) Rename the head mesh to gun.
3) When this dialog appears, choose Yes:

Immagine rimossa a causa della mancanza di supporto per HTTPS. | Mostra Comunque

The mesh now looks like this:

Immagine rimossa a causa della mancanza di supporto per HTTPS. | Mostra Comunque

If you choose Yes on that dialog it tries to keep the head mesh the same size, but the gun image is smaller so it clips the mesh, producing a bad mesh that has collisions. We'll fix this and change the dialog buttons so it is not a "yes" or "no" answer, as I expect people click "yes" for "yes whatever, make this dialog go away".

If you choose No then the mesh is scaled to the new image size, which is probably what you want.

More info on the dialog:
Meshes - Spine User Guide: Image resize

AAnnaB · 8 lug 2020

Ok, great, yes that's good to know! I do not think that's the entire cause of the issue, only because, as I said, we have done this process hundreds of times...we have definitely used both of those options to experiment and never saw any issues before, certainly not this "locked verts" issue. So yeah maybe it's a combination of how images loading has been changed and also this setting? It did seem like it was not correctly sensing the edges of the images or correctly relating them to the mesh.

Nate · 9 lug 2020

I'm 99% sure it's because 1) the new image dimensions were smaller than the old mesh, and 2) you chose Yes on that dialog. If you choose No then Spine doesn't manipulate the vertices at all, they are just stretched to fit the new image dimensions. If you choose Yes it will be OK even if the new image is smaller than the old image, as long as the old mesh dimensions fit within the new image. If they don't, that is when the edges of the mesh get crushed. I don't think there is anything else in Spine that can cause that.

AAnnaB · 9 lug 2020

Ok, well as I've said we've been using the tool and this process for 2 years to transfer animations between hundreds of characters and have never seen this issue before. And I know that we've used both "yes" and "no". I know there have been changes to the image sizes that meet or exceed the changes to the images sizes we had in this project. Neither myself or my coworker have had "locked" meshes before, we were completely stumped. So I am not 99% convinced the issue has existed this entire time (at least in this form/to this degree) or I believe we would have encountered it at least once. It's possible but seems unlikely to me. Not trying to discount your opinion, just trying to lay out the facts as to why I'm still doubtful.

Ignoring that whole thing- if you are correct that it comes down to the dialogue box, I would agree that yes, you need to change that. In what situation is "yes" ever the correct choice? Your description makes it sound like basically you're saying that it "tries" to keep the mesh the same size but in fact breaks the mesh when doing so if there is any variation whatsoever.

This whole process is about linking different images than were used when creating the mesh. Of course sometimes that would be something like a color adjustment, but there's a huge likelihood the contours of the image might change slightly. As in this situation- we're talking about two cats that are basically the same size and shape- literally just one is slightly rounder in the face.

There should at least be a warning that choosing "yes" will break the scene if there is any variation to the size of the image.

Nate · 10 lug 2020

That the steps I provided reproduce the problem are a stronger indicator that is how it happened. It could be in the past if you chose Yes then your image was large enough to contain the mesh.

We've already adjusted the dialog in Spine v4 and it looks like this:

Immagine rimossa a causa della mancanza di supporto per HTTPS. | Mostra Comunque

The dialog won't appear at all if the new image is not large enough for the "keep size" option (formerly Yes), in that case it applied "stretch".

The "keep size" / Yes option is useful when you have added/removed whitespace around your mesh image. That is a reasonably common need, since you can't move vertices outside the image bounds. If Spine always did "stretch" / No then you'd have to redo your entire mesh if you added/removed whitespace.

3.8.97 is now up! It doesn't have the new dialog because that would require translations and we wanted to get it out quickly, but it does the fix the problem with the dialog crushing the vertices against the edge of the image. Similar to in v4, the dialog won't show if the resized images are too small to use the "keep size" / Yes option.

If you see the problem again in 3.8.97 or later, then I will admit you were right and the dialog is not the only cause.