Do I need a rigidbody for gameobject that scales up and down? - unity3d

I have a beginner-like question. I currently have a gameobject in my scene that scales up and down via animation. It has a Circle Collider 2D on it.
I've seen some tutorials before regarding the performance optimizations of rigidbodies and colliders. I learned that if the gameobject should move in the game, it should have a rigidbody component. Otherwise, a collider component itself is fine for triggers.
Since my game object is kind of moving (because of the endless scale up/down animation), would it be best to put a rigidbody component on it?
I do like to mention that I'm not using any physics movement such as AddForce or anything like that. Hope someone can clear this up.

A gameobject should have a rigidbody component for mainly two reasons, first one is if you are using physics, second one is if you want other colliders to detect a hit/entrance/exit by that gameobject.
From what you described it does not seem like you would need a rigibody on your gameobject, especialy because the movement is only by scale and not by position.
and also, just to clarify, putting a rigidbody component on a gameobject is not a must even if the gameobject is moving. there are different ways to move objects, and rigidbody usually helps in case that the movement should be very realistic and interact with other gameobjects it is colliding with.

Related

In Unity 2D, how do I achieve Non-trigger collsion that doesn't "physically" move the rigidbodies?

I have a bullet game object and an enemy game object.
I want to have the ability of getting the collision point/contact, which's why I think I need the collider of the bullet to not be a trigger collider - this way, I want to have the bullet bounce off the enemy. At times, the bullet will need to bounce off of rectangular objects (not a problem), but I also want the bullet to bounce off of elliptic objects (the problem).
I want the bullet not to "physically" push the enemy, which is why, intuitively, I should set the bullet's collider to be a trigger collider.
When the bullet's collider is a trigger collider, I seemingly don't have a way to implement the bouncing.
But when the collider's not a trigger collider, it pushes the enemy object.
There's no code errors, but I think the code hasn't got anything to do with the problem.
I suspect the problem may have something to do with the Physics Collision Matrix.
EDIT
It seems that raycasting would be the solution to the problem, as Leoverload proposed. My problem became a different problem now, so I'll close off this thread, and open a new one.
Thanks for the help, #Leoverload ! :D
For the position of the hit it's very easy. You must have 2 colliders and 2 Rigidbody and then you can simply add a
Void OnTriggerEnter2D(Collision Coll) and inside it check for the tag : if(coll.compareTag("surface")) and inside you can get the position with collision.transform.position.
The collision matrix on the Physics menu only allows to remove Collision between certain layers, it's useful if you want the enemies not to push eachother!
If you don't want the player pushed you can change the collider to trigger, and destroy the bullet just after the collision with the same method as before with a void OnTriggerEnter2D and the compareTag. In this way it will look like it touches the enemy and explode, but it won't actually touch anything. If you want to add knockback to the player then you could do a simple AddForce based on the direction of the bullet and the work is done!
If you want to avoid the bullet to move walls you can set walls to static and it should work fine

How do I make GameObjects use physics to interact with each other using Vuforia?

I'm using Vuforia for an AR school project and am trying to make a Roll a Ball game. However, the ball keeps falling through the ground despite the fact that both the ground and the ball have colliders. How can I the ball interact with the ground?
In general you always need at least one Rigidbody in order to get collisions via the physics engine.
A Rigidbody
is the main component that enables physical behaviour for a GameObject
What you would probably use for that is a kinematic Rigidbody on your moved object.
This is a GameObject with a Collider and a kinematic Rigidbody attached (ie, the IsKinematic property of the Rigidbody is enabled). You can move a kinematic rigidbody object from a script by modifying its Transform Component
but it will not respond to collisions and forces like a non-kinematic rigidbody. Kinematic rigidbodies should be used for colliders that can be moved or disabled/enabled occasionally but that should otherwise behave like static colliders. An example of this is a sliding door that should normally act as an immovable physical obstacle but can be opened when necessary. Unlike a static collider, a moving kinematic rigidbody will apply friction to other objects and will “wake up” other rigidbodies when they make contact.
Even when immobile, kinematic rigidbody colliders have different behavior to static colliders. For example, if the collider is set to as a trigger then you also need to add a rigidbody to it in order to receive trigger events in your script. If you don’t want the trigger to fall under gravity or otherwise be affected by physics then you can set the IsKinematic property on its rigidbody.
For detailed information also refer to Unity Manual - Colliders and in particular the sections Collider Interactions and Collision action matrix

Rigid body doesn't stop moving backwards

