[html5 webgl]Parts drawn with unwanted seams.

ErikH2000

I have an HTML5 animation app that uses the Spine HTML5 WebGL runtime for rendering. The image below shows the issue I'm having...

The head is rendered onto a canvas element. The top and bottom halves of the head have a "seam" between them. It looks possibly like a 50% alpha effect at the top edge of the mouth. I would like the two parts to be joined seamlessly as I see them within the Spine editor.

Things I've looked at and or tried to get rid of the seam:

All tests in HTML5 app are performed with a clean cache before execution.
Verified that the part images within the exported atlas PNG do not contain translucent (alpha < 1) pixels at their edges.
Aligning the translation X/Y of slots in the Spine editor on even numbers.
Trying Y+1, Y+2, Y-1, Y-2 variations of positioning in the Spine editor.
Combinations of export settings - PNG format, aliasing, rotation, strip whitespace, edge padding.
Adding an empty row of alpha-0 pixels in the part asset as padding.
Upgrading to latest version of HTML5 runtime. (@todays version)
Loading in a different skeleton to HTML5 app that uses entirely different assets (it shows the same seam problem).

I'm running out of ideas! My code is based on what I found here: spine-runtimes/index.html at 3.6

I suspect the shader may be introducing the artifact. But I will be honest

that is a fairly difficult part of the code for me to understand.

Any ideas? Maybe someone has asked a similar question already?

-Erik

ErikH2000

Pharan

Does the seam follow the skeletons and image's movements or does it stay where it is like an overlay on the canvas?
Have you tried putting other things on the canvas?
Does the same problem exist on different computers and browsers?

Mario

What HTML5 backend are you using? Spine-ts WebGL? Spine-ts Canvas? Are you using premultiplied alpha? What browser and OS are you using (including versions)?

Pharan

(He said WebGL.)

ErikH2000

Pharan wrote
Does the seam follow the skeletons and image's movements or does it stay where it is like an overlay on the canvas?

It follows the skeleton. When I change attachments on a slot, other attachments have the seam as well, though it is not consistent.

Have you tried putting other things on the canvas?

Yes. I have another similar Spine project with a split head that was created by a different artist with a different set of tools in her workflow for creating assets. The seam issue comes up there as well.

Does the same problem exist on different computers and browsers?

Not sure. I can try this when I get home.

badlogic wrote
What HTML5 backend are you using? Spine-ts WebGL?

Yes, this one.

Are you using premultiplied alpha?

The atlas is exported with premultiplied alpha. The code that performs the render, sets premultiplied alpha with the value from the skeleton. (Same code as in demo) I tried it with premultiplied set to false as well.

What browser and OS are you using (including versions)?

I need to wait until I get home for versions, but Chrome and MacOS.

Thanks for thinking about my question. Pharan, too!

Pharan

I meant other non-Spine things. Have you tried it?

ErikH2000

Pharan wrote
I meant other non-Spine things. Have you tried it?

Pharan, I'm not sure I follow. What would I try?

Mario

Can you send us the Spine project, including which skeleton in the project gives you problems, as well as the attachments that are most problematic? contact@esotericsoftware.com

ErikH2000

@badlogic, yes, I will send the Spine project. I'm really impressed that Esoteric is willing to look at it.

To answer some previous questions...

MacOS version: 10.10.3 (Yosemite)
Chrome version: 67.0.3396.87 (Official Build) (64-bit)

Tried also on Firefox just now and saw the same "seam" issue when the skeleton is rendered in my HTML5 app.

Re having tried other non-Spine things, I've opened the atlas PNG inside of photoshop to inspect, and saw no artifacts. In particular, I was looking for translucent pixels (alpha < 1) around the problem attachments, but found no evidence of that.

Tonight, I tried one another thing with no luck

