Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
So, I am working on a game in Unity and I have some issues with my colliding. The problem is that the car that I made will sometimes glitch next to the wall and wont move back or forward. even though it's not colliding. What I've done is I added 2 empty gameobjects. Named them front and back bumper and added a script that is activated when the bumpers hit a wall. If the front bumper hits a wall it can't go forward and if the back one hits a wall it can't go backwards. But this isn't really that good. I need to know how to setup a good collider because this really is annoying when you play. Also the car can go up to 50 speed.
Assuming that the car can collide at high speeds into the wall, I would consider using a specific collision detection for the car's rigidbody.
There are some collision detection methods that are used to prevent fast moving objects from passing through other objects without detecting collisions.
From Unity's documentation :
Discrete : Use Discrete collision detection against all other colliders in the scene. Other colliders will use Discrete collision detection when testing for collision against it. Used for normal collisions (This is the default value).
Continuous : Use Discrete collision detection against dynamic colliders (with a rigidbody) and continuous collision detection against static MeshColliders (without a rigidbody). Rigidbodies set to Continuous Dynamic will use continuous collision detection when testing for collision against this rigidbody. Other rigidbodies will use Discreet Collision detection. Used for objects which the Continuous Dynamic detection needs to collide with. (This has a big impact on physics performance, leave it set to Discrete, if you don’t have issues with collisions of fast objects)
Continuous Dynamic : Use continuous collision detection against objects set to Continuous and Continuous Dynamic Collision. It will also use continuous collision detection against static MeshColliders (without a rigidbody). For all other colliders it uses discreet collision detection. Used for fast moving objects.
As you can see, you should use Continuous detection for the walls and Continuous Dynamic detection for the car.
Warning : Don't forget that Continuous detection has a big impact on performance, you should only use it if you have collision issues and in the minimum possible amount of objects.
Related
I am trying to make some kind of simulation program with Unity. The simulation includes a missile launched from an aircraft and a terrain.
I get the coordinate data required for the movement of the missile from another program using a socket connection.
I created an explosion effect for the missile to explode as soon as the missile and the terrain collided. But the explosion effect is not triggered in any way.
I used the OnCollisionEnter() method to detect the collision, but this method does not seem to work.
The missile has its own rigidbody and collider and The terrain has Terrain Collider, but still no collision is detected and the missile passes through the terrain.
What could be the cause of this error?
EDIT :
I thank everyone for their help, but none of the solutions worked. I solved the error using the OnTriggerEnter method. For this, I also had to enlarge the object's collider a little more.
As mentioned in the comment section above (I dont have enough rep to contribute to the discussion but will provide a solution), you need to enable continuous collision detection. Once you have done that we can move onto the next step.
It is generally bad practice to interact with rigidbodies in update and it can lead to all sorts of strange bugs so I wouldn't recommend it. That being said I dont think it's the cause of your issues. As #HumanWrites mentioned, you are manually moving the position each frame which causes your missile to never actually collide with your mesh. the solution to this is:
rb.MovePosition(Vector3.MoveTowards(...))
The reason for this is that by using the method on the rigidbody, you inform the physics engine that you want to move from one position to the other and you would like the physics to take care of this instead of you doing it directly. This allows it to "sweep" between the current position and target position and detect any collisions that would have happened along the way.
Your missile is moving too fast to ever actually touch the mesh within a frame so you need to rely on the physics engine doing that sweep check.
So I've made this game right here: https://youtu.be/OxJEeOTldcM
And I'm facing an issue with the maze wall's colliders where, in certain levels (not just the one I'm showing in the video below), the ball goes through the walls when it's being forced against the wall by the movement.
Here you can see what I'm talking about: https://youtu.be/dVU3LWKuXJ0
I've already dealt with this and compromised by making the maze's rotation speed a lot slower than I initially intended to. I wanted the maze to rotate as fast as the player's movement, but that made the ball go through every single wall.
So the way I'm creating these levels is this: I have these pre-made PNG mazes, I import them into the level and I apply a Polygon Collider 2D on them. But it seems like that Polygon Collider alone can not properly deal with my game's collisions.
More than this, I started layering some empty game objects with box colliders on some of these walls, trying to make them stronger. This does work, but it's still not enough, and the ball keeps going through some of them.
The ball, as well as the walls, have rigidbodys on them, and I've set their Collision Detection to Continuous, based on some answers I've seen online regarding bad collision detection. Still doesn't fix it.
I've also tried making those maze's walls thicker in Photoshop, but I can't go thicker than they're right now without ruining the space the ball should be moving in, as well as distorting the maze's look.
There has to be a way in which I can fix this bad collisions of Unity. I need the ball to stop going through walls, as this is obviously an essential part of my game.
I also want to be able to set the maze's rotation back to being as fast as the player's movement, without having to limit its speed, but honestly I'd be happy if I can just fix this collision problem with the current speed.
The most frequent cause of "clipping through walls" is not bad collisions. It's usually due to poor understanding of Unity's separation of Physics and Frames.
Unity calculates collisions and physics on a fixed update cycle, and generates frames on a dynamic update cycle based on CPU resources. These are often explicitly leveraged by FixedUpdate() and Update() in Monobehaviours.
Everything in Unity happens on one of these 2 cycles. Frame based logic like changes to a transform happen on the dynamic update cycle, and physics logic like collisions happen on the fixed udpate cycle.
You are likely rotating your puzzle using the transform. This rotation to the transform happens outside of any physics calculation, and if you rotate fast enough you can end up clipping through walls before the physics calculation has a chance to run and generate a collision. This is very noticeable when you have very high FPS (like the uncapped FPS of the inspector). However, locking your FPS only masks the issue, and the bug can still occur.
To fix your issue, I implore you to make your rotation changes to the Rigidbody2D itself instead. Something like this should work:
public class SimpleRotation: MonoBehaviour
{
Rigidbody2D rigidBody2D;
void Start()
{
rigidBody2D = GetComponent<Rigidbody2D>();
}
void FixedUpdate()
{
if(rotateRight)
rigidBody2D.rotation += 1.0f;
if(rotateLeft)
rigidBody2D.rotation -= 1.0f;
}
}
Something else important to note is that Unity only updates input on the frame, so if you read your input during the FixedUpdate(), you may double read your input (or miss it completely). It is a good idea to read your input on the Update() cycle, and set a variable to transfer logic between the methods.
I am working on a 2D game that involves many blocks that stack and collide on eachother and the player. I am currently using Rigidbody2D on the blocks for dynamic collisions but I am not a fan of how the dynamic physics include the "bounciness" in the elastic collisions. Also, there is an inherent push-force as well as other unfavorable push physics that are too "realistic".
I am wondering what is the best way to handle my predicament to remove the bounciness and push elements of the rigid bodies. I've tried adjusting the block's masses and bounciness physics but no luck. Is there a way to set them all as kinematic or disable these realistic effects somehow and still have them collide via rigidbodies? (Kinematic would be great if they were able to collide with each other) Or will I have to create some sort of raycast based block physics handling script? Or is there an even better solution to creating this very primitive physics structure that I am not seeing?
Thanks for any and all help!
The only way I could think of solving your problem, such that you have complete intuitive accuracy, is to write your own Rigidbody controller. Of course you can still reuse the Box colliders.
Once you've decided on a collision detection method and manifold generation working (raycasting maybe), this link details the impulse resolution you need.
So, I'm working on a game and I've run in to the problem that.. I'm trying to detect the collision of two objects, and at first I assumed I needed two colliders. Then I found out I needed a rigid body, now I've come to find both object need a rigid body and this is a lot of cpu usage and the rigid bodies serve only to detect these collisions. It vastly limits how many objects I can have in a scene.
The only solution I can thin of is to be cast small rays from each side. Are there any other industry standard solutions that are more optimal?
Thanks in advance
There's no way to do exactly what you want. As you did not describe what you are planning to do (not even if 2D or 3D), here's a generic solution:
1) Attach a Rigidbody to only to one of the objects (out of two which could collide)
2) Tick in IsKinematic on Rigidbodyso it won't react on Physics
3) Tick in isTrigger on the other object's Collider (so it won't need a Rigidbody yet fires away trigger events when hits another object with a non-trigger(!!!) collider (and a Rigidbody)
(Or use Rigidbody on all your GOs, yet tick in IsKinematic on all of them)
As of your own collision detection, see #Hellium's comment.
I would add that, if you code your own collision detection, at the end of the day you'll most probably end up with a code eating more calc. time (and probably being at least a bit more sloppy).
Simply because you'll code in script, not C++ and the engine's Collision Detection is C++. (Your .net script will compile to native via il2cpp, so not a native implementation == must be slower than the code having similar nature, yet supported by the engine, i.e. coded in c++)
Side note: If you find your app. running slow, that's not necessarily because of collision detection. It's not impossible it's your code, what you do when you detect collision is running slow.
I highly recommend using the profiler to see what slows things down in your application.
If it really is your code, post a question on how to make that run faster.
Sorry if similar questions have already been asked.
I have a character that can hold up a shield to block incoming damage. The character has a circle collider for his body space. The shield has a box collider that blocks off a portion of whatever direction he's facing, and it's only enabled when the player is holding down a button. My enemies have weapons surrounded by triggered box colliders which are enabled when they decide to attack.
So, my problem is that when my character is attacked while shielding, sometimes his body collider is detected and sometimes his shield collider is detected. I can't find any consistency no matter what I try.
[Screenshots] (http://i.imgur.com/VHujbcG.png)
[Code] https://gist.github.com/siketh/2401454977d10ed7699b
I've been struggling with this all day and need another set of eyes. This isn't a serious project so if you need to see anything else I'm happy to post more code or explain more of my design.
It's probably because the weapon intersects with both the character and the shield at the same time. There are great tools in Unity if you want to see if that's the case.
Notice that Unity has "Play", "Pause" and "Play one step" buttons at top of the editor window. You can pause the game with Debug.Break(); instantly at the moment player fires or swings the weapon. Then you can watch what's happening step by step. Select the character, the shield and the weapon so that you can see their colliders in action. This way you can see what collides with what exactly step by step.
Similarly you can see the action in slow motion by adjusting time scale. Something like Time.timeScale = 0.1f;
To prevent this,
You may want to look at continuous collision though I've always failed to use it properly in Unity.
You may want to utilize more physics layers. http://docs.unity3d.com/Manual/LayerBasedCollision.html
You may want to detect collisions by using raycasts.
You can enlarge the shield and reduce the weapon swing speed or bullet speed. So that it's impossible to penetrate through shield.
You can decrease the period of FixedUpdate calculations so weapon movement will be smoother and there will be less penetrations.
http://docs.unity3d.com/Manual/class-TimeManager.html
There is a high probability that you are detecting both weapon-to-shield and weapon-to-player collision in one step. So why not postpone the decision one FixedUpdate later. So that you can check if there was only weapon-to-player collision or both collisions. If weapon-to-shield collision detected in previous update, then you know player hit the shield no matter if weapon passed through the shield or not.
Let's say there is no way you can detect if weapon hits the shield or the player. By using some simple geometry, you can check if the attack is coming from the direction of the shield or not.
Good luck :)