A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Discussion in 'Physics' started by SeriouSerg, Mar 4, 2015.
Edited: No time for pointless internet arguments.
Ill take that as 'I got nothing'
*pointless internet arguing*
This collider shall be repaired ? Is there any official response on this?
It's my understanding that it's mostly what physx is so there's nothing to fix (barring any bugs).
If the vehicle moves a bit forward , the wheel will detect the collider and will project on top of him , and this will make the vehicle go flying ...
Have you tried making your Physics settings more or less sensitive?
I've tried all sorts of settings , here's an example:
sorry for the Portuguese in the script , I'm Brazilian , so I end up programming in my language
Soften spring/dampers. Make sure wheel colliders aren't out of your car's collision geometry bounding box.
This and why are the Substeps setup so high?
the vehicle is configured correctly , the colliders are well placed too.
1. Your wheelCollider mass is ridiculous. Use a value under 100. This is the mass of the wheel, not the mass of the weight its carrying
2. your spring/damper values are also way too high. They look like values from a U4 wheel collider.
Try script in my sig... might help
James, Are you seriously saying you've never come across a vehicle with 2 tonne wheels... I guess you've never fitted wheels to a Skyscraper and drove it around...
Regardless of the value be 20 , 200, 2000 , 20000, the problem anyway.
The key part of your issue is just that Unity wheels are a simple raycast straight down - they have no volume, they're just a line pointing down, so as you go from one level to the other they'll always "pop" up like that to some extent. They're just not really suited to quick vertical changes in height unfortunately.
lol.. sounds like a great idea for a game
not the problem anyway?
The problem with your car flying off is exactly because of the stupid values you used... dont bother with my script, its probably too advanced for you, despite being simple.
Dude, no need to be so mean about it. He's probably still seeing a bit of a jump even with realistic values because of the sharp transition between heights coupled with the raycast-based wheel collider. Yes he can reduce the issue with better values, but it won't ever go away entirely.
It's not a Unity 5 physics problem like this thread is mainly about (Unity 4 had the same sort of raycast wheel physics), but it is a wheel collider problem. Edy mentioned earlier in this thread that he'd like to some something about it eventually with his custom wheels.
In the first screenshot the ray is just about to hit the bump:
Dont have any time for people who want help, but dont want to listen.
I read his post as saying that he tried all those values and always "the problem [occurs] anyway", but who knows.
Your correct it's a PhysX issue, although, surfaces such as the ones in the example don't often exist in real life let alone games, and to realistically simulate that will take a lot more cycles of CPU time, however, you could use several options, if I really wanted to achieve the above though, I'd probably write my own cylinder collider and write the tyre frictions from scratch, this is breaking out from game physics and heading toward realism physics.
I think James was more replying to this part and not the going through:
Could maybe keep the default wheel collider but use cylinder colliders for the ground. i.e. Keep it looking like the vertical jump it is but in reality smooth it out a bit.
For those who are thinking that I am a beginner, and therefore was using a high value for the mass of the wheels, know that you are very wrong! I have 3 years experience in programming and am currently developing a complete vehicle system, with the intent to distribute it free to all.
I do tutorials for Unity, and have more than 4,000 subscribers to my channel.
Anyway, my question is advanced, there is a common mistake to be committed. I tested different values in different situations, and even the project that comes along with Unity showed strange behavior when the wheel hits square objects.
Did you read my comments Marcos? You'll be able to improve it somewhat if you don't mind smoothing out the colliders to not quite match the vertical jump in the real geometry.
A simple comparison
I'm starting to agree with you JamesLeeNZ... Is he reading our posts?
Marcos, yes, it's an issue with the fact that the wheel collider is a single raycast straight down, combined with the sudden jump in height. You'll be able to improve it somewhat if you don't mind smoothing out the colliders to not quite match the vertical jump in the real geometry. Tweaking your settings can also reduce the bounce, but it'll never go away entirely.
What happens is that I am Brazilian , and I speak only Portuguese fluently . This makes it extremely difficult dialogue to understand for me, especially if it is not written correctly by those who write in English.
Hard to be sure...
Generally I would say your values look ok. Spring/Damper still a little high IMO.
I would have to play with a similar scenario to figure out how to solve the problem.
To solve this, we'd really need to know what he's trying to do and why he's doing this, if it's to trying and create a realistic solid wheel collider no values will help, you'd need to create one from scratch, PhysX is about approximating Physics, not recreating them, if it was about recreating them it would be slow and useless for 99.9% of us!
Try to go through square obstacles with these settings:
WheelCollider wl = GetComponentInChildren<WheelCollider>();
wl.ConfigureVehicleSubsteps(80.0f, 6, 3);
Then try to do the same, but with these settings:
WheelCollider wl = GetComponentInChildren<WheelCollider>();
wl.ConfigureVehicleSubsteps(1000.0f, 1, 1);
It will give to understand what I'm trying to say ...
With the most sensitive simulation, the vehicle just flying in the air, sometimes several meters high, and with the least sensitive simulation, this does not happen.
Google PhysX penalty force, this will explain why.
just adding to the dismay that exists... tried updating my game, Devil's Peak to Unity 5.... not possible... existing car settings are broken... with much effort can kind of make them drivable... but its not the same. All my existing ghost race data and high scores would become meaningless :/ I guess that kills off any new updates to my game They should have left in legacy physics option or something.
Why would you want the old one, the point of upgrading is to use the new features not stick with the old ones.
A year has passed, but the topic is alive
I'm topicstarter and I'm still not able to convert my project to Unity5, although I did have a lot of attempts.
By the way, I want to tell you about my experiments on Unreal Engine.
For the first time a year ago in Unreal Engine I had the same problems with the wheel collider, although they were less noticeable. The car does not fly away into space with the wrong parameters, but only trembling and slightly bounces.
I wrote about this somewhere in the middle of this topic.
Some time later, somewhere near the end of last year, I tried Unreal again and found that the problem was gone!
There is no trembling at any vehicle weight. In UE4 I tried a fatal vehicle mass value for Unity5 of 50 kg ( for WheelCollider's settings for 1500 kg vehicle). There were changes in the acceleration parameters and the suspension became just tougher. That is all! There is no space jumps!
This means that PhysX itself is stable, everything depends on the third-party implementation. Also, if you check out the sources of PhysX you will find a compartibility mode for the WheelCollider in PhysX 3.3.
I do not want to offend Unity engineers, because I do not know the details of their implementation. I do not want to offend anyone either. It was important to find a solution, so I share with you my own investigation.
I would ask the company's engineers to expose compatibility mode, or to share a piece of PhysX 2.8 WheelCollider code to let us make our own implementations.
Currently, this is my project. It is almost complete and will soon become an asset .
The problem was stabilized , just do not understand why Unity engineers do not create a simple smoothing for this unwanted effect.
Remember to remove other's resources before submitting to the Asset Store (the tire skidding loop is originally from Edy's Vehicle Physics)
Thanks for remember. I will not use any material without which there is no authorization for use. For now , I am using resources from other assets for testing only.
Something that has been bothering me the time is the damping of the wheels on uneven terrain such as ramps with few polignos.
My project and the default project that comes with Unity has a poor performance in these situations, as the video shows. Edy design has a much better performance, but because it adds strength directly to the vehicle body instead of using the wheels.
I'm not finding a good solution to this problem, because the simulation is realistic, and if the actual vehicle is placed on an equal ground, probably behave the same way it behaves in my current project. However, I do not want it for a game, so I need to solve this problem, but all kinds of stabilizer that worked out, did not really work. Someone would have any tips?
Suspension Spring: for all vehicles
To pervert the car roll over reduces the suspension distance, i notified in your video the suspension is high.
Use Force App Distance, it is similar to the center of mass , works as stabilizer.
Or better yet, buy the Edy´s package.
My intention is to develop an asset that is free.
The problem in slow motion:
How, it´s the first time i see that behavior on vehicle
The problem most be in your code. You manipulate the wheels collider component via script?
The problem is not in my code, as to the standard Unity project behaves the same way
Strange. Mostly i do racing games and i never see that happen.
use Suspension Spring:
if I use:
ColisoresDasRodas3.ConfigureVehicleSubsteps(1000.0f, 1, 1);
The problem stabilizes a bit, but you must use an absurdly high value for "Sideways Friction - Extremum Slip" to prevent the vehicle is slipping, even when stationary.
I have no problems whit that values and slow motion.
The problem is the ConfigureVehicleSubsteps shake the car, whatever the wheels settings is.
Maybe it's just me, but I can't see anything wrong in that video.
Physics works at fixed time steps of 0.02 sec (50 Hz) by default. In slow motion you see the physics updates.
Rigidbody.interpolate seems not to be enabled, so the vehicle doesn't move smoothly on slow motion. When using interpolation, the vehicle's movement is smooth as the movement is interpolated between each physics step.
Wheels are handled by the physics system, so they get updated on each physics step. Interpolation has no effect here.
You may try decreasing the fixed time step interval to, let's say, 0.01 (100 Hz). Go to Edit > Project Settings > Time. This will double the impact of the physics on the overall performance. You will still have a similar result, just at smaller steps. This behavior is inherent to the physics simulation.
- Rigidbody.interpolate is enabled in video
What impact on game performance if you leave the "Fixed TimeStep" in 0.001f ???
Well, then something else is wrong. I've tested my vehicle in the same situation at ultra-slow time mode and its movement is perfectly smooth.
Physics will require 20x more CPU than the default value.
- The default value of 0.02 is 50 Hz, which means 50 physic iterations per second. This includes computing the rigidbody dynamics, detecting impacts, process joints, etc. 50 times per second.
- 0.001 means 1000 Hz, so all the above is performed 1000 times per second, thus 20x more CPU usage.
Feel free to try it, but watch the profiler for the cpu usage on behalf of the physics.
There are several other Physics tasks. I can find 8 in my profiler window right now:
Here are my results. They've been gathered while simulating a single vehicle in Vehicle Physics Pro. Physics is the orange band in the performance chart. Note the time / fps labels in the chart.
Fixed TimeStep = 0.02
Fixed Timestep = 0.001
lol, About 2~3 times slower