I am trying to create a drivable car model using Unity's WheelColliders and I have set up my CarControl.cs script like this: https://gist.github.com/victorbstan/e5903829576eaf6ce5e3
I am encountering two problems:
The car slightly turns without any steering being applied on a completely flat surface.
The vehicle accelerates and decelerates inconsistently given the torque applied to it.
To get a better idea of what I mean, I made a video recording of the setup and play-through: https://www.youtube.com/watch?v=XuMT_AzRHbA&feature=youtu.be
Without really digging into it, my initial impression is that your WheelCollider friction values are probably too low. Increasing the forward friction will probably help with your inconsistent acceleration and the sideways friction will probably address your steering issue.
Related
I have a sphere with bounciness set to 1
The ball has no drag and uses gravity
It hits a platform, which has bounciness set to 1 and no friction
Yet, the ball bounces higher on every bounce, going to infinity. How is such a thing possible, when I have not given it any extra momentum?
The issue comes from the fact that physics in games happens in discrete frames, and that a moving object will be "inside" another at the frame where there is a collision. The physics engine then has to separate the objects before the next frame, and figure out how much energy to "bounce" with.
One of the steps to do this involves figuring out how much the objects overlap, and that's where this phantom extra energy is comin from. Less error in the overlap equals less error in the energy.
Don't fiddle with the bounciness; those are naive solutions, not to mention they sidestep the issue rather than solving it.
What you should do is to fix what's wrong with your collisions. That can be done a number of ways, the most appropriate/performant of which depends on each specific game:
Increase your physics frame rate (decrease fixed delta time). This reduces overlaps and makes physics frames "smoother". It doesn't really solve phantom energy though; only makes it's causes and effects smaller (maybe so small they become unnoticeable, which is all you need).
Set your sphere's collision detection method to Continuous Dynamic,
and set your ground to static. If you need the sphere to collide with
other stuff, those other stuff present similar issues, and those need
to be non-static, set their rigidbodies' collision detection method
to Continuous. (This is the method I most often find to be the best, but I've had projects where others were better for various reasons)
Increase your Default Solver Velocity Iterations
Change your solver type to Temporal Gauss Seidel
I have had a similar issue with javascript/html/css canvas animations. I have no explanation for this. Use a number like 0.99999 or 0.969399 and that should do the trick. I do get what you mean though it's weird. Just get close to 1. That's all I can say. I hope this helps anyway.
I have a cube with Rigidbody attached to it would slide slightly whenever I pressed the play button. If I leave it for awhile, it would slide to other side of the screen.
Anyone know how to solve this problem without using the "freeze position"? I don't know what I messed up in my project...
This is what the object looks like:
Note: I need to use the gravity.
Thank you!
Heh! The solution here is:
You had a rigidbody on the floor :)
You don't do that :) Never.
If the "floor" surface is flat, then,
it will not slide.
You've got something strange going on, such as
"floor" is NOT flat
a feature like "Wind" turned on
perhaps other objects invisible in the scene you have forgotten about are nudging it
PhysX does not have a "mind of it's own". There is some simple reason it is moving.
Let's say the "floor" is indeed on an angle, so it SHOULD move, but you WANT it to NOT move.
What you obviously do:
Just as in the real world, put something there to stop it moving.
A small invisible wall will do the trick. That's PhysX!
Usually rigidbody sliding happens when a lower rigidbody has lower mass than a higher rigidbody (forcing down the lower rigidbody). Typical problem with player having say mass 80 jumping on a cube with mass 1. In this case the collision is so violent that the cube will probably fly out (not only slide).
The situation is very similar to the real world. Try to stay on a box of milk if you have 120 kg (ok, ok, 80 :) ).
When you try to eliminate this behavior, you need either increase the mass of the lower object or decrease the mass of the higher one or set the lower rigidbody to kinematic.
The solutions above is not proper way of solving the problem. Unity has more features of physics than mass. If you get sliding on movement or because of other objects you should add proper drag value on your rigidbody. For example , lets say you have blocks spawning over top of other blocks and this creates horizontal sliding. In my case I add drag of 1 to the objects which has mass of ~ 1 kg. It depends on the scene and you should try different values on your case. Do not use bigger values and angular drag if it is not important.
I'm working on a 2D physics game that involves collisions between objects which at the moment use complex polygon colliders.
When the objects collide, I get the normal of the contact point using otherObject.contacts[0].normal, and knock the objects apart in equal-but-opposite directions using Rigidbody2D.AddForceAtPosition, with the force being the normal multiplied by a constant.
Most of the time this works flawlessly, but I've found that when the collision occurs with a concave section (aka: an inward "dip") in the polygon collider, the normal will be flipped, and the objects will instead get pushed towards each other.
Alternatively, are there any other ways I could go about solving this?
The blue circled area is an example of a problematic concave section
Alternatively, are there any other ways I could go about solving this?
Yes, the standard thing in vid games is that most stuff has many small simple colliders, rather than one large complex collider.
This is a basic of game engineering.
(It can be very surprising to hobbyists and folks new to the field.)
So, imagine a car in any ordinary 3D game. You'd have a collider for the rear bumper, one for the front, maybe one for "left doors" and so on. Very typically, each has to react in a different way, and you need to know which area was touched.
In your case if the 2D poly has say 12 edges, just make 12 "small" as it were colliders for each of the edges.
We know nothing about your setup since no screenshot, but that could possibly work.
Note however that Unity's 2D poly collider in fact already does know to slice the object in to smaller triangle-like shapes if it is concave - I'm surprused it dinnae work for you.
Further: now that we can see your image.
In any video game on Earth, the way you'd do that helmet is with a square collider as in orange:
If (for some reason .. why? for what purpose? how? where? what possible reason could there be?) you were making the most precise video game, ever created by humans, on an entirely new plane of engineering, for some imaginary new hardware with quantum warpspace cores, ... in that case ... you'd maybe add the two extra colliders to cover the horns. But nobody would ever notice the difference.
I appreciate you may be doing something exceptionally unusual, like a "close up game" ("you're an atom in medieval Scandinavia, bouncing off helmets" or whatever), in which case there'd be some other solution.
The very short answer is you've stumbled on one of the most surprising things about game technology ... we use crappy, simple, colliders, you've been tricked all your life in every title you play!
I'm trying to create a chain in unity3d. A player should be capable of grabing one side of it and pull it to different location. So i created some grids and connect them together. It all works fine, the problem is only when user pulls a bit faster, then I got some spaces bettwen seperate grids. Is there anyway to set max distance on that?
Btw. I'm doing these in 2d so i have 2d Rigidbody and 2d Hinge joint.
Thanks!
The solverIterationCount of rigidbodies affects the smoothness of physics when they are moving fast. You should try increasing it or dynamically adjusting it according to the speed of the rigidbodies to increase stabilty
http://docs.unity3d.com/Documentation/ScriptReference/Physics-solverIterationCount.html
There a number of ways to tackle this issue, all with the up sides and down sides:
increasing accuracy:: this is usually the first place new game designers go, and crank up accuracy to the max. But then end up playing the price later when performance plummets. So be gentle, try to find a good balance, and if it does not cut it make up the rest with other tricks.
The main ways to increase accuracy are, increasing fixed times interval, and increasing ridged body Iteration count
.
Increasing restrictions::This often requires the most time, but cutting corners allows for smoother more predictable physics and can increase performance
small example:: the top link of the chain only needs to simulate rotation on the ridged body
.
Cheating:: find any way to make things easier, fake it
for example:: does the image really need to match the physics? Why not make sure the sprites stick together, but alow the physics to have small gaps
playing with the same concept more or less this week, experimented some with 2D Unity joints, I think the issue you are having is identical to one I had yesterday, the force you are applying 'breaks' joints for some frames, hence that almost 'spring' joint effect, make sure the mass and/or force applied are not too heavy, also maybe increase the chain parts mass, makes the joints more solid too.
In Editor, Hinge Joint -> Use Spring = true; Spring/Damper/Target Position = 0.
I'm making an iPhone game where the main actor is a ball that rolls depending on the device's accelerometer rotation.
I haven't started on this part of the coding yet, but I was wondering if you guys had a nice way of solving this:
I tried looking a little into chipmunk, and I noticed that bodies have the property v, which is a point containing x and y velocities.
I was thinking it'd be a bad idea to just do like:
playerBody->v = ccp(accelerometer.x * 5, playerBody->v.y);
because it'd just roll up of walls and stuff,
is there a better solution to do this?
Basically, in a perfectly elastic collision (no energy lost) with a wall, which I'm guessing is what you want, the component of the velocity that is normal (perpendicular) to the wall is reversed (inverted). The tangential components stay the same. For instance, if the wall is along the x-axis, then v_y = -v_y. I haven't used Chipmunk so I won't attempt to tell you the actual syntax for doing this.