koobas.hobune.stream
hinge joints and velocity
So I have an oriental dragon based on hinge joints. The tail and the head are Kinematic. The rest isn't. When I pause the game I use the function below to switch the other hinge joints to kinematic, that way they don't all around.
This all works great until I unpause the game and set the rigidbodies back to being non kinematic. At this point the velocity of the dragon seem to double. I've checked and constrained transforms, but can't figure it out.
Any help would be greatly appreciated.
Transform SetActiveOnHingeJoints(Transform current,bool abool)
{
if(current.rigidbody !=null && current.name!="Head" && current.name!="Tail")
{
if(abool)
{
current.rigidbody.isKinematic =!abool;
current.rigidbody.velocity = new Vector3(0,0,0);
current.rigidbody.angularVelocity = new Vector3(0,0,0);
}
else
{
current.rigidbody.isKinematic =!abool;
}
}
// search through child bones for the bone we're looking for
for (int i = 0; i < current.GetChildCount(); ++i)
{
Transform found = SetActiveOnHingeJoints(current.GetChild(i), abool);
if (found != null)
return found;
}
return null;
}
You shouldn't need to set them to kinematic on pausing the game. Instead set Time.timeScale to 0 - then reset it to 1 when the user unpauses.
Its a good answer, but I need certain physics based object to keep moving while the dragon freezes.
Though what you've said has given me an idea....
Ah ok :) So in that case you need to take a copy of all of the rigidbody velocities (angular etc) on pausing and play them back on after you set is$$anonymous$$inematic = false.
precisely, WD has explained the situation in that comment
it's actually a huge nuisance in unity, they should have TWO CONCEPTS
"rolling pause" ... perhaps "freeze" ... continues physically where it was
"pausey pause" .. basically all the physics disappear when you pause
one huge problem here is....a
lmost every time othe r than in Hello World,,
your rigs will have some sort of "rest state". so, in reality, whenever you do the "pausey pause" offered by Unity3D, in fact, you also have to typically return them to some sort of rest state (positions, etc, animations, sounds, who knows what)
it's a good example I$$anonymous$$O of how some stuff in Unity is essentially simplified, and in basically 100% of real games there is "something else you have to do" in terms of some functions, paradigms...
Whenever I report to my partners on progress in my game and what I'm working on - I always get the "but didn't we spend a ton of cash on a game engine?" question. I try to explain that physics, 3D rendering, shaders, effects, input management, scene management, shadows, lighting etc etc are all very hard to write - but then there is the weeks spent saving a level and they ask "don't all games need a save feature?" Yep
