Nate The area in the red box is the four-point range I obtained, which is determined by the SP_ATTACHMENT_REGION or SP_ATTACHMENT_MESH in the upper left corner.

Nate Maybe the skeleton has no region attachments?

In my opinion, this understanding is correct. This is indeed the reason for the fourth picture. I think I should count both SP_ATTACHMENT_REGION and SP_ATTACHMENT_MESH simultaneously. Theoretically, this is correct, but the final effect is not as good as only counting SP_ATTACHMENT_MESH (most models are similar to the comparison of Figure 1 and Figure 2, and Figure 3 and Figure 4).

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

I quite agree with this. It's just that using only SP_ATTACHMENT_MESH currently performs better. Of course, if the problem is eventually solved, it must be SP_ATTACHMENT_REGION and SP_ATTACHMENT_MESH.

Nate Is that the problem you are having?

This is almost the problem I have encountered. This is the difference in location when I use the runtime and skeletonViewer.

Nate "whitespace stripping".

I will consider using this method, but because of this problem here (the fifth picture).

ETO Because as shown in the figure, even the box containing the content of the picture is not necessarily attached to the image.

I think even if it is achieved, it is not necessarily possible to be "strictly centered".

ETO If the runtime of spine cannot achieve this, I might consider first obtaining the maximum boundaries obtained from SP_ATTACHMENT_REGION and SP_ATTACHMENT_MESH to obtain the PNG, and then processing the PNG in other ways to make it finally centered.

So I will try this method first, because in any case, it should be necessary for the above situation.

Nate Note this is in seconds. 16ms is .

This is my mistake. Thank you for your correction. But does 16ms correspond to 60 frames? You suggested I take one frame, but in fact, my animation only has the zeroth frame. There might be no difference between going through one frame and going through 16*60. I once tried to calculate the duration of the animation to reach the last frame, but there was no improvement either.

Nate what you want to do and why,

I hope to preview the image in the center.
I hope to render the image correctly.

Nate what you tried,
Nate what happened instead.

I attempted to obtain bounding boxes using SP_ATTACHMENT_REGION and SP_ATTACHMENT_MESH, but the effect was not good.
The rendering code above me caused some images to be missing.

This is the problem I encountered. I'm sorry again for my ambiguous expression. ≦(._.)≧

Nate I examined the specific implementation of Skeleton and realized that there was no essential difference from my traversal of SP_ATTACHMENT_REGION and SP_ATTACHMENT_MESH. Therefore, I realized that this work might have gone beyond the scope of spine-runtime. So I adopted the simple Andrew's Monotone Chain algorithm to fulfill my requirements, and it did. (Perhaps I should have done this long ago. ( 。ớ ₃ờ)ھ)

So the first problem has been solved at a certain stage, while there is no idea about the second one.

Nate Andrew's Monotone Chain. Here I have used the following more common writing method. I analyzed your writing method and used the quick sort algorithm, while I used std::sort, which combines quick sort and heap sort. The time complexity of both is the same O(n log n). Compared with your maintenance of the index, I don't have the corresponding requirements, so my constant factor is smaller. Therefore, I think it is efficient enough.
//（Andrew's Monotone Chain）
static int cross(const sf::Vector2i& O, const sf::Vector2i& A, const sf::Vector2i& B) {
return (A.x - O.x) * (B.y - O.y) - (A.y - O.y) * (B.x - O.x);
}
static std::vector<sf::Vector2i> convexHull(std::vector<sf::Vector2i> P) {
int n = P.size(), k = 0;
if (n <= 1) return P;
std::sort(P.begin(), P.end(), [](auto& a, auto& b) {
return a.x < b.x || (a.x == b.x && a.y < b.y);
});
std::vector<sf::Vector2i> H(2 * n);
for (int i = 0; i < n; ++i) {
while (k >= 2 && cross(H[k - 2], H[k - 1], P[i]) <= 0) k--;
H[k++] = P[i];
}
for (int i = n - 2, t = k + 1; i >= 0; --i) {
while (k >= t && cross(H[k - 2], H[k - 1], P[i]) <= 0) k--;
H[k++] = P[i];
}
H.resize(k - 1);
return H;
}
Regarding the acquisition of the point set, as you said, I don't have a very good method. I traversed all the pixels. This is indeed a bottleneck. But as you said, I don't want to introduce more things, and the time consumption is actually within the acceptable range. Overall, this has met my needs. Thank you for your suggestion.

