UV Texture Coordinates in spine-cpp

SneakPlatypus

I have been pulling the spine runtime into my own rendering and after several days I cannot figure out what's going with the uv coordinates. I have all the animations playing just fine and all of the meshes are constructed properly but the texture will not line up even close to where it's supposed to be.

The spine-cpp guide page seems to simply pack the uv pairs from MeshAttachment::getUVs() function. I tried that and it got very random looking texturing.

I am computing the world vertices and then packing them into a buffer, then drawing with glDrawElements using the indices provided by MeshAttachment::getTriangles() which gives me a nice mesh which animates perfectly. I've tried all manner of using MeshAttachment::getUVs() and MeshAttachment::getRegionUVs() and various calculations using the region UV range and region width/height.

I'm just wondering if you really are supposed to be able to just pull the uvs from MeshAttachment::getUVs() and use them directly as the runtime guide suggests or if there is a trick to calculating the actual texture coordinates from the MeshAttachment data.

The texture coordinates are just getting piped into glsl texture(sampler2D, uv). The packed texture is loaded correctly because I see bits of the character but they are no where near where they should be.

I just want the basic process of pulling the uvs but here's the block in question if you want to look at it.

Render Function

void SpineSprite::render(Camera* camera)
   {
      SpineSpriteType* spriteType = &spineSpriteTypes[type];
      Shader* shader = &shaders[spriteType->shaderIndex];
      spine::AtlasPage *page = spriteType->atlas->getPages()[0];
      GLuint* texture = reinterpret_cast<GLuint*>(page->getRendererObject());
      shader->use();
      shader->setMat4("projection", camera->getProjection());
      shader->setMat4("view", camera->look());
      glBindTexture(GL_TEXTURE_2D, *texture);
      int numSlots = skeleton->getSlots().size();
      glBindVertexArray(VAO);

  for (int i = 0; i < numSlots; i++)
  {
     std::vector<SpineVertex> vertices;
     spine::Slot* slot = skeleton->getDrawOrder()[i];
     spine::Attachment* attachment = slot->getAttachment();
     // to-do: retrieve slot blend mode
     
     std::vector<unsigned short> indices;
     if (attachment->getRTTI().isExactly(spine::MeshAttachment::rtti))
     {
        spine::MeshAttachment* mesh = static_cast<spine::MeshAttachment*>(attachment);
        size_t numVertexFloats = mesh->getWorldVerticesLength();
        spine::Vector<float> floatVertices;
        floatVertices.setSize(numVertexFloats, 0.0f);
        mesh->computeWorldVertices(*slot, floatVertices);
        spine::Vector<float> uvs = mesh->getUVs();
        vertices.reserve(vertices.size() + (numVertexFloats / 2));
        // pack data            
        for (size_t j = 0; j < numVertexFloats; j += 2)
        {
           SpineVertex vertex;
           vertex.vertUv = glm::vec4(floatVertices[j], floatVertices[j + 1], uvs[j], uvs[j+1]);
           spine::Color vertexColor = slot->getColor();
           vertex.color = glm::vec4(vertexColor.r, vertexColor.g, vertexColor.b, vertexColor.a);
           vertices.push_back(vertex);
        }
        spine::Vector<unsigned short> meshIndices = mesh->getTriangles();
        indices.reserve(indices.size() + meshIndices.size());
        indices.insert(indices.end(), meshIndices.buffer(), meshIndices.buffer() + meshIndices.size());
     }
     glBindBuffer(GL_ARRAY_BUFFER, buffers[Buffers::MESH]);

     glBufferData(GL_ARRAY_BUFFER, sizeof(SpineVertex) * vertices.size(), nullptr, GL_STREAM_DRAW);
     glBufferData(GL_ARRAY_BUFFER, sizeof(SpineVertex) * vertices.size(), & vertices[0], GL_STREAM_DRAW);

     glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, buffers[Buffers::INDICES]);
     glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(unsigned short) * indices.size(), nullptr, GL_STREAM_DRAW);
     glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(unsigned short) * indices.size(), & indices[0], GL_STREAM_DRAW);

     glDrawElements(GL_TRIANGLES, indices.size(), GL_UNSIGNED_SHORT, 0);
  }
  glBindVertexArray(0);
   }

VertexAttrib Setup (run once before render)

buffers = new GLuint[2];

  glGenVertexArrays(1, &VAO);
  glGenBuffers(2, buffers);

  glBindVertexArray(VAO);
   
  glBindBuffer(GL_ARRAY_BUFFER, buffers[Buffers::MESH]);
  glVertexAttribPointer(0, 2, GL_FLOAT, GL_FALSE, sizeof(SpineVertex), (void*)0);
  glVertexAttribPointer(1, 2, GL_FLOAT, GL_FALSE, sizeof(SpineVertex), (void *)(2 * sizeof(float)));
  glVertexAttribPointer(2, 4, GL_FLOAT, GL_FALSE, sizeof(SpineVertex), (void *)(4 * sizeof(float)));
  
  glEnableVertexAttribArray(0);
  glEnableVertexAttribArray(1);
  glEnableVertexAttribArray(2);

  glBindVertexArray(0);

