• Editor
  • [Feature Request] Mesh Points Snapping to Pixel Grid

Related Discussions
...

Hello!

I was attempting to animate Pixel Art by FFD, through spine meshes. Technically, it works fine and is very nice to build pixel art animations and custom characters (through skins). Nonetheless, if I want to import spine files instead of spritesheets into the game engine (in this case, Unity), I see small problems with a few pixels (because I couldn't perfectly deform them in Spine, regardless of my efforts). These problems aren't seen when I turn on the Snap to Pixels option in Spine, but it will obviously don't export with those pixels snapped.

I would greatly appreciate some sort of option where I could automatically snap all mesh points to pixel grid AND/OR place mesh points snapped to pixel grids while moving them. I prefer the first option, of course, because it would save me much more time and I would be able to edit mesh points easier (instead of trying to move mesh points that are very close to each other).

Not sure if I explained myself, but if there are any doubts, feel free to tell me. And if there is already an easy way to solve my problem, I would appreciate any explanation!

Thanks in advance, Spine is lovely!

This is actually not as easy as snapping vertex positions to a pixel grid when exporting from the editor. This needs to be solved on the runtime side. As you are using Unity, I let Harri, our Unity wizard, figure out how to do that 🙂

badlogic escribió

This is actually not as easy as snapping vertex positions to a pixel grid when exporting from the editor. This needs to be solved on the runtime side. As you are using Unity, I let Harri, our Unity wizard, figure out how to do that 🙂

Oh, thank you! I guess it's more a Runtime thing rather than an Editor one. I was looking forward to guides for the ruler tool to make mesh deformation more accurate, but if there is a way to do it through the runtime, that would be gorgeous!

I'm attaching an example of the problem I face, just in case it helps.

Are you using an actual pixel grid mesh in Spine?

Yeah... I noticed that most character animations were just similar FFD that could work decently for most of them. In the same time, my goal was to be able to customize them. It works perfectly fine if I export these characters as images. That already saves me a lot of time, so this technique does help and Spine is perfectly fine for FFD Pixel Art animations.

NONETHELESS, I don't want sprites if I can get the skeleton (who would?). Thus, I would need the mesh points snapped to the pixel grid in order to achieve the results I'm looking for.

Here is a small example. I put the character in an idle stance, and get the character walk animation. It works fine for skins (especially for multiple skins in order to choose torsos, pants, shoes, etc.).

Of course, if you could add a pixel art oriented mesh edit mode in Spine, that would be CRAZY. But it would already be more than enough with some runtime code to snap mesh points to pixel grid.

I'm also sharing with you this video to see the problems I find in Unity. Do you notice the small pixels and lines that ruin the final result? These may not be noticed if I zoomed out, however, as soon as I zoom in, the inaccuracies are noticeable.

What you want to accomplish can be done in Unity by selecting the atlas texture in the Project panel and in the Inspector setting Filter Mode to Point (no filter). If you want further pixel-snap functionality, you can change the shader at your material to Spine/Sprite/Unlit (or any Spine/Sprite shader), they provide an additional Pixel Snap parameter.

BTW: using point filtering instead of linear should allow you to use normal bone workflow and still have the pixellated effect. Just mentioning since using so many vertices might create performance problems in combination with FFD at some point.

A vertex-snap functionality would not be too helpful in general, as it would still leave diagonal edges, solving only some special cases.

Thank you Harald!

Indeed, the textures are already using point filtering. I set the shader to Spine/Sprite with the Pixel Snap parameter on. It appears with the same problems.

Do you mind if I send you the project so you can check the problem as well?

If your screen (or rendertexture) resolution is not at the desired snapping resolution, it will thus just snap to screen pixels and not yield the desired result. You can use Unity's PixelPerfectCamera component for this see the docs pages here.

Note that depending on the Unity version it can be found either as a built-in component (newer versions) or as an experimental Unity Package Manager package via the Package Manager (enable "Advanced - Show Preview Packages").

Then you can add the PixelPerfectCamera with following settings to achieve a pixelated effect, working also with other shaders:

Interestingly, PixelPerfectCamera did not work out of the box at a local Unity 2019.2 test project, perhaps some things regarding the render pipeline or related settings must be set up as well. It worked well out of the box in Unity 2018.4 (as can be seen in screenshot above).

I see... thank you! I will look into it, I should have got the pixel perfect camera in the project so I don't find these problems. Nonetheless, I fear that a bone based animation will still bring me small problems in some cases (usually rotating pixels will sooner or later be noticed in most cases). However, I wonder if 9206 verts are a problem for spine projects. Will this be problematic (by itself) if in the scene there were around 15 characters at the same time?

I may be able to clean some verts that are usually unused, but I will most likely need at least 5000-7000 verts for this.

AtskaHeart escribió

However, I wonder if 9206 verts are a problem for spine projects. Will this be problematic (by itself) if in the scene there were around 15 characters at the same time?

Perhaps it is not a problem, but it is for sure far more than seems necessary for what you want to accomplish.

AtskaHeart escribió

I may be able to clean some verts that are usually unused, but I will most likely need at least 5000-7000 verts for this.

The question is why you need all the inner vertices around every single pixel (as shown in the above image). I would assume that it will be sufficient to have only e.g. 5 unconnected quads for the complete leg (so 20 vertices per leg) and still being able to move the sections around as before.