Regarding the rendering issue, I have made more attempts below and should be able to provide more details.

This is the complete process I attempted. Meanwhile, I tried to output the duration of the animation, and unsurprisingly, the result was 0.000000.

Next, I will talk about the differences under different conditions.

The difference between the upper left corner and the lower left corner lies in whether this is enabled or not. I found that if the attachment is not explicitly set, even if I do not set an exit condition when counting the bounding box, the unrendered attachments will not be recorded.

for (int i = 0; i < skeleton->slotsCount; ++i) {
spSlot* slot = skeleton->drawOrder[i];
if (!slot->attachment && slot->data->attachmentName) {
spAttachment* att = Skeleton_getAttachmentForSlotName(skeleton, slot->data->name, slot->data->attachmentName);
if (att) slot->attachment = att;
From the difference between the upper left and the right, I learned that not all attachments need to be forcibly opened. There might be a judgment condition here, and I don't know how to handle it.

Then let's look at another example. The layout is consistent with the previous one, but we can see that after enabling all attachments, there is no difference. At the same time, just like above, it is not included in the statistics of the bounding box.

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 (always as an example in the upper left corner).

Is there any extra processing in the skeletonViewer rendering process, the latter example still has no idea for me.

Nate 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.

For this issue, I only performed such rendering once throughout the full text and there was no cross-thread operation. I don't think it matters much here. According to the previous examples, the location where the error occurred should be at or before the earlier traversal.

Nate

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. Then I made an attempt based on this.

However, what emerged were the elements that should have been properly hidden, while the elements that should have been drawn still did not appear. This might provide some clues.

Nate

Nate start with the spine-sfml example code. Run it and see spineboy renders. Change the skeleton to one of yours, see it renders correctly.

I did do so (Based on this), but the result I got was that spineboy was completely normal, while this part of my model did not display properly.

Nate Render directly to the screen, like the example:

The window in the upper left corner above me is done this way. I explained it later, but it might not be conspicuous enough.

Nate Or, when a skeleton uses skins it is common to not have any attachments at all in the default skin.

I have considered this aspect, but the fact is that my model only has the default skin.

Nate Discard fully transparent rows/columns at the 4 edges

This is indeed a good method. Through some algorithmic techniques, a fitting bounding box can be found efficiently. But in my practice, just like the spear you mentioned above, there is a cigarette placed a bit far away in my model library (the graphic designer is really bad QWQ). So later on, I hope to achieve the "center of gravity" effect. I will design a function to display the more important parts at a slightly central position, so I hope to obtain more information through traversal.

Nate For example, it appears your code doesn't apply clipping correctly

I made the modifications according to the code you provided above. The reason why clipping was not applied earlier is that I didn't find the usage requirements in the model. Since it was mentioned, I'll add it as well.

I don't know if my understanding is correct. I made such a modification, but there was no improvement shown in the end.

I just sent my code, which includes example.cpp and main.cpp. The former is a simplified test based on the sample code, and the latter is the code I am currently using. It also includes three groups of problematic models. These three should almost cover all the situations I have encountered.

Nate I noticed that you are somewhat interested in my implementation of the bounding box. This is my final implementation. Although the annotations are all in Chinese, in implementation, it is simply to obtain the center of gravity by dividing the total torque by the total mass, and then move the closely surrounding side to center the center of gravity. This does indeed require traversal. (If it is no longer necessary, we can stop discussing the issue in this direction. This has fully met my needs.)

Meanwhile, when I was checking just now, I found that I hadn't implemented your suggestions well before.

Nate Are you rendering directly to the screen though? The code you've show seems to be rendering to the texture.

I just corrected the code.
make window.draw(finalSprite); to window.draw(*drawable);
But in the end, it still failed.

Nate That's great, thank you for your continuous help all along ~ ଘ(੭ˊ꒳​ˋ)੭ ​​​

Nate I have received the relevant push notifications and noticed your fixes for spine-sfml and spine-cpp. Please excuse me for not being able to conduct the test immediately (due to the 12-hour time difference). I checked the newly fixed part and noticed that it corresponded the logic of cpp to c and changed the logical judgment. This also confirmed my previous conjecture. I will perform batch operations on my model library again later to verify if there are any other problems. All in all, thank you for your help!

Nate Thank you very much for your work. With my additions, the functions of this tool of mine have now been fully implemented. I might make more attempts later, but I believe the life cycle of this post has come to an end. Thanks again ♪(· ω ·)ノ