Feedback Solver outside of hierarchy

[Jawsarn]

I've bumped into this few times now. And for purpose of using the obi simulation for only visual purposes, the limitation of parent solver is a big annoyance.
I wish we could have a script on an actor that references and links it to a solver (limiting it to world space if required). Thus making it easy not having the hierarchy dependent on what framework used for displaying visuals.

[josemendez]

I wish we could have a script on an actor that references and links it to a solver (limiting it to world space if required). Thus making it easy not having the hierarchy dependent on what framework used for displaying visuals.

Hi!

This is how Obi 1.0 worked, we quickly left this design behind as it's a never-ending source of trouble.

By allowing actors to reference any solver in the scene, actor transforms cannot be assumed to be under the solver in the hierarchy (the solver might actually be a sibling of the actor, or even a child) so this requires multiple code paths that transform all simulation data differently depending on each specific case.

Inertial forces don't work in the sibling or child solver cases because the solver may move independently from the actor, and in these cases applying inertia doesn't make sense. This makes it fairly easy to inadvertently set things up incorrectly (for instance, by mixing actors that are children and parents of the solver in the same simulation. Or, by adding an actor to a solver, reparenting the actor somewhere else and forgetting to call the appropriate code to signal the change) and is a constant source of user error.

We had error messages/info globes all over the place to try and steer users away from incorrect use cases, but it was clunky to say the least. To get rid of all these issues, we took note of how Unity solves the same problem in many of its systems: Canvases are required to be parents of UI elements, Animators are required to be parents of the bone hierarchy, IK Managers must be parents of IK targets, etc.

In our case, forcing the solver to be up the actor's hierarchy (at any nesting level, doesn't have to be an immediate parent) got rid of the 3 different code paths, got rid of all the edge case transforms, allowed inertial forces to always work properly, and made it impossible to set things up incorrectly: an actor is either managed by a solver or it isn't. Reparenting the actor automatically swaps solvers both in-editor and in scripts, so API complexity is also greatly reduced.

I know the "let me specify an arbitrary solver transform for each actor" desire is strong, but we've been there before and it's certainly not a good place.

kind regards,

[Jawsarn]

Thank you for the detailed explenation.

Would it be possibility toggle to have the simulation in global/world space for a solver instead of local? Thus moving the solver would not affect the simulation, which in turns means inertia force are not allowed.

The case I'm looking at is creating a rope attached to a stick at some point in the game. Moving the stick is part of gameplay logic, but the visual should naturally follow as a dangling rope. Having it part of same hierarchy would mean the whole simulation moves. The option I'm looking at is having to spawn the Obi Solver with Rope as a separate object and have setup attachment logic.

Best regards,

[josemendez]

Thank you for the detailed explenation.

Would it be possibility toggle to have the simulation in global/world space for a solver instead of local? Thus moving the solver would not affect the simulation, which in turns means inertia force are not allowed.

The case I'm looking at is creating a rope attached to a stick at some point in the game. Moving the stick is part of gameplay logic, but the visual should naturally follow as a dangling rope. Having it part of same hierarchy would mean the whole simulation moves. The option I'm looking at is having to spawn the Obi Solver with Rope as a separate object and have setup attachment logic.

Best regards,

Hi,

I believe inertial forces are precisely what you’re looking for. You can control the amount of solver linear/angular inertia that’s transferred to the actors using the world inertia scale parameters in the solver. This will cause the rope to be left behind when the solver starts moving, and for it to continue moving when the solver stops moving.

Kind regards,

[Jawsarn]

Hi,

I believe inertial forces are precisely what you’re looking for. You can control the amount of solver linear/angular inertia that’s transferred to the actors using the world inertia scale parameters in the solver. This will cause the rope to be left behind when the solver starts moving, and for it to continue moving when the solver stops moving.

Kind regards,

Thank you once again. You are correct. Setting it to 100% does exactly what I want. For some reason I thought it would induce double the issue I was experiencing.