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.
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!
so I've been trying to see if I can make use of Wheel Colliders for the past several months now. As much as I've managed to figure out more and more things about how to set them up properly, there's some things I've been noticing that seem impossible to avoid:
Even if your friction sideways stiffness is lower, there's a chance that your car will continue to "spin" or "rotate" in the direction you were steering if you JUST hold down your input long enough to get the car beyond just rotating. I've noticed this will happen, whether for example the "SteerHelper" or "TractionControl" functions are doing their work or not. This will put a dent in ensuring smooth turn movement. Now, I don't know if maybe this is just due to realistic car physics (I mean, I can picture the car skidding in scenarios where they lost grip of the road for sure), but it just feels kinda glitchy. Sometimes, even when I'm not turning, the car will start to turn a little to the left or right and then gradually seem to "lean" that way in terms of applied torque to the rigidbody. I've seen many suggestions for trying to stop the rigidbody from doing this. Here is one way I'm trying to work against this:
rb.AddTorque(-rb.angularVelocity * 2);
However, it seems that the car will still "spin" more than intended. What would be ideal is to be able to MAYBE allow the car to turn a little extra after the left or right steer buttons were released (maybe more or less depending on the vehicle), and no more than that to ensure there is maximum control to give the engaged and maybe arcadey game play I've been going for for a long while.
It's been difficult to adapt an ideal friction curve value that would give the most ideal feel of a drift turn, especially a more arcadey one. I'm not trying to go for wide turns that slow you down, I'm trying to go for tight (yet controllable) turns that allow you to preserve most of your speed. I find that especially at higher values of stiffness, as I know many people have observed in other posts, that again, the car will turn back an extremely high amount sometimes (you drift left enough, a force is turning your vehicle way to the right). It's sad, because I've wanted to be able to say I've "mastered this beast" and used it for my purposes, but I don't know if that's really a good practical expectation for anyone. I even worked my own alternate friction curve values that would be used in the controller:
But I guess as some people say, you can't polish something that's broken? Moving to the third point...
I've read so many posts that show how to adjust a vehicle's center of mass, or to add more colliders in different spots to correct it, using scripting to add an offset to the center of mass, etc. So many tips that say, "lower the center of mass, you'll find it" and I give that a try. When the center of mass is too low, my car can get pretty shaky on the terrain (not that it hasn't in the past, but it's often been things I could correct, like the weird initialization of the attachedRigidBody of the wheel colliders themselves in the beginning, etc). High enough, and of course, (even when it's lower sometimes???) the car will just start spinning in the air on either multiple axes or specifically the forward z, when you drive off a ledge or bump into something with a high enough speed. It just seems inevitable.
I've been trying to give my benefits of a doubt. I like to think there's a correct way to use this thing, and that I'm just not familiar enough with Unity3D physics concepts. However, it just seems more and more that I'm investing too much time in a broken component - or, maybe I just never got the best grip of physics.
I was about ready to try just convex mesh colliders around my tires, and just abandon the idea of gripping physics altogether, but I'd love to hear suggestions to either address anything I've mentioned above, or just a more ideal package to move onto. I've glanced at packages like Vehicle Physics Pro, but I do want to be sure I'm getting something that makes sense.
Full disclosure: I'm in the middle of trying to make a game that feels incredibly similar to F-Zero, but with wheels.
Thanks in advance for any thoughts or suggestions you can provide.
(Maybe not an answer per se, but hopefully helpful.)
Note Unity also suggests to possibly give the car a constant downward force via script. It might be telling that such workarounds are officially given, one would think proper physics would, well, properly work without them.
There's some assets you might want to give a try generally:
One is the Unity Asset Store asset called Arcade Car Physics, and it's free. I've tried it and it works (but not sure if it works for your needs). It's using Unity's native Wheel Collider plus extra scripts.
Another is the Arcade Car Physics github project. It has nice plane stabilization and more, and works well. It's not using the native Wheel Collider.
Then there's this asset called Vehicle Physics. Instead of native Wheel Colliders, they've create a fully custom wheel system so that it would be more physically workable. The asset is not free, but they offer a free demo executable where you can drive around different vehicles, and that works quite well. (I haven't yet bought this asset myself.) As a downside, some reviews mention there's some complexity in setting this up (and I suppose future support for this custom Wheel Collider hinges on the company continuing to exist).
Good luck!
How can I completely remove the bounciness from my PhysicsBodies, I already set the restitution of all PhysicsBodies to 0 but when multiple PhysicsBodies collide they still bounce off of each other, how can turn this off?
Here's a video where i swipe up and down which triggers this code on the blue SpriteNodes:
node.physicsBody?.applyImpulse(CGVector(dx: x, dy: y))
https://imgur.com/a/MD2Sc
I want the blue SpriteNodes to just stay up or down and not bounce away
Are you experimenting in a space without any world damping/friction? If so, you will need to zero the velocity of objects the moment they collide in order to get zero bounce. But you'll also need to move them outside the boundary of the objects they collided with.
By way of explanation:
This is, I presume, happening because your objects are achieving a (slight) state of overlap right before the collision is reported to the physics engine. When this happens, the first response of some physics engines is to remove this overlap by moving the object with a corrective amount of force or movement. What's happening looks like a continuation of that movement.
In some physics engines you get the opportunity to determine how strongly the corrective behaviour is, and how frequently it occurs, and even set the physics simulation to much higher rates of solving than the frame rate. In these engines you could find the right balance of settings to prevent this. But not in SpriteKit.
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.
I am looking at tutorial where things are defined like this:
planes are sprites with dynamic physics bodies
plane moving is done with actions by following the path
there is contact detection between bullet and plane
bullet is sprite and it has physics body set to be static (which is little unusual in my opinion)
Here is the link to tutorial for more information.
Questions:
When we use actions to move physicsBodies is there a difference how we set body's dynamic property? Because bullet is static but still there is no problem for movement.
When we have situation like this, where we don't need collision detection, but just contact detection, and we can't move sprites (enemies) by applying forces or impulses, what is a good approach? Is this approach correct?
I think this is nice way, but I would like to be fully aware what is really happening when we use this method and are there any drawbacks or possible problems.
There are posts on SO that suggest we shouldn't use actions for moving dynamic physics bodies. I am aware that we can't use this approach in every case. For example this would not work for moving platform with other object on it, because there would be no correct physics simulation between body on the platform and platform moved by action. But in cases like from this tutorial, where we only need contact detection for object that can be moved only by actions (moved along path) I suppose it's not a problem ?
static means that the body isnt affected by physics. That doesnt mean it cant be manually repositioned or moved. So if something is set to static, it participates in the physics simulation, but it isnt affected by it. Think of a plane hitting a mountain. The plane is dynamic, the mountain is just going to sit there even though its participating in the physics. But you could still move that mountain around manually using a position or an action.
Not totally understanding your question, but I'll give it a shot.
You can move physicsBody's manually (using position property or actions), but you need to ask yourself why you're doing that. You typically don't want to do it because they're bypassing the physics simulation. If you're forcing it to move around, what's the point of using a physics body in the first place.. right?
But if your physicsbody is something like a powerup that is totally static, and you just want it to move around in a circle using an action then thats fine. You probably just want to use contact detection for the bullet, powerup, etc without actually moving it around using physics. Nothing wrong with that.