Hello, I realize that more bones = less performance as there is always overhead, but I was hoping to get the opinion of one of the developers.

I'll try to keep it simple.

I have a bone in the skeleton, we'll call A.
I move A around in runtime code, but I want to restrict the movement within a rectangle.
I create 4 bones in the editor that envelop the space it can move.
In the code during setup I can cache and calculate the bounds to restrict movement.

Is this unadvisable?

I understand transform constraints and IK constraints can achieve similar results, but they are less flexible.

Thank you for any input.

Related Discussions
...

Using bones as reference points in runtime code to restrict movement within a rectangle is a feasible approach. While it is true that more bones can lead to increased overhead, the impact on performance is generally minimal unless you have a very complex skeleton or a large number of bones. Using bones to define the boundaries for movement can provide a flexible solution, especially if you need to adjust these boundaries dynamically at runtime. However, it's important to test the performance impact in your specific use case to ensure it meets your needs. Constraints like transform and IK constraints are indeed alternatives, but they might not offer the same level of flexibility as using bones directly for this purpose.

  • Nate

  • Post #3

The runtime cost for a bone is quite small. It's unlikely to be a bottleneck to have a few more bones.

You would only need 2 bones to define the corners of a rectangle.

Another option could be to use 2 point attachments. They have only a position and rotation, so are lighter to compute the world position. You would ignore rotation (which isn't used to compute the position anyway).

Another option is to use a mesh or region attachment. A mesh would allow you to have a polygon instead of a rectangle. In the editor you could use a translucent image. Don't render the attachment, just compute its world vertices and use them for movement restriction.

Another option is to just hardcode the world coordinates of your rectangle in your code, if it's not dynamic. This is the most efficient way, since you don't need to compute local to world coordinates.

You could use event values as a way to get a value you define in the editor to your runtime code. You don't need to ever key the events, just find each event and get out its float value. Eg, 4 events with world coordinates: x1, y1, x2, y2. ctrl+shift+R to better visualize world coordinates.

If needed, you could create your own constraint at runtime. This is more involved (need to modify Skeleton updateCache) but would allow you to restrict the bone position in the middle of the draw order.

Thanks for the response Nate.
I really like the event values, pretty clever.
Does adding bones to a unused skin make them even more lightweight?
Although I would likely have to manually call UpdateWorldTransform or something, but I'm not sure if that would have an effect as the skin is not active, but was curious if it would just force it anyways.
Was just thinking it would allow me to define a bone that I could use and update on a as needed basis.

  • Nate

  • Post #5

The event idea is OK, just a bit of a bummer to need 1 event per value. We've wanted to add general purpose name/value pair annotations for a long time.

Bones in a skin that isn't active won't affect performance, but they won't be computed for you either, so it doesn't really help. If you change the bones in a skin, you need to call Skeleton updateCache, and the sorting that does is a little expensive.