I am making a game in unity. I have a tank it's got a rigidbody. I am using transform.translate to move it. When it gets hit by a shot it moves backwards. If use the joystick to move it forward it moves with reduced speed. If I let go of the joystick it continues moving backward.
Please help.
There is not much to go in your question but I'm quite certain you're moving the character with transform.translate (like you wrote) but you have a Rigidbody attached to the GameObject, which uses physics.
So when your GameObject gets hit by a projectile the physics will move it backwards, and you will "teleport" the GameObject with the inputMovement, but that does NOT affect physics.
If you don't want to use physics and are only interested in the collision, you should disable the physics simulation on the Rigidbody compontent.
So go ahead and set the Is Kinematic checkbox in your rigidbody to true.
And, if interested, the value affecting physics is the velocity of the Rigidbody:
GetComponent<Rigidbody>().velocity
You need a Rigidbody on one of the colliding objects, personally I put it on the player but use velocity to handle movement to make sure it works nice with collision physics. When using transform.translate your character will essentially teleport X units every frame, giving the illusion of movement but not actually physically moving. This can make things like teleporting through walls, etc, happen.
So I've told you how to solve your immediate problem, my suggestion is that you re-write your movement logic to use Rigidbody.velocity instead. Your movement seems simple so it's practically just replacing your transform.translate with this:
rb.velocity = joystickInput * speed;

A collider is better to be static when checking collision?

So... As far as I know it's only good practice to make any GameObject Static if that object is not meant to move, therefore I also thought even a rolling stone with a rigidbody shouldn't be a static GameObject.
However, I was commented by someone as a 'Unity Tip FYI' the physics calculation spikes up when an object checks collision whilst it's rotating, so to make the collider static for the sake of better performance(even meer small amount).
I'm really not getting this idea.
Does this make any sense to anyone here??
Not exactly sure what that comment is saying. It doesn't make sense. Also, it looks like you are confusing static collider and marking GameObject as static.
Marking Object as static from the Editor
Telling Unity to batch it. It is used to increase rendering performance. (This has nothing to do with colliders)
Static Collider
Telling Unity that the Rigidbody will not be moved.
From your question, you are describing Static Collider. Static Collider work for both 3D and 2D physics system.
What is a Static Collider:
Static Collider is when you have a GameObject with any type of collider but no Rigidbody attached to it.
How to create a Static Collider:
To make a GameObject a Static Collider on, attach a collider to that GameObject but don't attach Rigidbody to it. It is now a Static Collider.
To make it non Static Collider, attach Rigidbody to it.
What it is used for:
When you have many Objects that you want your collide with but you are 100 percent sure that this Object will not be moved by you or player.
One good example is a brick wall. You simply want the wall to stop the player but you don't want to move the wall. It could also be used for stones in an environment to prevent player collison. Imagine having to attach hundreds or thousands of Rigidbodies to each stone Object with a collider.
It is used to increase physics performance.
What happens when you move a Static Collider:
Don't. When GameObject is made to be Static Collider, it is expected that you never move it. If you do, it will spike cause spike in CPU. This introduces constant freezing in your game each time you try to move it. This spike has been reduced in Unity 5 but it is still there. I think that's what that comment is trying to say. This whole thing happens because it has to recalculate the physical world all over again. From Unity's website, below is a screenshot of what happens when you try to move a Static Collider Object.
A static game object is not the same as a static rigidbody/collider, they're two completely different concept.
Static game objects are used to save performance time/memory regarding rendering, navigation meshes, etc., you can read about them here: https://docs.unity3d.com/Manual/StaticObjects.html
Static colliders are a totally different beast. A static collider is used to tell Unity that this object will never move under any circumstance, so it will save quite some calculations in the physics engine.
Finally, regarding the tip that you mentioned: I think that probably the author of that tip was talking about 3D colliders, and by "static" he meant that you should separate the 3D mesh from the 3D collider, so when the mesh must be rotated, you rotate only that and not the collider.
Think of a sphere, you create a parent game object, then two children: one that has the Mesh component, and the other the Sphere collider. When you want to rotate the sphere in place, you only rotate the mesh child and not the collider, and when you want to translate instead the sphere, you just translate the parent game object in order to change the position of both children.

RigidBodies without Extra Physics Behavior in Unity

Currently I'm making a racing game.
I move my cars with the Transform.translate class.
Now the thing I want for my cars is not to move through each other.
I attach colliders and a RigidBody to my player car and it's working.
But my problem is that each time my CPU cars and player car encounter with each other, my player car shows unrealistic behavior like moving out of the screen or throwing away.
I know this is part of the physics engine behavior but is there a way to make the RigidBody only do one job and make objects not to move through each other not to add other physics behavior?
Any ideas?
There are just few problems:
1.You don't move Rigidbody with transform.translate. When you do this, colliders will go through other colliders.
You move Rigidbody with Rigidbody.AddForce, Rigidbody.velocity and Rigidbody.MovePosition. By moving Rigidbody with these methods, collision should be functioning properly.
2.You are not even supposed to move the Rigidbody of the car.
Use WheelCollider. There are many online tutorials on how to set them up on the internet but Unity's documentation is fine too.
WheelCollider.motorTorque is used to move the car forward or backwards.
WheelCollider.steerAngle is used to steer the car.
WheelCollider.brakeTorque is used to brake the car.
If you need further help, you can find a fully working WheelCollider samples here.