I'm trying to make a sticky grenade by disabling its rigidbody upon collision, using OnCollisionEnter(). However, OnCollisionEnter() fires when there is clearly no collision happening, as you can see in this image : https://imgur.com/w9KMEff. This causes my grenade to stick in the air. I suspect this is due to a lack of synchronization between physics loop & rendering loop. Also, my standard "non-sticky" grenade uses the same model & is working finely.
I already tried the following :
Verify that there are no other colliders which could cause my grenade
to "stick in the air"
Use OnTriggerEnter() instead. The result is a little better but the problem is that it is fired too late, only once the grenade is inside an obstacle or an enemy.
Add rigidbody & continuous collision detection to all objects
Tweak PhysicsManager.DefaultContactOffset from 0.01 to 0.001, as suggested by Eliasar
Switch from "PCM" to "Legacy Contacts Generation"
None of these worked so I'm feeling a little desperate. Thanks in advance for your help !
Code I use to stick the grenade upon collision :
void OnCollisionEnter(Collision c) {
rigidbody.isKinematic = true;
transform.parent = c.transform;
}
PhysicsManager.DefaultContactOffset might be set too high for your object scale
According to this Unity forum post, your physics margin might be too high if your objects' scales are too small. OnCollisionEnter will fire during a Physics tick and may update your grenade's position a frame sooner than you're expecting. That would explain why it would stick outside the contact point, whereas OnTriggerEnter would process 1 frame later.
Unity post in text form
Max_van_Hell, Jun 1, 2017
oh god yeah Baby, I finally found the issue!
Appearantly the PhysicsManager.DefaultContactOffset was too high for my scale. The Default contact Offset was about 0.02 and with virtual objects which are around 10cm it yields a HUGE error margin obviously.
That never was a Problem for me, since in most graphics or game projects the scale of the objects is actually much larger so that such a contact Offset does not have a huge influence.
However, since this is a HoloLens Project and I am working with virtual objects which are around 10cm - 100cm the contact offset is more sensible.
Anyway, thank you much for your help!
cheers,
Related
I am currently working on a classical fps game, I want to be able to generate larger numbers "enemies", ideally in the hundreds. Though this may not be feasible. I am hoping to use physics and Rigidbod[ies] for these enemy models.
Obviously the nice solution would be to have mesh colliders on all these models but I'm pretty sure that will affect performance. So my alternative idea was to instead set them up initially with box colliders while they are atleast X distance from the player and then once they enter that radius around the player to switch (via enabling and disabling) these box colliders to mesh colliders.
Is this possible to do and what are the implications? My initial tests caused the model to lose its collision detection with the floor, and so drop through the environment.
Are there are performance implications to switching (enabling/disabling) colliders/if this would even make a difference?
Lastly if none of the above, is there a better solution to this problem that is performant?
The most common practice I know is using multiple primitive colliders under the same rigidbody; I believe this is much more efficient than using mesh colliders, plus, as an added bonus you can even very easily handle special hits (headshots do x2 damage, leg shots slow enemies down) since you know exactly which collider was hit.
Here is an example of how they did it back in the day in Counter Strike
Notice that you will have to place each primitive collider correctly on the bone structure for it to move correctly during animations.
I think you should have two colliders for your ennemies :
1) A persistant box for physical interaction. (This collider would be on a separate layer, colliding only with the physical space.
2) Then, you would have your flexible box / mesh collider. Instead of swapping colliders, enable/disable them. If it is too far, try enabling the box, and if too close, enable the mesh collider. I think enabling and disabling is better for performance than removing and adding components at runtime. Plus, since you already have an 'environmental collider', swapping isn't an issue for the movement of your ennemies.
Hope this helps.
I am working on a Unity game in a 2D environment. The player GameObject has a Rigidbody2D attached. It moves horizontally when swiping. When swipe is too fast, it does not collide with the Colliders. Maybe it changes its transform position before detecting collision? It does not happen when the swipe is slow.
Based upon your problem I am assuming you are moving your object in the Update() function (please correct me if not). This means you are moving the object a certain amount every frame. However, Unity checks colliders and does physics calculations on a different time interval (Fixed Timestep, https://docs.unity3d.com/Manual/class-TimeManager.html).
Just before the objects collide, the colliders are checked. Unity calculates colliders every Fixed Timestep (default 0.02 times a second). If unity does not detect a collision it means your objects intersect for less time than the Fixed Timestep, or in other words, they are moving very fast (like you describe your situation). One (bad) way to fix this would be to decrease the amount of time in between physics calculations. However, this would greatly decrease your programs efficiency.
Instead, consider moving your object in the function FixedUpdate() so that the object only moves every time the physics checks for a collision. This should fix your problem.
Take a look at the 3rd answer (by Garth-Smith):
https://forum.unity3d.com/threads/rigidbody-2d-wont-collide-with-another-object-when-its-moving-really-fast.248786/
I particularly want to highlight the part:
If you have a Rigidbody2D, you should be moving it in FixedUpdate()
using rigidbody2D.MovePosition(Vector2). This will move the
Rigidbody2D through space, instead of teleporting it from point A to
point B.
The second part about Raycasts should not be necessary for your problem, but if you continue to experience problems your can use them to check a range as jdweng stated in his comment.
Here are a couple places to learn about Raycasts if you are unfamiliar with them:
https://docs.unity3d.com/ScriptReference/Physics2D.Raycast.html
https://unity3d.com/learn/tutorials/topics/physics/raycasting
If the movement of your object is too fast it will simply ignore the collision since it never touches the actual collider - it just skips it.
In order to fix this you need to predict when that collision will happen and trigger it at correct moment.
Setting collision detection to Continuous as pixlark said might help if the swipe is not too fast.
Make sure that the collision detection mode for your Rigidbody2D is set to Continuous or Continuous Dynamic.
simple
go to the rigidbody of the object and change the c
I'm having a problem with Physics! I have imported an object which a bridge from 3ds max to unity 5 ,but the problem is that whenever I want to walk through on it ,I just fall down. It's like there's nothing called BRIDGE! I know there must be a problem about Physics. But how to fix it ?!
When importing a model into Unity it does not have any Collider.
Even though using auto-generated "MeshColliders" is an option
I highly recommend not to use them.
You never need such highly detailed colliders in a game.
Instead, you have to
Add the colliders manually
Here is a little step by step guide
This is the imported model (made with blender) without any collider whatsoever
First thing to do is add a new box collider to the components
as shown in this gif
The next thing to do is scaling the box collider
by either entering the values manually or using the drag/GUI version like I do in the gif below
(you probably know that already but the mode can be changed to orthographic by licking the small cube in between the cones in the upper right)
If necessary you can add as many "detail" collider as you want
by repeating the steps. Sometimes sphere or capsule colliders might fit better but keep in mind that they have a higher resolution!
In this case i added another box collider representing the upper part of the car:
Thats all you need to make things collide with your object
Right now you only have a MeshFilter, MeshRenderer, and Animator component attached. You walk through it because the mesh is only being rendered. In order to add collision, add a MeshCollider component to it.
Joe offers another way to do it with box colliders. There is a bit to know about both methods:
Box colliders will take more time to set up (rather than just adding a
component) and will have less precision. They will have faster performance.
Mesh colliders do not collide well with other mesh colliders.
However, this is often not an issue. If a mesh collider has the
"convex" checkbox checked then it will collide just fine with other
mesh colliders. Small items and any convex-shaped meshes should have
"convex" checked.
For something like your bridge.. it depends on your game. If you are doing a top-down game with limited mobility (no jumping) then box colliders may work for you. If you are making a first-person game then I would strongly suggest mesh colliders. If you decide to use box colliders then you must set them up carefully. Otherwise, physics may not match up with what the player sees!
Do not worry about performance at this time. Worry about it later IF it becomes an issue. With the physics upgrade in Unity 5, it probably won't be.
I'm using LeanTween engine and all was going well until I tried this:
LeanTween.moveY (menuPanel, 1200f, 0.5f)
.setEase (LeanTweenType.easeInOutBack);
The goal is to have the menu panel move down slightly before shooting up out of the screen. The easeInOutBack seemed the correct type (based on Easing Cheatsheet).
menuPanel is a GameObject UI Panel of which I declare as public and assign in the inspector.
Instead it goes a little crazy, bouncing up and down sporadically whilst moving a bit.
Has anyone observed this behaviour before, know what I'm doing wrong?
I know this is an old question, but just in case anyone else is having similar problems - you'll need to disable the Rigidbody attached to the game object you're tweening to avoid getting unpredictable behaviour in your raycast.
I'm developing a 2.5D mobile game with Unity. In order to move the character back and forward I'm using a piece of code inside the update function:
void Update () {
if (shouldMove==true){
transform.Translate(Vector3.forward * 3 * Time.deltaTime);
}
}
So that code works pretty well when the game is running at 60 fps, but when the fps go down to 30 or less, the character starts to vibrate while moving. I've tried to test the same code with a plane terrain and it worked well, so maybe the problem is the collision between the character's and the terrain's colliders. However, I don't understand why if the fps are high it works well. I've tried both capsule collider and a mesh collider but no one has worked. What do you think? Should I try to use another code?
Edit 1: I'm using a capsule collider and a rigidbody. Should I use a Character Controller?
Sam Bauwens is absolutely right in his response, however, this issue normally is caused due to an excess of objects (specially those which are animated). This can worsen the performance a lot.
You should try to delete some of the objects and try if your character still vibrates. If it doesn't, that means that I'm right. Of course, you won't want to delete objects of your scene, so, you can add an asset such as SmartLOD that deletes the geometry of those objects that are not shown on screen and thus enhances your game's performance.
Hope it helps.
I had a similar problem with a ball that vibrates on the ground. It was caused by gravity which is pulling the gameobject towards the ground, then it collides on the ground and bounces. If your problem is the same as me, you have to either tune the Fixed Timestep (Edit => Project settings => time) and/or Bounce Threshold (Edit => Project Settings => Physics).
By increasing Bounce Threshold, you're going to increase the minimum speed below which an object won't bounce, so that the force of gravity won't be big enough to make the ball's velocity exceed the bounce threshold.
By reducing Physics time step, you reduce the impact of gravity for each time step because the time steps are smaller and therefore the amount of velocity added to the gameobject for each timestep is smaller.
EDIT: you can also look at sleep velocity (Edit => Project Settings => Physics), because if it is higher that the gravity velocity, the object shouldn't vibrate.