koobas.hobune.stream
GameObject disappears when velocity is set to (near) zero.
I'm using Unity 5.1.0f3. I have a simple GameObject called "Ball" with a non-kinematic rigidbody and simple script attached. I know that I shouldn't modify rigidbody's velocity directly, but this is a very simple scenario (pong-like game). At some point of time (let's say after 3 seconds of delay) the external event occurs that triggers the ball to init the move, by calling following function:
void Run()
{
rb.velocity = new Vector3(Random.Range(-BallSpeed, BallSpeed), Random.Range(-BallSpeed, BallSpeed), -BallSpeed);
running = true;
}
My FixedUpdate looks like this:
void FixedUpdate()
{
if (!running)
{
return;
}
rb.velocity = new Vector3(rb.velocity.x, rb.velocity.y, rb.velocity.z < 0 ? -BallSpeed : BallSpeed);
}
So far it works OK. However, when I RESET the Ball velocity to zero (by assigning rb.velocity = Vector3.zero in event handler) then after around 0.5 seconds the whole GameObjects is destroyed. It disappears also from hierarchy. I inserted Debug.Log in OnDestroy() and it is actually called. However, I don't call any destroy from my scripts. Moreover, if I reset the velocity not to zero but for example to (0.4f, 0.4f, 0.4f) it works fine (although of course ball moves a little)! The 0.3f seems to be a limit value.
Why after setting velocity value of rigidbody to zero or almost zero my whole GameObject is destroyed? How to debug such behavior?
" I know that I shouldn't modify rigidbody's velocity directly". Directly setting velocity is fine.That advice is only for people who don't know coding, local axis, physics math. Lots of people confuse += with =, and got advice "you know what, just stick with AddForce for now."
Probably one of your scripts somewhere is killing the ball. One you totally forgot about, since "it can't be that one." Did the OnDestroy debug give a stack trace (btw, clever. I wouldn't have though to that)? For fun, try in a new scene/project. I'd guess the ball won't get killed (even if it does, that narrows down the problem.)
Thanks for suggestions. I did check stacktrace in OnDestroy() but only OnDestroy itself was there. Seems like it was called from Unity Engine somehow... I would love to have a full backtrace but since Unity's .dll are closed I guess it's impossible. However only symbols without sourcode would be sufficient to see what function from inside Unity called my OnDestroy()... Anyway, I've created separate project and implemented only the part that I was interested in and I cannot reproduce the problem... I'm really sure I don't call OnDestroy() explicitly in my scripts :D Also, this object didn't have parent. All in all this was my first project, I'll re-install Unity (since I have couple of versions installed) and will start it from scratch. $$anonymous$$aybe I clicked something in project settings during my 'try-and-error' phase while learning Unity.
I can't even think of a way to "accidentally" have objects destroy themselves -- no settings or things like that. The old particle emitters had an auto-destroy checkbox.
As you write, having a parent can indirectly Destroy you, but someone still has to call a Destroy on that parent.
It can be easy to have a "secret" script on the camera, or some empty; and have that forgotten script be responsible for oddness.
The physics engine has something like Sleep Treshold. I was suspecting that zeroing the velocity makes the treshold to trigger. Normally it shouldn't be a problem of course (it's a feature in fact), and it should be awaken as soon a new force is attached. Also, it shouldn't destroy the whole GameObject. But maybe in my case, it triggered a bug in Unity? I mean, some internal functions related to putting object to sleep failed? I saw somewhere in the internet someone described the same behavior and claimed that re-installing Unity helped (can't find it now, hopefully I didn't dream it :P). I tried to change this treshold but it had no affect on the behavior. This is one disaventage of closed engine: I cannot see what's going under the hood :/. $$anonymous$$aybe I changed something in physics/project settings, then configured rigidbody in such strange way that it triggered some low-reproducible use case causing such behavior... I just can imaging a bug in editor that changes something more that I'm aware of or something like this. But those are only my loose thoughts.
And really, there was no way that I called OnDestroy from scripts. Anyway, thanks for attention! I hope after reinstalling I don't get this behavior again. I think I will post a bugreport to Unity if I reproduce it again.
The biggest problem for me is now the ability to debug things happening inside the Unity engine. But it's another issue and maybe I'll ask another question.
It's not rigidbody sleeping. All that does is cause the physics step to ignore the object, but it never destroys the object. Visually, the object doesn't move when it should. For example, an object resting on a table, and the table is moved away or tilted in a way which tricks the physics system into not sending a WakeUp. And setting velocity won't even cause a sleeping problem.
If you really want to test it, copy your scene, then delete down (check gameObjects to be inactive?) until the bug goes away (you said the bug was gone on a tiny test project.)
This is a little late, but might still be of use to someone. I've just encountered this same problem whilst making a breakout clone (as a way to test out the engine) and had problems with the ball disappearing when I reset its speed and position. I eventually tracked it down to the Trail Renderer component that I had added to my ball. Specifically it has a parameter called Autodestruct. If set to True, the ball would disappear. Changing it to false fixed the problem.
