To obtain the bounding box and render attachments correctly using the Spine runtime with SFML, you need to ensure that you are correctly handling the world vertices for each attachment type. In your code, you are already computing the world vertices for MeshAttachment types, but you should also handle RegionAttachment types similarly. For RegionAttachment, you can use spRegionAttachment_computeWorldVertices to get the world vertices.

Additionally, ensure that you are updating the world transform of the skeleton after setting the position to center the skeleton correctly. This involves calling Skeleton_updateWorldTransform after setting the skeleton's x and y properties.

Here's a brief outline of what you should do:

1. Check for both RegionAttachment and MeshAttachment types in your loop.
2. Use the appropriate function to compute world vertices for each attachment type.
3. Update the skeleton's world transform after setting its position.

By following these steps, you should be able to correctly calculate the bounding box and render the attachments as expected.

ETO I hope to obtain the bounding box with image attachments and render all attachments correctly.

This terminology is a bit odd, maybe by "image attachments" you mean both region and mesh attachments?

ETO SkeletonBounds* bounds = SkeletonBounds_create();

SkeletonBounds does this:

Collects each visible BoundingBoxAttachment and computes the world vertices for its polygon. The polygon vertices are provided along with convenience methods for doing hit detection.

It only uses bounding box attachments, not region, mesh, or other types of attachments. If you want to compute the AABB for all attachments, you don't need SkeletonBounds.

Otherwise your approach is good: compute the world vertices for each attachment and compute the maximal bounds. Note that is almost identical to rendering, so you can copy/paste the SFML rendering code for the spine-sfml runtime, remove the rendering, and put in computing the maximal bounds.

if (!mesh->rendererObject) continue;

Since you aren't rendering, you aren't using the rendererObject and you don't need this line.

printf("No RegionAttachment found!\n");

Your code checks for mesh attachments, not region attachments, so this message is confusing. You can add this code:

if (attachment->type == SP_ATTACHMENT_REGION) {
    spRegionAttachment* region = (spRegionAttachment*)attachment;
    hasAttachment = true;
    
    float vertices[8];
    spRegionAttachment_computeWorldVertices(region, slot->bone, vertices, 0, 2);
    
    for (int v = 0; v < 8; v += 2) {
        float x = vertices[v];
        float y = vertices[v + 1];
        if (x < minX) minX = x;
        if (y < minY) minY = y;
        if (x > maxX) maxX = x;
        if (y > maxY) maxY = y;
    }
}

However, it may be better to copy/paste from the spine-sfml renderer.

drawable->state->tracks[0]->trackTime = 0;

This is right to choose a frame to pose, but if you have physics your skeleton will see the setup pose, then suddenly the animation pose, causing physics to jump. If you care about physics, you need to pose your skeleton repeatedly from 0 to a particular trackTime using a time step like 16ms.

if (!attachment) continue;

This is OK, but you may want to check if the attachment is invisible:

if (!attachment || slot->color.a == 0) continue;

It can be seen that I hoped the image area would actually be centered, but some Meshes failed to do so.

Sorry, I don't understand what you mean here.

It can be seen here that attachments that work properly through the official skeletonViewer do not work properly in my code.

I see the difference, but it's not clear why. Are you able to render it correctly in a similar way but to the screen? Is it only regions or only meshes that don't render?

ETO These four pictures should be able to correspond to the problems corresponding to the bounding box.

OK but... what am I looking at? What are the red boxes? What are the problems?

In most cases, SP_ATTACHMENT_MESH can always obtain relatively accurate four extremities, while SP_ATTACHMENT_REGION does not show reference value in practice.

Maybe the skeleton has no region attachments? The 4 vertices for a region attachment will work for computing the AABB just like the vertices of a mesh.

It means that I hope to calculate the not completely transparent parts as bounding boxes