aligning the attachment positioning at the tenth decimal place to make it so the attachments line up perfectly in Spine. (I was just using whole #s before.)

Okay, zipping up some files to send to heroic support staff next...

I've done more research since then. I think I've narrowed it down further.

It seems that any rendered attachment will have an edge effect applied to it. And it seems that the issue happens in the Spine demos as well and probably for all rendered attachments. You just don't notice the edge effect because the underlying attachments tend to have visual borders at their edges that disguise it.

I was able to get the edge effect to show in the 3.6 Spine demo with unmodified code by just changing an atlas PNG to be an all opaque color. You can see the modified PNG below.

When running the demo that uses this modified Heroes.png, the edges unexpectedly show as grey. This looks like the same artifact I've been battling in my project. Below is what the demo looks like with the modified Heroes.png.

Erika

Aren't grey edges a problem you can solve by enabling premultiply alpha in the runtime, or if this doesn't work, disabling the premultiply alpha option from the Spine export? Texture Packing - Spine User Guide

ErikH2000

Erikari wrote
Aren't grey edges a problem you can solve by enabling premultiply alpha in the runtime, or if this doesn't work, disabling the premultiply alpha option from the Spine export? Texture Packing - Spine User Guide

Thanks for the tip. I tried enabling and disabling premultiply for export. But to no avail—problem is unchanged.

Mario

This is a texture filtering problem due to the way the atlas for your skeleton is packed. The top head part is packed at the bottom of the atlas. When the texture is sampled, the border regions are sampled as well, resulting in the line you see. The issue is visible in the spine-ts runtime as well as the reference implementation (Java Skeleton Viewer).

You can fix this by increasing the region padding in the texture atlas packing settings (I set it to 8 pixels for demo effects).

That will fix it at 100% zoom

However, texture filtering is fickle. Your top and bottom parts aren't perfectly aligned. Just zoom in as much as possible in the editor and you'll see it.

If you click the bottom part, you can see the y-position set to -149.1.

If you change that to -148, you get a nicer, non-visible seam

ErikH2000

Wow, thank you so much!

I had played with edge padding earlier but too hastily discarded it as a solution, I think because a second problem was also present while I was fiddling with this that made me incorrectly think edge padding was not helping.

The second problem I had was that the positioning of attachments to exactly match the seamless adjoinment varies depending on how the rendered skeleton is scaled in the canvas. So I spent some hours last night hand-editing the skeleton Json based on the rendering results to get the seam to disappear. And I made sure the browser was at my target scale while doing it.

And I made hand edits to the atlas file to remove sampling outside the intended area of the attachment in the skeleton png. This is the artifact you described. But thinking about what you said, a duplicate padding setting should alleviate this problem. And my hand edits had the Ill effect of removing a row of content, which is worse than just having duplicate padding.

The attachment positioning issue that I hand-edited the JSON for might also go away by tweaking the padding settings, but from my understanding of how they work, I don’t think so. In the future, I might include an overlap area of a few pixels in the adjoining edge of the attachment images themselves. My thinking is that this would make the edge matching much less finicky.

Yeah, the hand-editing was far from ideal, but next time I think I could do without it. Thanks so much for your troubleshooting and explanation.

Nate

The duplicate padding will help with filtering (ie when things are scaled or rotated), but the gap between attachments was the real killer. With world axes you shouldn't need to guess, you can input numbers to position it exactly. Careful though, the region attachment position is the center of the region. If your region has odd dimensions, you'll need to offset your world position by 0.5. Eg, if your image is 101px tall and you position the center at y=50, your region pixels will be drawn from 50-(101/2) to 50+(101/2), which is -0.5 to 100.5. Being off by half a pixel will cause filtering to kick in even at 100% zoom (because the region pixels won't match the screen pixels), and may also cause you to pull your hair out when positioning attachments to be adjacent. If you use y=50.5 then your region pixels will be drawn from 0 to 101.

ErikH2000

Nate wrote
The duplicate padding...

Pure gold. Thank you, Nate.