itch.io

Before I get around to that, I should inform you that the latest update (version 1.4a) has a bug-fix that fixes incorrect flip updates that were introduced in version 1.4, as mentioned in the relevant devlog. In hindsight, I think I should have more explicitly informed you of that.

Re-added some accidentally removed lines of code that updated the current flip state in PaperSkeleton, which likely would've introduced problems for PaperBoneAttachment3D's flipping logic if gone unchecked.

Did you update to 1.4a? If not, can you download it and use it to see if the update already fixes your problem? Just making sure, as itch.io's statistic tell me that no one has downloaded it thus far, though I don't know how frequently that counter updates.

Also, sorry for not responding too quickly. For some reason, itch.io's notifications seem to lag behind a bit for me, only popping up hours later.

Thanks for pointing that out to me. I've now made another update that should fix that issue, alongside some other small fixes and changes.

Thank you very much for your feedback. I've implemented fixes that I believe should solve those two issues.

First off, the bone attachments. This was due to a new implementation I added to improve parity. You see, the `flip_model` property just inverts the scale on the x-axis. This is fine, but seeing as how everything else flips by, well, flipping, I've decided to introduce new code to make it so that bone attachments would rotate instead of having their x-scale inverted. Unfortunately, my implementation introduced a few issues:

• Failing to consider that some might actually want their models to be flipped for varying reasons.
• I based the transform calculations off the base PaperSkeleton's transform and not its `billboard` node.
• My math also had some other mistakes, with the rotation actually being significantly off.

These all should be fixed in the new update. There's an `invert_x_scale_when_flipped` property implemented, as well as fixes for the other two issues.

Secondly, the visibility bug. Very simple fix really. You see, I initially had the PaperSkeleton node constantly check if the Polygon2Ds' visibility were toggled. Instead, now I have it change during the `NOTIFICATION_VISIBILITY_CHANGED` notification on each PaperPolygon2D. Unfortunately, I neglected to initially define this visibility upon instantiation, of which it now does, so consider the bug fixed. Also, I tweaked it so that it references `is_visible_in_tree()` instead of `visible`, so that its visibility can be toggled as a group when put underneath a child of a node that's not visible.

If there's still something wrong with any of these feature, please let me know.

That's great to hear, albeit with slightly humorous timing, considering that I just released version 1.3 haha.

There's actually a bit of a significant oversight with my implementation of material caching in 1.2 (realized that it cause would multiple instances of the same PaperSkeleton scene to share the same material, making things like independent texture changes between them impossible), of which I completely rolled back in 1.3, so I recommend upgrading to that whenever you can.

I should note that I just added a PaperBoneAttachment3D node in the latest 1.2 update, if that suits your needs better.

Ah! Very good eye about the tinted white thing. I mainly was testing this in the compatibility renderer for the web demo, and I assumed that the white tint in the forward renderer stuff was just due to lighting changes in different renderer modes, so thank you very much for telling me this. I do find this specific difference here to be rather odd though.

Secondly, that's a tricky task. Firstly, the Skeleton3D and its bones are made dynamically at runtime, so you shouldn't be able to attach a bone attachment in the editor I don't think. You should be able to do something like that via script, which seems to be what you're trying to do, though as your code highlights, you'd need to essentially shrink it by 100 due to the method that I've shrunk the PaperSkeleton meshes, which is just shrinking the meshes after they've been created. I didn't have the foresight to consider that people would need to actually retrieve the 3D bone positions in certain scenarios, which, in actual world space, outputs as multiplied by 100.

While I could recommend workarounds, I want this addon's usage to be as accessible as possible, so I've released an update that I hope should resolve your issue. Here's a devlog regarding it:
https://bunkwire2x8.itch.io/paperskeleton/devlog/914403/11b-update-shader-and-bo...