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.
Related
I'm looking for a little newbie advice on gamedev strategy and/or approach. I'm working on a game that uses Rigidbody physics in Unity and I've got a character interacting nicely with physical objects in the game world. The thing I'm trying to work through is that there are certain physical interactions that I want to control, but my own attempts to control them are conflicting with what Unity is already (correctly) doing.
For simplicity, let's just say I've got a Rigidbody-based player, and when certain Rigidbody-based objects collide with that player, I want to override where they deflect to. When I detect the collision and apply my own force with rb.AddForce(myForceVector, ForceMode.VelocityChange), Unity is also applying it's own force as a result of the same collision. I also tried setting the velocity directly with rb.velocity = myForceVector, which mostly works, but there are still situations where Unity applies force after I set the velocity so it's glitchy at best.
Other options I've considered are:
Use an additional, larger IsTrigger collision mesh to detect and handler the special type of collision I'm looking for before the actual collision occurs. That might work for slower speed projectiles, but likely will have the same issue for faster collisions.
Change the player to not being Rigidbody-based, which might work, but would require me to code a lot of the other interactions that are already working out of the box with Rigidbody physics.
Use RayCasting to detect when these special collisions might occur next and handle them before the actual collision. This is where I'm leaning currently.
Anyone have a recommended best practice for this kind of thing?
Thanks in advance!
The easiest way might just be to take full control. On the correctly timed press, disable the RigidBody and the Collider. Then just move it yourself to the target location. It's really hard to get precise control over a RigidBody -- every FixedUpdate(), it might be picking up force from collisions, and there can be many FixedUpdate() calls between Update() calls.
You could write a pretty simple coroutine using a Lerp() or Slerp() between the object's current and target position. That way, you could fully control how the object moves toward its target.
Just to follow up... I attempted to "take full control" as suggested in Alex M's answer above, but that ended up making a number of other things complicated in my specific situation. However, his comments about disabling the collider in the original question led me down a different path that ended up working well...
I ended up disabling the collider for the deflecting rigidbody upon impact and setting the velocity of the deflected body directly. That way, I was able to avoiding any additional force(s) applied from Unity while the collision was active. Once the deflected object was on it's way, I just had to reenable the collider.
Thanks, Alex!
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.
The goal is to simulate the explosion of the building. Currently developing a simulator to Unity 3D. However, now in the time of the explosion, at 4000 colliders fragments building FPS drops to 0.
Impression that unity3d can not provide the necessary performance.
Are there alternatives to the optimal physical calculation and a sufficient level of graphics (lighting, explosion sprites, textures etc)?
4000 colliders is excessive, specially if all start colliding at the same time. You can always optimize and "fake" things. Depending on the scope of your simulation you might not need all generated particles to collide. For example, dust and tiny particles could be voxels.
If your simulation is calculation heavy, which any Physics simulation should be, then you should delegate the number crunching to C.
In Unity you can also take advantage of the shader language and send packages to the GPU to help you render. You should also look for ways to optimize, such as caching Components. Good read on optimization in Unity.
You can also tell your simulation to ignore certain collisions between certain objects, such as, ignore collision between A and B.
Once you hit the ground or a certain condition you could also add this line of code:
rigidbody.isKinematic = true;
That will make Unity ignore Physics for that Rigibody. Info here.
I'd like to use compression forces to keep detached objects suspended in the air. Here's a photo of what I'm trying to accomplish:
Ideally, they would stay in the position illustrated above until acted upon by another force.
However, the boxes become all wonky and seemingly ignore the friction between each other.
If I put them closer together, they sort of explode in every direction, and if I put them exactly touching or further apart, they simply fall straight down.
Is this possible in Unity3d? or is this beyond the scope if the standard physics engine.
I haven't seen this implemented in any physics engine without intervention through code. Basically you'll have to make the objects immovable until some event triggers them to be movable.
There's no such thing as "compression force" in physics engines. The problem here is that even the slightest compression means two bodies are intersecting (overlapping) and any rigid-body physics engine will try to resolve that by moving the bodies out of the way.
A soft-body engine would be able to cope with that, but they're special use cases and not commonly used. For instance BeamNG.drive uses a soft-body physics engine to model the deformation of cars, and that's not ideal either as you'll sometimes notice that even strong metal connections have a slight wobble to them.
You can only model this behavior in a rigid-body physics engine if you were to attach the bodies through joints to keep them suspended in air, but even so they would either be allowed to intersect (might not look good unless intersection is minimal) or they'll start moving, possibly going wild. Or like I said at the beginning, have the bodies suspended at their position - put them to sleep, make sure once one of them wakes up they all wake up. Something like that.
I'm using Chipmunk 5 for iPhone, with Cocos2D. Upon collision between two specific objects I'd like to run a method which checks the velocity of that collision, if it's over x it runs one set of code, if it's under x it runs another.
Now, I understand the basics but I can't work out the code to run a method on collision detection, and the code to check impact speed.
Any help or pointers would be greatly appreciated.
Cheers.
Check out the addCollisionCallbackBetweenType function in SpaceManager.h That might help with registering collisions.
After that, you can check the v property for the cpBody objects, a cpVect of the velocity. (http://code.google.com/p/chipmunk-physics/source/browse/trunk/include/chipmunk/cpBody.h, not linked, new user.)
I am not experienced with chipmunk, but that's what a little googling turned up.
For Chipmunk 5, assuming that you want to play a sound or apply damage from the collision, I'd recommend calling the cpArbiterTotalImpulse() function from a post-solve callback. You can find more information in the docs here.
http://chipmunk-physics.net/release/Chipmunk-5.x/Chipmunk-5.3.5-Docs/#Callbacks
Also, Chipmunk 5 is fairly old at this point. If it's not a hassle, I'd suggest upgrading to 6.x. Then you could use the cpArbiterTotalKE() function. (If you are near the end of an existing project though, I'd just stick with 5.x.) The kinetic energy is an even better indicator of how "bad" a collision is than the impulse strength.