So i am making a simple Golf game, when trying to replicate the balls movement i have noticed that on slopes the ball functions very oddly, it either never stops or stops too quickly and when travelling down slopes will reach a very slow terminal velocity quickly (ie it stops accelerating down slopes). So it either doesnt deaccelerate enough going up a slope or accelerates too slowly going down a slope.
I have been messing about with angular and static Friction of both the ball and the surface to see if that changes it at all and i have also been changing the friction combine of the surface and the ball to see if that makes any difference and so far haven't had any luck.
Is this a common issue with Unity because i haven't been able to find any other questions about it on here. If anyone could give me some advice on how to have my ball not roll forever but still accelerate when going down a slope that would be great
EDIT: The ball has a rigidbody with continous collision, then the course uses a mesh collider. Both however have attached physics materials
The ball is currently just a basic sphere from unity using a sphere collider, i havent tried changing the rigidbody about much yet other than mass. When the ball is hit i addforce to it, the slopes are an asset i have purchased that are perfectly smooth.
Rolling object physics are indeed difficult in game engines.
As I mention in the comment for such questions it's necessary to know (a) what sort of collider and (b) what sort of object it is, since there are at least 4 major approaches to this problem.
But in general you usually have to manually add the "slowing down" function, in a sense representing air resistance.
For a moment set aside the collider choices, and imagine in the abstract you have a ball rolling along a flat plane. You've somehow started it moving at 2 m/s say.
There's really no reason at all it will stop rolling or slow down. Why would it? There's no air resistance in physX and what you "want" it to do in the game engine physics is keep rolling.
Thus what you do is add a script that, essentially, "slows it down a little" every frame. In pseudocode, something like
velocity = 0.99 * velocity
Note however that alternately, to "manually slow it down", you may have to simply add force to it.
The trick is you do that in the opposite direction to movement
yourBalls.addForce( v.normalized * -1 * some small force )
(It's easy to think of that as basically "air resistance")
You usually also, simply, just add a top speed. In this way on downslopes it won't just get "infinitely fast"
if (v.magnitude > 3.0) v = v.normalized * 3.0
That's basically how you make objects roll around on hilly surfaces.
Note that you basically should not fool with the friction settings in anyway, it's really not relevant in most cases.
Unfortunately there is a vast amount of detail but, I feel your question is more asking for the "basic principles" - and there they are!
Tip: it could be this question is more suited to the gameDev site, where "techniques" of game physics are QA'd.
Related
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!
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 using the Standard Assets "AIThirdPersonController" prefab with a script that set the destination depending on where you click on the scene. It uses a Nave Mesh Agent.
I am using a bunch of assets from Standard Assets prototyping. Stairs and Ramp.
The problem is that the character will climb stairs if the speed is set to 1, which is running. But I want it to climb stairs when its a walk (0.5).
The character gets to the stairs and stops, the animation continues the walking animation, but he does not get up the stairs. The step height for humanoid is set to 0.4, and the stairs are less than that (they are .25).
Does not have any problem getting up ramps.
Anyone know how to fix this?
thanks
I know this is an old question but gonna give my answer here anyways.
I had the same problem and fixed moving the Capsule Collider in the agent up a little bit.
I changed the offset in the y axis from 1 to 1.25. Now there is no collision at all on the agent foot. This change didn't have any negative impact in my game, but is better to test this approach carefully.
I figure it has something to do with the friction between the colliders since when the agent has a higher speed it has no problem.
If anyone has a better fix, please let me know.
I am making an FPS game using unity 3d, I've a problem in the shooting accuracy script. Can you tell me how I can change it with a single script that shoot the bullet and include the shooting accuracy and equipped to the gun, please?
If you are currently using a raycast, you should have no problem.
If you are spawning a sphere and thrusting it forwards, I suggest you use a raycast.
Raycasts go in a completely straight line. Bullets follow gravity, and quickly fall to the ground.
You don't see bullets, they move too fast. Raycasts are invisible.
When it hits something, it sends you back the information you need. If you make the sphere go too fast, it might glitch through objects.
You can learn about raycasts here.
I'd like to make game with some windmill in it and want to make wind via b2vec2 gravity vector. I can't find some clear explanation about wind resistance. Is it possible with box2d? May I ask you to point me to necessary functions and documentation please.
What you are trying to do is most likely impossible with box2d, as that would involve the physics being simulated in 3d, while box2d only does 2d physics. If I was you, I would just fake the animation. By having the blades of the windmill in a separate CCSprite than the body of the windmill and then rotating the blades around the z-axis using a CCAnimation that matches the wind speed.
For games
Depending on the game, you may not need to worry about drag force (wind resistance). You could probably get away with pushing objects in the direction the wind is blowing, using an ApplyForce or messing with gravity (like you mentioned in the question).
If you really want to model wind resistance
Looks like linearDampening could be helpful, though unrealistic. True air resistance isn't linear.
You could also do an ApplyForce every frame, opposite the velocity. Unfortunately its been a while since I've taken my mechanics class, so I can't help you with the code, but you could look at this wikipedia article for the formulas
I stole most of this info from this thread:
http://www.box2d.org/forum/viewtopic.php?f=3&t=2718
If you are still having problems
I made some assumptions in my answer. I assumed that you're making rudimentary approximations of things like wind and air resistance. I also assumed you're not truly trying to model a gas pushing a fan, as you probably won't have much luck doing that in 2D, and even if you tried, I can't imagine it adding much to your game.
If you're still confused, try adding some example code to your question, or describe what you are trying to simulate in more detail.