I have a sphere collider on a stick and a cylinder. The cylinder has to detect a collision with the sphere collider of the stick and fire up a "OnTriggerEnter" script. Just imagine it like a drum stick hitting a drum in virtual reality.
Is there a way to avoid registering a collision on the sides of the cylinder, but only trigger on the top of the cylinder? And even without adding more protecting objects around it?
In the screenshot you see the properties of the stick and below the properties of the cylinder.
Obviously the green and red icons show which area is allowed to be triggered and which not.
Btw, simply using a thinner cylinder collider doesn't work in this case, because it wouldn't detect some collisions at all, when the stick goes too fast trough the thin cylinder. More about that in the comments.
Thank you.
Related
I'm trying to create a platform game, watching videos and tutorials I see that they use the Tile Palette option very frequently.
When creating the 2D Tilemap Collider, each square has its collider, and I guess that makes it consume a lot of resources, so to solve that I create a 2D Composite collider.
The problem is when the player collides with the collider of a vertical wall, causing the player's rigidBody.velocity.y to add force and that doesn't allow me to execute the jump.
https://clipchamp.com/watch/nFKCJOv7DEX
Here you can see under the scene of the game the debug.log that ends up showing me a speed to the Y axis
This project would be for android, and I would like to optimize it as much as possible. Do you have any idea so that in that collision I do not add force Y?
I have tried to change the speed in an onColliderStay2d and put the vertical tilemaps with another tag to differentiate them from the ground, but nothing.
Instead of checking your y velocity to see if you are grounded or not I recommend just making a rectangular area under your player character and check if it overlaps with the ground using Physics2D.OverlapArea. It's way less error prone.
Also, just because composite collider creates less shapes than tilemap collider doesn't mean it is less performant, the physics system doesn't iterate them one by one. Do yourself a favor and just use the tilemap collider instead.
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.
What would be the best way to adjust the height of a rididbody when for example my character goes into crouch position? would it be to get a reference to the rigid body and manually change the height etc, or would a mesh collider be a better option? Im open to any suggestions, I'm just curious what would be the best way to go about doing this.
Rigidbody itself doesn't trigger collisions, only colliders does so you should change the height of collider.
In my opinion cylinder collider is a better option then mesh collider because it produces less overhead, is easy to scale (for example by just changing height) and is quite good approximation of humanoid mesh.
So just keep a reference to cylinder collider attached to game object and changed height of collider whenever your character goes into crunch position.
As shown in the picture, I want to be able to maintain this placement of virtual buttons wherever the ball moves.
This is what I've tried:
1.
The cue ball is a Rigidbody with Bounce Material, so it can bounce off the cushions. So in this case, I tried making the Virtual Buttons RigidBody Components and adding the same force to the buttons, but this didn't work because it wasn't able to detect the cushions and kept moving forward.
2.
I gave it a collider, it would bounce off the cushion before the ball and that would disrupt the formation around the ball.
3.
I tried to parent the Virtual Buttons under the Cue Ball and the Cue Ball under the Image Target, but this didn't help since it all centered within the ball and overlapped. I couldn't move it at all (I don't know why)
Willing to put a Bounty on the answer.
Virtual Butttons sometimes don't move above the Image Target, I really don't know why. But here's a work around.
Now consider your CueBall the parent. Throw in 8 Empty GameObjects as child Objects. Position these GameObjects in the position around the ball that you wish to maintain through the movement.
Now each virtual button is put as a child to these GameObjects respectively.
And now script movement of the ball. You should see it works perfectly. Make sure you have your X and Z rotation restriction. I guess since it's a Cue ball and its white, the rotation won't be much of a problem, unless you're scripting for Curve shots as well.
Hope this helps.
A solution might be to create a script to attach to your ImageTarget, that has 9 public transforms, (your 8 planes and the cue ball) that would then look at the cue ball's x and z coords, and then would change the planes' x and z coords accordingly.
This is the setup I have. I am trying to make a game in unity which appears 2d but is actually 3d. I have a simple sphere and a floor, which is made up of cubes placed next to each other(the colliders overlap a little) with the same Y value and Z value. My 2d plane is in X-Y plane(Z being the depth).
Now in the script attached to the sphere, in the Update function, I have used rigidbody.addForce() in the +ve X axis function to move the sphere forward. I have attached rigidbody to the sphere and enabled gravity. The collider of the sphere is the default one.
Now the problem is:
When I run this scene. The sphere moves forward but at the intersection of the colliders, it jumps a bit(very less but still noticable) upward and loses its momentum. It happens at every intersection.
BUT this does NOT happen if I place the sphere on a floor made up of a SINGLE cube(a very long one).
Is this problem arising because of overlapping colliders? How do I solve this issue?
Thanks in advance
I don't think this is fixable. Unity physics is approximate, and even when physics material are set up to 1.0 bounciness, momentum doesn't stay constant — I learned it the hard way when I tried to develop a game depending on constant momentum, and had to write my own little physics simulation for that.