The vertices will give you an AABB based on the images drawn. It doesn't account for the parts of the images that are blank. Is that the problem you are having? That the AABB from vertices still has blank space? The only way to know that would be to look at the pixel values. For example, render to a buffer as you have done, then look at pixel values. This is often called "whitespace stripping".

drawable->state->tracks[0]->trackTime = 16;

Note this is in seconds. 16ms is 0.016.

As mentioned earlier, SP_ATTACHMENT_MESH is more meaningful for my border statistics.

Both regions and meshes are important. A skeleton could be entirely regions.

It's only partially missing, so that I can't accurately identify the cause.It has only one frame, so I feel at a loss here.

Sorry, your posts don't really explain your problems. I am not familiar with your skeletons. I don't know what the red boxes are trying to tell me. I don't know what your end goal is. I don't know what problems you are having trying to get there. Please concisely but thoroughly explain these key concepts:
1) what you want to do and why,
2) what you tried,
3) what you expected, and
4) what happened instead.

But does 16ms correspond to 60 frames?

By default Spine uses 30 FPS in the editor. At runtime it is always in seconds. One frame is 1 / 30 = 0.033 seconds (33ms).

You suggested I take one frame, but in fact, my animation only has the zeroth frame.

Then trackTime = 0 is fine. You may want to calculate the maximal bounds for a specific frame later in the animation, or for an entire animation. spine-player does an entire animation:
EsotericSoftware/spine-runtimesblob/4.2/spine-ts/spine-player/src/Player.ts#L793-L819
There's no Skeleton getBounds in spine-sfml/spine-c, but you're doing the similar. You can see it in TypeScript:
EsotericSoftware/spine-runtimesblob/4.2/spine-ts/spine-core/src/Skeleton.ts#L628
This does more than your code, eg properly applying clipping.

I hope to preview the image in the center.

There's technically many solutions to this. Using bounds from the vertices centers it based on what is drawn, but visually blank parts of the region and mesh attachments may make it look off center. The only way to fix that is draw, then inspect the pixels.

I hope to render the image correctly.
The rendering code above me caused some images to be missing.

If you can draw to the screen correctly, it should draw to your texture correctly. Get rendering to the screen working first.

I attempted to obtain bounding boxes using SP_ATTACHMENT_REGION and SP_ATTACHMENT_MESH, but the effect was not good.

Done correctly, it should give you the AABB of what is drawn. That you are drawing images with lots of blank space is a separate problem.

If you don't want to use what is drawn for centering, then what is "centered" can be subjective. For example, if a character has a long spear, it may extend far to one side. Even after you remove whitespace, the character will be off to one side. Maybe that is good enough.

You might consider a marker in each skeleton to define the center of the character. Or you could use 0 worldX.

What is this being done for? If you are going to pack the images into an atlas, you don't need to worry about whitespace at all, you can let texture packing do it. If you just want to get it done and aren't doing it at runtime, you could pack the images and the atlas data can tell you how many whitespace pixels were cut off.

