Posts: 4
Threads: 1
Joined: Dec 2020
Reputation:
0
Hello,
I am currently working on a game where a blob is moving forward constantly and shrinking constantly. I learned that if you decrease the size of the solver, it decreases the size of the simulation space of the softbody and thus decreases the size of the softbody. I am using ObiActor.AddForce() with ForceMode.Force to propel the softbody.
It works great for a second or two, but then something weird happens. The softbody starts slowing way down, then it starts teleporting short distances forwards and backwards, and starts rolling backwards. The scale of the solver is always positive.
Is this a limitation of the asset, or is there a way around this? I tried disabling the shrinking and setting the softbody to decreasing in size by a constant amount every time you press a button. When you press the button, the softbody teleports backwards a bit, then back forwards again and it massively decreases in speed.
Any ideas? Here's a gif of what happens in action:
Posts: 6,300
Threads: 24
Joined: Jun 2017
Reputation:
397
Obi Owner:
07-12-2020, 10:57 AM
(This post was last modified: 07-12-2020, 12:16 PM by josemendez.)
Hi there,
I assume your solver does not move at all. While the solver is shrinking, you're propelling the softbody forward using a force (which is expressed and applied in the solver's local space).
Think about it: the behavior you describe is 100% correct and to be expected. Try picturing what happens when you scale a transform down, and the child transforms are not exactly at the parent's origin: they will get scaled down towards the parent. The same happens with actors inside a solver:
As long as the force you're applying displaces the softbody further away from the solver's origin than the scaling does, the softbody will move forward. At some point though, both displacements will even each other out (as the force is also scaled down with the solver, since it's applied in solver space), and shortly after that, the displacement due to scaling will be larger than the one due to the force:
The result is that the softbody moves forward at first, but progressively decelerates and then begins moving towards the solver's origin.
So this setup does not do what you were expecting. I don't know the details of your use case, though. If you could describe what you're looking for in detail, I would be able to suggest alternatives. The simplest thing that comes to mind is converting your force from world space to solver space before applying it. This way, as the solver gets scaled down, the force will be scaled up and compensate for it.
Posts: 4
Threads: 1
Joined: Dec 2020
Reputation:
0
10-12-2020, 08:51 PM
(This post was last modified: 10-12-2020, 08:53 PM by picross.)
(07-12-2020, 10:57 AM)josemendez Wrote: Hi there,
I assume your solver does not move at all. While the solver is shrinking, you're propelling the softbody forward using a force (which is expressed and applied in the solver's local space).
Think about it: the behavior you describe is 100% correct and to be expected. Try picturing what happens when you scale a transform down, and the child transforms are not exactly at the parent's origin: they will get scaled down towards the parent. The same happens with actors inside a solver:
As long as the force you're applying displaces the softbody further away from the solver's origin than the scaling does, the softbody will move forward. At some point though, both displacements will even each other out (as the force is also scaled down with the solver, since it's applied in solver space), and shortly after that, the displacement due to scaling will be larger than the one due to the force:
The result is that the softbody moves forward at first, but progressively decelerates and then begins moving towards the solver's origin.
So this setup does not do what you were expecting. I don't know the details of your use case, though. If you could describe what you're looking for in detail, I would be able to suggest alternatives. The simplest thing that comes to mind is converting your force from world space to solver space before applying it. This way, as the solver gets scaled down, the force will be scaled up and compensate for it. Thanks so much for the detailed response, it makes a lot of sense.
I like your idea of converting the force from world space to solver space. I'm not quite sure how to approach it, though. Currently, we are applying a force to the softbody in the solver with ObiActor.AddForce and a ForceMode of acceleration:
Code: _softbody.AddForce(Vector3.forward * _acceleration, ForceMode.Acceleration);
_acceleration is just a float set to 3.0f.
Any ideas?
Posts: 6,300
Threads: 24
Joined: Jun 2017
Reputation:
397
Obi Owner:
10-12-2020, 09:31 PM
(This post was last modified: 11-12-2020, 08:26 AM by josemendez.)
(10-12-2020, 08:51 PM)picross Wrote: Thanks so much for the detailed response, it makes a lot of sense.
I like your idea of converting the force from world space to solver space. I'm not quite sure how to approach it, though. Currently, we are applying a force to the softbody in the solver with ObiActor.AddForce and a ForceMode of acceleration:
Code: _softbody.AddForce(Vector3.forward * _acceleration, ForceMode.Acceleration);
_acceleration is just a float set to 3.0f.
Any ideas?
Hi,
The way you transform vectors from world space to local space in Unity is by using: https://docs.unity3d.com/ScriptReference...ector.html
Posts: 4
Threads: 1
Joined: Dec 2020
Reputation:
0
(10-12-2020, 09:31 PM)josemendez Wrote: Hi,
The way you transform vectors from world space to local space in Unity is by using: https://docs.unity3d.com/ScriptReference...ector.html Alright, so I tried doing this and scaling the force by the size to different degrees, but it seems to always exhibit the same behavior. For example, I tried squaring the force vector I plugged in and it still started reversing at around the same time (but at faster speeds).
This is what I changed the code to:
Code: _softbody.AddForce(_softbody.solver.transform.InverseTransformVector(Vector3.forward * _acceleration), ForceMode.Acceleration);
It is definitely scaling the vector, but the same behavior seems to happen.
This is the behavior without scaling the force vector based on transform scale:
And this is what happens when using the scaled force vector with the code above:
Should I be manipulating this force vector in some other way, or should I take another approach altogether?
Thanks again for the help!
Posts: 4
Threads: 1
Joined: Dec 2020
Reputation:
0
(13-12-2020, 02:20 AM)picross Wrote: Alright, so I tried doing this and scaling the force by the size to different degrees, but it seems to always exhibit the same behavior. For example, I tried squaring the force vector I plugged in and it still started reversing at around the same time (but at faster speeds).
This is what I changed the code to:
Code: _softbody.AddForce(_softbody.solver.transform.InverseTransformVector(Vector3.forward * _acceleration), ForceMode.Acceleration);
It is definitely scaling the vector, but the same behavior seems to happen.
This is the behavior without scaling the force vector based on transform scale:
And this is what happens when using the scaled force vector with the code above:
Should I be manipulating this force vector in some other way, or should I take another approach altogether?
Thanks again for the help! It appears we were able to solve most of our problems by moving the tube towards the player instead of moving the player, thus circumventing all the problems we were having in the first place.
|