Softbody with no bones on a rigibodycontroller

[ieltoro]

Hi. using rigibody to move characters around thats in a ball form.
Can you use the softbody without having bones on a rigibody controller? I just want the nice softbody feeling you get when using your softbody but be able to use rigibody controller without having bones (only way I made it work atm). Right now the character glitches out and flies away.
Been trying having the solver and rigibody as a parent, but then the softbody lives its own life and dosnt follow the rigibody parent.

The characterobject uses skinned mesh

[josemendez]

Hi. using rigibody to move characters around thats in a ball form.
Can you use the softbody without having bones on a rigibody controller? I just want the nice softbody feeling you get when using your softbody but be able to use rigibody controller without having bones (only way I made it work atm).

Hi!

Most rigidbody setups don't have bones (unless you're using an existing skeleton). See the "BallPool" sample scene, or the "RubberDragon" one.

What do you mean by a "rigidbody controller"? Do you mean a rigidbody-based character controller? If so, you can't have an object be a rigidbody and a softbody at the same time for obvious reasons: a body is either rigid or soft, can't be both at once. A softbody is just like a rigidbody, but "soft": it has its own mass/inertia tensor, its own linear/angular velocities, its own gravity, etc.

If you want to build a character controller on top of a softbody, you can do so in a way similar to what you'd do with a rigidbody: softbodies also have AddForce/AddTorque methods, you can query their position, etc. You can see the "ObstacleCourse" sample scene for a simple softbody controller example.

Right now the character glitches out and flies away.
Been trying having the solver and rigibody as a parent, but then the softbody lives its own life and dosnt follow the rigibody parent.

Do you mean having the rigidbody as a parent of the solver? this doesn't make much sense, and is similar to parenting a rigidbody to another rigidbody: the object will be simulated in the space defined by its parent object, which means gravity will be applied to it twice (its parent object falls, then the object falls inside its parent object).

kind regards,

[ieltoro]

Oki thanks for the clarification.

Using server aut movement that takes rigibody values (vel and angVel) to reconcile, so hoped to be able in someway just make the softbody work in my rigibody system by just following and simulate the collisions visually (rig and soft are not in the same layer and cant collide).

[josemendez]

Oki thanks for the clarification.

Using server aut movement that takes rigibody values (vel and angVel) to reconcile, so hoped to be able in someway just make the softbody work in my rigibody system by just following and simulate the collisions visually (rig and soft are not in the same layer and cant collide).

I don’t think you can do it that way, because softbodies are not “rigidbodies with wiggly vertices”: regardless of how you discretize it (aka, how you chop it up into pieces), every bit of a softbody has its own angular and linear velocities, as well as its own mass and inertia tensor. Different parts of the softbody can move in completely different directions, and mass might not be evenly distributed on its volume (varying density). As a result, the shape of a deformed softbody may not look at all similar to its “rest” or “undeformed” shape.

There’s many different discretization methods for a softbody: cells, tetrahedra, particles…Obi uses particles, each particle in the softbody can be treated like a small rigidbody to some extent. What you can do is sync individual particle positions/velocities instead, see: http://obi.virtualmethodstudio.com/manua...icles.html

This does of course mean syncing a lot more data than you need for a single rigidbody.

In case all you need is the “rigidbody with wiggly vertices” approach, something that behaves like a rigidbody for all intents and purposes but appears to wiggle a bit upon collision, a better choice may be a vertex deformer like VertExmotion (I’m not related to its creator in any way): https://assetstore.unity.com/packages/to...tion-23930

Kind regards,