The monotone chain algorithm (aka Andrew's algorithm) is for computing a convex hull. You can reference an efficient, non-allocating version of it that I wrote here. How do you use this algorithm? Do you apply it to the pixels in each mesh? This seems quite complicated. The easiest approach is to render to an in-memory buffer then read the pixels from each edge. Reduce the size of the image for each row or column that is fully transparent. When you encounter a pixel that is not fully transparent, stop. Code for that for texture packing can be seen here. Of course you will need to adapt to your game toolkit API. Since this involves rendering, you are dependent on the game toolkit API. It's not functionality the Spine Runtimes provide, so changing runtimes won't help much. Changing game toolkits may help. Doing it with libgdx would be easy, but you may not want your tool to require or package Java.

For your rendering problem, as I mentioned before: get it working by rendering to the screen first. Once that works, then render to a texture. The rendering code path should be the same, but it's easier to work on getting the screen rendering correct. It's not possible to give more help from only screenshots of incorrect rendering. I can only guess at what is wrong, but it seems as if some batched geometry was not flushed at the end of your rendering.

Your convexHull function looks good!

I traversed all the pixels.

I still contend the fastest and simplest solution is:

1. Compute the AABB using mesh and region vertices.
2. Create a buffer using that AABB size and render the skeleton to it.
3. Discard fully transparent rows/columns at the 4 edges. You now have the tightly fitting AABB.

If you know the maximum size of your skeletons, you can skip step 1 and in step 2 just create a large buffer, eg 4096 x 4096.

You can see an example here. That code poses a skeleton with an animation on frame 0 (using the timeline API, effectively the same as your use of AnimationState), then renders it to a buffer -- very similar to what you want (but in Java with libgdx). Next you'd read the pixels to discard fully transparent rows/columns at the edges (like I showed in the texture packer in my earlier post). Game toolkits like libgdx are so much nicer than those that force you to use a scene graph.

Your code that iterates slots should be based on the spine-sfml rendering code, here:
EsotericSoftware/spine-runtimesblob/4db43da67888eb71ed706046cb13735d96286048/spine-sfml/c/src/spine/spine-sfml.cpp#L159-L317

Copy paste that, then remove the parts that do rendering. In the for (int j = 0; j < indicesCount; ++j) { loop use the vertices to find the AABB. The reason to do this is because you must do exactly what the spine-sfml rendering code does, except you calculate AABB instead of rendering. If you do something else, then your AABB may not match rendering. For example, it appears your code doesn't apply clipping correctly.

That code does not use Skeleton_getAttachmentForSlotName and you should not need it. By default the skeleton has the setup pose attachments visible. You don't need to set attachment visibility. The spine-sfml renderer does not. The FboTest linked above does not. You should not change the slot color either.

I tried to output the duration of the animation, and unsurprisingly, the result was 0.000000.

0 is correct if the animation has only keys on frame 0.

As you said, I have rendered it on the screen. In fact, there is no difference between it and when I output it to PNG

OK, good -- it will be easier to debug when rendering to the screen. Are you rendering directly to the screen though? The code you've show seems to be rendering to the texture. Don't render to your texture and then render the texture to the screen. Render directly to the screen to ensure your rendering code is correct, only then make it more complex by rendering to a texture.

Render directly to the screen, like the example:

sf::RenderWindow window(...);
SkeletonDrawable *drawable = ...;
...
window.clear();
window.draw(*drawable);
window.display();

Is there any extra processing in the skeletonViewer rendering process

No extra processing should be needed. The SkeletonViewer code is available. The FboTest above is simpler. You just load the skeleton and render it.

I ran through all my model libraries and found that there was still model return 4 but no return 3. This indicates that the model calculated the bounding box, but all of them were set to transparent.

This could be correct. A skeleton could have all attachments hidden in the setup pose, eg maybe they are only shown in animations. Or, when a skeleton uses skins it is common to not have any attachments at all in the default skin. When shown in Skeleton Viewer, you won't see anything until you choose a skin.

At this point you should probably start with the spine-sfml example code. Run it and see spineboy renders. Change the skeleton to one of yours, see it renders correctly. Modify the example to render to a texture, then render the texture to the screen to see rendering was correct. If you need an AABB to render to a texture, base it on the spine-sfml rendering code. Finally, convert the texture to an image and remove fully transparent rows/columns from the 4 edges.

Give that a try (don't skip any steps!) and if you still have trouble, post or email your full code. contact@esotericsoftware.com

We got your email, thanks! We'll take a look soon. It should render using the 3.8.99 spine-sfml, as it does in the 3.8.99 Skeleton Viewer.

Note your skeleton data is 3.8.99, so it's important you use and base your code on the 3.8.99 spine-sfml.

The latest in the 3.8 branch is compatible with exports from 3.8.xx editor versions, so it sounds like you have the right runtime code.

Cool, that is a neat solution!

Hopefully on Monday we'll solve your rendering.