koobas.hobune.stream
The question is answered, right answer was accepted
Physics behaves more strangely with Time? Bouncing and Sliding Objects
Is there any plausible reason why Physics would act more and more strangely over time?
I have gameobjects that spawn and destroy over time.
As time progresses the way these objects react to Colliders becomes more and more strange. There is no Time factor in my collision scripts.
Things that are affected most are Bounce (increasing) and Friction (decreasing).
The number of gameobjects doesn't seem to be an issue IN THIS CASE as having few or many gameObjects early on will not behave this way but having few or many later on will.
Is my FixedUpdate() dropping steps? I'm getting a stable 80 fps!
EDIT: Ive added a HIGH FRICTION Physic Material and it has NO EFFECT on this issue!
Any chance there's something in one of your game scripts that's changing gravity slightly?
I actually don't use set world gravity but I've scripted Physics.Gravity to change with accelerometer ins$$anonymous$$d. So it's not a slight change but a full 360 degree changability around the z axis when the phone is turned around (android).
var gravityVal : float = 20.0;
var Grav : Vector3;
var dir : Vector3 = Vector3.zero;
function Start()
{
Grav = Vector3(-gravityVal,gravityVal,0);
}
function Update ()
{
dir.x = -Input.acceleration.x;
dir.y = Input.acceleration.y;
if (dir.sqr$$anonymous$$agnitude > 1)
dir.Normalize();
Physics.gravity = Vector3(dir.x*Grav.x, dir.y*Grav.y, 0);
}
I don't grasp the concepts of these things yet, but from reading the Normalize bit about a vector3 that's (really) small getting set to zero makes me wonder if that, over time, is the culprit. Edit: hmm that would make the whole equation come to 0,0,0 if that happened, which does not sound like it would results in a slight bounce/friction change - not sure.
Noted. I'll look into it.
Basically, I normalize to find the Unit Vector, which is just the direction component of the Vector. Then I multiply that by the Gravity value. I do it this way so I can play around with the components at different stages in the game.
The x,y,z of the accelerometer each vary between -1 and 1.
dir.x = -Input.acceleration.x;
dir.y = Input.acceleration.y;
are the calls for retrieving x and y values of the accelerometer.
I think this was one of the first scripts I wrote for my game; maybe I was being hasty, but the gravity actually seems to behave very well on my gameObjects.
If you want to just rotate the gravity about the device Z axis (perpendicular to the screen), zero the Z axis and normalize the accelerometer value, then multiply it by gravityVal :
function Update ()
{
dir = Input.acceleration;
dir.x = -dir.x; // mirror X as you were already doing
dir.z = 0; // ignore Z axis
dir.Normalize();
Physics.gravity = gravityVal * dir.normalized;
}
If the accelerometer is too jerky, filter it with a "Lerp filter":
...
public smoothSpeed: float = 5;
function Update ()
{
var temp: Vector3 = Input.acceleration;
temp.x = -temp.x; // mirror X as you were already doing
temp.z = 0; // ignore Z axis
temp.Normalize(); // normalize it
dir = Vector3.Lerp(dir, temp, smoothSpeed * Time.deltaTime);
Physics.gravity = gravityVal * dir;
}
Thanks for the reply dude. Writing a gravity script wasn't really the problem. I kinda breezed that :P The problem is the strange physics defects that occur after a Time.
I've now tried dir.z = 0; I actually prefer it without as the gravity responds differently when the phone is flat. I don't $$anonymous$$d the unit vector pointing in z as all objects are z-locked and the response encourages the user to hold the phone up a particular way.
I use
Physics.gravity = Vector3(dir.x*Grav.x, dir.y*Grav.y, 0);
to zero the z ins$$anonymous$$d.
I keep the components separate so my Governor can play with the gravity, but I havent updated it for separate gravityVal's yet.
And I was very surprised by how smoothly the Accelerometer handles. Technically Unity automatically accesses Gyro data when its referring to accel. Which is a lot smoother anyway.
The strange Physics defects seem only to happen after a certain amount of time rather than any other factor.
One thing I will mention is, the common offending object has a $$anonymous$$esh Collider AND has Generate Colliders checked. It is a screen bordering object that encapsulates ALL other gameObjects, so primitives just wont do.
Frankly though, all these problems would be solved if I could find a solution to my other, see$$anonymous$$gly simply problem:
http://answers.unity3d.com/questions/500349/how-to-fix-rigidbody-dir-vector-despite-force-dir.html
By the way Aldo
Electronic engineer, specialized in audio, analog and digital electronics, microcontrollers, and addicted to program$$anonymous$$g.
Snap :) I'm the same!
@meat5000: so, you're a colleague engineer! That's nice - I was feeling kind of solitaire among all programmers in UA! About the question: I supposed that your problem could be caused by gravity beco$$anonymous$$g too low: the main difference between our scripts is that in yours gravity falls near to zero when the device approaches a horizontal position, while in $$anonymous$$e it's constant - only its direction changes. But from your comments I deduce that gravity is working as you expect, and only collisions with the outer mesh collider behave strangely. If so, my suggestion is to replace the mesh collider by box colliders that surround the same volume. $$anonymous$$esh colliders are somewhat slow and problematic: collision detection starts at the collider bounds, than iteration through the mesh triangles takes place in order to find the hit point, if any. This is time consu$$anonymous$$g, specially when compared to primitive colliders like box, capsule and sphere: in these cases the collision detection is solely based in their basic properties (center, radius, height, size etc.), which's more reliable and a lot faster.
PS: I saw your previous question and tried some solutions, but no one worked as expected. I tried to project rigidbody.velocity on the desired direction and assign it back, but the RB gradually slipped out of the original trajectory. I also tried to clamp the rigidbody position to the desired trajectory in FixedUpdate, but weirdly this didn't work either - again, the rigidbody drifted from the ideal trajectory while moving.
Thanks for trying dude! I'm getting stressed out by this see$$anonymous$$gly simple problem.
I've gone back to read your comment again. I think I didn't understand it back then. $$anonymous$$akes much more sense to me now :)
