Your convexHull
function looks good!
I traversed all the pixels.
I still contend the fastest and simplest solution is:
- Compute the AABB using mesh and region vertices.
- Create a buffer using that AABB size and render the skeleton to it.
- 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