Vertex Shader

#version 330 core

layout (location = 0) in vec2 inPos;
layout (location = 1) in vec2 inTexCoord;
layout (location = 2) in vec4 inVertexColor;

uniform mat4 view;
uniform mat4 projection;

out vec2 texCoord;
out vec4 vertexColor;

void main(void)
{
   gl_Position = projection * view * vec4(inPos, 0.0, 1.0);
   texCoord = inTexCoord;
   vertexColor = inVertexColor;
}

Fragment Shader which gets texCoords from vertex stage

#version 330 core

uniform sampler2D textureSampler;

in vec2 texCoord;
in vec4 vertexColor;

out vec4 fragColor;

void main()
{
    vec4 texColor = texture(textureSampler, texCoord);
    fragColor = texColor;//vec4(0,0,1,1);
}

If I put in the color and not the texture color I see the whole mesh playing the animation as a solid color and the wireframe looks fine.

Adding something new I realized. I used a KritaToSpine export script rather than buying photoshop. Strangley the first time I exported it included massive whitespace in the layer exports. I did a whole animation like that and packed it into an atlas and that was failing to map to the given UVs. I tried exporting the same file again and this time there is no whitespace. I will try again with these images but I have to redo everything now. Spine said that it detected the change and would resize the images but that failed spectacularly. I tried exporting with stripped whitespace and without and both failed to place the texture coordinates correctly.

Either way I still don't understand why the export would fail to map the uvs to the packed atlas it outputs.

Nate

MeshAttachment getUVs provides a UV pair for each vertex, normalized within the entire texture. getRegionUVs provides a UV pair for each vertex, normalized within the texture region.

To be sure, are you using SkeletonBinary or SkeletonJson to load the data? Note those use MeshAttachment updateUVs to transform getRegionUVs to getUVs. If you are loading in some other way, make sure you are calling updateUVs after setting or changing the region UVs.

The UVs are usable directly. It may help to look at spine-sfml rendering:
spine-runtimes/spine-sfml.cpp at 3.8

SneakPlatypus

In the block I put up I had taken out the updateUvs call because it did not effect the result but I've had it in there before using getUVs() 99% of the time I've been testing and it has made no impact on what comes from the getUVs() function. I was using a Binary loader but I've used JSON as well and the result was the same.

My confusion is that I am doing exactly what the guide says what you just said and I looked at about 5 runtimes including sfml and they all just use the vertices directly in the same way. It's weird that after calling updateUVs() and then getUVs().

Are you sure this is always the case or does the export need to handled a specific way to make this true. I saw some things talking about whitespace in the source images causing problems which is something I noticed had happened. I'll try it again without the whitespace but I have to redo it first. I've tried almost every combination of export settings I could and the uvs I get after loading with the Binary loader provided in the spine-cpp runtime, then calling updateUVs, then getUVs never line up at all.

Nate

You don't need to call updateUVs since SkeletonJson and SkeletonBinary do so.

There's nothing magical going on with the UVs. They have always been usable as is. There is nothing with exporting that would affect them. They come from the texture region that comes from the atlas, so if anything it could be a problem with the atlas. You can use SkeletonViewer to verify your data can be loaded and rendered.

Maybe it's a problem with how you give the data to the GPU? Nothing stands out as wrong in your code, though I don't see the definition of SpineVertex and it's easy to make mistakes with the GL calls.

SneakPlatypus

I didn't include all of it. its just two glm::vec4 and the sizeof corresponds exactly to 8*sizeof(float). I know it's easy to mess up setting up data but i feel extremely confident the attributes are set correctly. I checked the offsets and strides hard when it first didn't work. That makes sense that updateUVs was called already.

Thanks for confirming though I have been on this for 5 or 6 days so I read through the actual spine code pretty thoroughly and the provided docs and I had the right logic in my head. I'll verify that the atlas is set up correctly because that actually makes a lot of sense for why it could off. If that did not get loaded quite right it could have affected the calculations. I remember looking at the block that does that. I'll step through that and make sure all the data it uses to calculate got set correctly.

I appreciate the help, that narrowed down where to look next. The skeleton viewer is a good idea too I like that as a test of how the export went.

Nate

Best of luck! Let us know how it turned out. 🙂

SneakPlatypus

I fixed it now. It was a one line error in the function that loaded the texture in the first place. Thanks for confirming the other stuff was right it let me hone in on where the problem actually was hiding. Besides that silliness it was surprisingly easy to pull it all in and I like how easy it is to batch all these meshes into one buffer when they share a texture and shader.