PaperSkeleton

Renders Godot's 2D skeletal meshes into 3D skeletal meshes. Perfect for 2.5D games. · By BunkWire2X8

Add to collection

Godot addon Community Devlog

PaperSkeleton community

Bone attachements and misc feedback.

A topic by Gokigenyou created Mar 28, 2025 Views: 142 Replies: 9

Viewing posts 1 to 2

Gokigenyou198 days ago (1 edit)

Hi, thanks for a great addon! It was just what I needed and easy to set up. I had used the old fashioned method of using a 2d skeleton in a viewport and rendering that to a Sprite3D and switching over to this addon was as smooth as I´d hoped.

Small thing first, compared to my original 2d polygons, the new paperskeleton polygons were tinted white, this could be solved by adding the 'source_color' hint to auto_albedo_texture in the relevant shader include.

And secondly, and I know I could work around some of this using 2d polygons, but I need to attach arbitrary nodes to the skeleton bones. Think weapons and other items held in the hands and also just knowing the global position of for instance the hands to eg. spawn projectiles from them.

What I´ve tried to do is to use BoneAttachment3Ds attached to the generated bones and this kinda works. I use a code snippet like this: 'return _skeleton_3d.global_position + (r_hand_bone_attachment.global_position / 100.0)' to convert the position of the bone attachment to something that works in global space. But, as characters move around, this position is not stable relative the polygon art.

Obviously I realize that I am doing a bit of reverse engineering here and something unintended, so I though I would ask if you know of a better way too accomplish what I am trying to do?

Thanks in advance for any help!

BunkWire2X8Developer197 days ago (1 edit)

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

Gokigenyou197 days ago

Thanks! The update solved my issues.

BunkWire2X8Developer169 days ago (1 edit)

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

Gokigenyou169 days ago

Cool! I will check it out.

Gokigenyou158 days ago

Finally got around to implement 1.2. In summary, it works without any issues and greatly simplifies things for me. :)

BunkWire2X8Developer158 days ago

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.

Gokigenyou156 days ago

I´ve updated to 1.3a now and I have a couple of bugs/issues that were not present in 1.2. They may be related to my implementation but they showed up in 1.3 and reverting to 1.2 fixes them. With the exception of adding to the complex shader I have not tweaked any of the addon files.

1 - When flipping the model, by setting the flip_model var to true, the bone attachments get rotated along the x axis 90 degrees making the objects point towards the camera. It looks good again flipped back. Apparent in the editor. It also breaks the billboarding of the bone attachement, moving the camera around the bone attachment stays in the same 3d position rather than following the model around as the camera moves.

2 - Polygons that are supposed to be hidden are visible during play, I cannot replicate this in the editor. I am 'dressing' up my models like literal paperdolls with several layers of pylogons and I set unused pylogons to not be visible.

It works as intended when they are intended to be visible, but turning visibility off seems to not be respected, or rather, the initial state of visibility seems to not be respected. Whether set by code running in ready setting them to the correct values or turning off the visibility through the inspector beforehand. The issue only seems to happen upon loading and initializing the paperskeleton. Later when changes happen during play, updating the visibility still seems to work.

Thanks in advance for any help or insight you may provide.

BunkWire2X8Developer155 days ago (1 edit)

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.

Gokigenyou155 days ago

Thanks for the quick update! This seems to fix all my immediate issues, I will keep you updated if I find anything else. :)

Great work so far!