Change default InitiaForce value on DynamicBoneChain from 2 to -2

[gentlecolts]

Describe the bug?

Dynamic bone chains on avatars, such as hair, ears, etc, can bend towards the direction of controller movement, rather than away from it. This is incorrect, as the chain should be dragged by the motion.

To Reproduce

It seems to be somewhat dependent on exactly how dynamic bones are configured, haven't yet isolated exactly what causes it, but it seems pretty common

Expected behavior

dynamic bone chains attached to avatars should exhibit physically plausible motion in response to player movement, both physical and via controller input

Screenshots

No response

Resonite Version Number

2023.10.13.202

What Platforms does this occur on?

Windows, Linux

What headset if any do you use?

No response

Log Files

n/a

Additional Context

No response

Reporters

zangooseoo

[Frooxius]

You can configure dynamic bones to do this on purpose. It's likely what you're seeing.

Without knowing their configuration we can't tell.

[gentlecolts]

Could you elaborate on how one could configure dynamic bones for this result deliberately? I don't believe any of the times I've seen it have been intentional.

[989onan]

Could you elaborate on how one could configure dynamic bones for this result deliberately? I don't believe any of the times I've seen it have been intentional.

It's called intertia force iirc. It allows you to make it negative or positive which will flip the direction in which it moves

[gentlecolts]

I can definitely reproduce this without touching inertia force. I set up two bone chains last night that exhibit this behavior, it seems imo related to high elasticity, but I can't be sure. Here's some example settings

[989onan]

if your bone's rotated a certain way it will go a different direction by design flipping the inertia force sign to -2 instead of 2 just fixes the issue. I wouldn't be surprised if devs mark this as a "Won't fix" because it has a fix already in there which is the inertia force slider Edit: I mean, you could add a check box for an internal flip of the inertia slider but that seems pointless when it's already there

[gentlecolts]

Could you elaborate on "by design"? I can understand orientation mattering for some types of constraints, but I can't see why that'd matter for how the chain responds to physics, especially since them moving the wrong way has nothing to do with which direction force is being applied.

[989onan]

I don't remember how so I need someone to confirm why this happens, but it depends on a few different factors. though I don't understand why changing one slider is all that bad. now if it were difficult I would be looking for a solution too

[989onan]

I gave up for one of the bugs I reported and wrote Protoflux around it for the simple reason of it being a simpler fix than waiting for a real solution

[gentlecolts]

If it is a bug it should be reported as such even if you have a workaround. I don't feel like I should have to justify this, but in this case it is a clear example of dynamic bone chains, which are meant to represent a physical stiff chain of sorts, not behaving in a phyiscally accurate way and, constraints aside, dynamic bone chain should be simulating points, spatial orientation of the simulated points is irrelevant. Your proposed workaround is unintuitive and will break when the correct behavior is implemented, so it is unacceptable

[989onan]

if you're not willing to use the slider then I cannot help you. If you wanna wait for a solution for many months rather than just slide a slider in the meantime then that's on you Edit: issue is #176

[gentlecolts]

Please understand this is an issue tracker, not a help forum. I appreciate your attempt at providing alternatives, but they do not solve the issue of this ticket

[gameboycjp]

There are sliders change how the bones respond to inertia. They are labeled as such. Also, sometimes there's mismatches between skeletons and meshes, in which case you will need to find a workaround, because fixing or even detecting that automatically is extremely hard. Lastly, there are uses for having negative inertia. In fact, even I've used it. I really don't think this is a bug.

[Electronus]

So did a bit of testing and it seems bone rotation doesn't matter @989onan I did some tests with just a chain of cubes and it works as described.

having your inertia force up means that the chain moves towards the direction of movement when you would expect it to move away.

Now this could be a bug, it could be its just not intuitive but we wont know really until a dev chimes in.

resrec:///U-Electronus97/R-feb7d051-21a3-4fd0-a9e3-c9ef93130daa

here i have made a quick test object where all i have done s increase, but not invert, inertia and inertia force. It also has four "bone" chains to swap through at 0, 90, -90, and 180, degrees on the z axis.

[shiftyscales]

@Frooxius @ProbablePrime - as others indicated, it is related to the InitiaForce being set to a positive value- but I do not believe this issue is not a bug, but rather a tweak- with a goal of having a more intuitive default behaviour for the component.

My recommendation would be to set the default value for the IntertiaForce to -2 instead of 2 when initializing the component. From all my years using this component, I have nearly universally flipped the sign on this value to produce the outcome I expect.

[gentlecolts]

I'm honestly still not entirely convinced that changing the default makes sense as a solution to this issue. For one, intuitively the idea of a negative value for inertial force just...doesn't make sense, that sounds like something that'd create the issue I observed here, not fix it. For two, this change isn't necessary in many cases, for example the bad behavior I observed for this ticket is not present with the default settings for bone chains as of current version.

The easiest way to reproduce this behavior seems to be using a high value for Inertia (note, not inertial force), such as values over 0.5, with significant visibility with values over 0.8. As I was testing for these values, I noticed that at lower values, such as 0.51, bone chains behave correctly initially, but start to push towards the incorrect direction as force (ex from walking in a direction constantly) is applied, however at higher values, chains snap into that incorrect state faster.

I thus believe this to be an incorrect handling of inertia in general, which only becomes evident at higher values

[Frooxius]

I don't think we'd change the default to negative value. It's a valid value for this, but I don't think it's a good default.

The idea is that you don't want your chain movement to be purely dragging, so when you move, it actually moves a bit with it, rather than dragging behind like a piece of rope.

I'm still not sure what the actual underlying issue here is. The dynamic bones are mainly made to look visually good. You can configure them in variety of ways to achieve lots of different types of effects.

The default values were set so it looks mostly good, but the expectation is, if you want something different, you configure it.

I don't see any reason to change the defaults right now for that. It would've helped if there were some videos and comparisons accompanying this, because when describing visuals in text, we each might be imagining a different thing.

[gentlecolts]

I am SINCERELY sorry for how poor my audio quality is at the moment, I don't really have a better option, but hopefully this at least helps

https://mega.nz/file/CMU0xQbC#fbYYrzkaDXN19XnjeJQ5bwyLuiVvZeddQ495E21GdIo

[gentlecolts]

Looked at this a bit more, I really don't think flipping the InertiaForce default value is the right move. I was messing with it a bit and it just seems to make the behavior of inertia less intuitive than it already is. It definitely also seems like the original issue of this ticket arises when Inertia is set to values above .5, but it's not quite exactly above .5, and seems like there's some tolerance above that point before things get weird. This led me to trying leaving InertiaForce set to 1 instead of 2, but that didn't seem to solve the issue either. I really do believe this is an underlying issue in the math used by dynamic bones, but I can't really go further than that without knowing what that math actually is