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.
Well guys, if you can't actually reproduce 4 behaviour for things like slopes, you should file a bug
Did anyone try to use the Sample Assets project as a basis and tweak the wheel colliders in there to get as close as possible to the desired behavior?
Seems im screwed. Went with an out of the box motorcycle controller (MSK) in order to hit our deadline. Worked great in 4.6. Upgraded to 5.0 because hell our game is stupid simple and I should be able to fix any problems with my own scripts right?
Turns out freaking wheel colliders are borked and the dev doesn't have a forum page nor responds to emails. I cannot even run the game right now because it crashes after 5 seconds of demonic wheel bouncing. Other vehicle asset devs are not including motorcycles because of problems they can't even solve.
Even though I did backup and have a 4.6 copy I want to use 5.0 for performance and lighting reasons.
Sigh, looks like that deadline is getting missed...
Sorry to hear that, but why the hell did you even consider to upgrade when you are close to the dead line? Major version updates almost always contain breaking functionality.
I would never consider upgrading any application or code base in the middle of a project.
At least for mobile, the lighting on Unity 5 is broken, and the performance is poor across a number of devices. I had a clue of this when I read through the Beta forum and saw that a lot of the concerns on mobile weren't addressed.
Have you tried replacing the default Wheel Collider that the asset uses with the open source version from the Unity Wiki? I think it's better to stick with version 4.6, but if version 5 is a must-have, it's worth a look, it's not perfect, but it's a good start.
Thank y'all for your responses. My deadline is self set so I am not in trouble if I miss it.
I upgraded because my game idea is super simple and I am only a few weeks in so I thought I could use it to learn unity 5.
The author of msk has gotten back to me, his message was sent to the junk folder, and he intends to upgrade it to 5.0 soon.
I don't think I can use the other wheel collider system because msk creates it's colliders at runtime.
at last i'v interesting in: why Unity use PhysX and stay with them? Maybe, it's non 100% correct way? Just simple thougts...
PhysX is a leading physics engine which is incredibly fast and portable. As almost all those kinds of software, it breaks the compatibility when major upgrades are made. And when the compatibility is not preserved 100%, there are people who want to have the performance improvements and a complete compatibility, even though they are mutually exclusive.
I don't think people here bicker over backward compatibility, they bicker over the fact that the new wheel collider is simply broken and even when used in a new project, with no old code, it's still pretty much impossible to set it up realistically.
If you e.g. try the Sample Assets, you see that it can somehow work. It is not completely broken, but definitely not really good and anything but compatible. Saying it is completely broken is just not true, it works for the use case it was created for.
Edit: With PhysX as it exists right now, it is possible to create an amazing WheelCollider without relying on the existing one, because the basis is absolutely solid and there is clearly no justification to remove PhysX.
Try to change the mass of the car in that sample project. The physics is broken for everything except simplest arcades. And the remark for your previous post about PhysX leading. Please, try Havok and then I'll ask you about PhysX leading and icredibly speed.
I wrote that the WheelCollider works for the use cases it was designed for. That is clearly not generic at all. I am sure that not everyone had a careful look at the settings and tried to adjust them based on something that works.
I am not going to discuss PhysX versus Havok. I consciously wrote a leading engine and not the leading engine, because I don't want this kind of discussion. From the context it should be clear that I meant, there is not enough evidence to justify a replacement of PhysX.
so, we turned to origins of problem:
1 - PhysiX realy great, and, they do all in correct way. So, Unity makes all sets uncorrect, tested (in Beta) by one eye and one leg while sleeping. Result - Unity fail.
2 - PhysiX do some unforgiveable sin in code, and, give it to humanity. So, Unity take it and use... But, make new version of realy powerfull game engine, 3D game engine, with uncorrect-working physics - not nice. Result - Unity fail.
3 - PhysiX and Unity fails with physics-making magic...
At last, i'v don't think, that this situation was realy as unforseen consequences. Need fix.
No one is trying to say there are no bugs, but it is also not a complete failure. The only productive way to deal with it from our side as Unity users is to submit usable bug reports about the issues.
Making this kind of controversial statements where everything is black and white helps no one and is not productive at all.
Hmm. Not a complete failure... realy powerfull game engine, with ruind physics - as for me - not complete, but, realy massiv failure. If it be a little bug, and u can work forward and skip it - ok, it's a little fail. But this, it's like u lost u'r leg and arm - hardly unpoductive point. And, at last, noone say -"Hey, wait 2weeks, we will fix it. keep moving forward" - ok, not a problem, but, now i'v realy don't know - how long i'v need wait and wat i'v need to wait - what and how it'll be fixed?
Did you submit bug reports for the issues you encountered?
Because of the performance increase in U5s physics I decided to bite the bullet and upgrade my main project. When doing so, I sort of did that - I used the Sample Assets vehicle scripts and combined them with my U4 scripts. Almost works as desired, after hours (& hours) of tweaking. Some things are not quite as desired and some things are improved. Will need more tweaking but it is good enough for me and my team to use and move forward with U5.
no, coz this problem i'v can't show as correct problem. When i got network problems in u5rc3, i'v show exectly points of problem, but, with wheel collider, it gets like - "I'v can't do it nice" but "nice" isn't a param \ value, so this bugreport gose useless and jast take out some time with no result. Another problem - privation contract - i'v can't send models \etc for enyone (bugreport too) so, it's a problem. And i'v get no time to make same physical models and sent them, coz time = money... One hope - they reeds forum.
Unlikely. I've made the WheelColliders' suspension to work correctly by using an ugly hack that goes directly against the PhysX design. PhysX insisted theirs is the way to go, and Unity integrates whatever PhysX gives them. So far, a correctly working WheelCollider will be part of my Vehicle Physics projects.
Right. The new WheelCollider works that way by design. But that doesn't mean that the simulation is right. IMHO the design is a bad design because the component works correctly when used under specific (artificially imposed) conditions only, causing the exposed issues in all others. This makes the PhysX wheel unusable as generic wheel component.
My fix/hack voids part of the PhysX design, resulting in the artificially imposed requirements being eradicated. Under this fix, the suspension works nicely in the exact way everyone expects with absolutely no artifacts, just like in Unity 4, but with the precision and optimization of the new PhysX.
With my fix applied I've been able to set up vehicles with as little mass as 10 Kg, each wheel supporting 2.5 Kg. Fully stable, nice and realistic. Same with heavy mass vehicles (25000+ Kg). The only difference between these cases was the spring / dampers values.
My mid-term goal is to implement my own suspension and abandon the Unity WheelCollider definitely.
Not sure why you need to submit any models to show issues with the wheel collider. As you know there are a lot of parameters that can be tweaked and as such a reproduction is invaluable, because I don't expect the Unity engineers to waste their time trying to reproduce issues.
Complaining about bugs is completely useless, unless you submit a bug report.
Model - for physical simulation, coz simulation on cube + 4 WC and non-standart physical-collision mesh with lots of settings and 8 wheels - not same. When gets freetime - will try to make same physical bugs and send bugreport.
absolute same dubstep party gets with my veh... try submit bugreport. 1-2 days i'll do same.
That's good news. Will this change become available to Edy's Vehicle Physics?
Just curious, are you ever going to add motorcycles to your unity 5 vehicle pro asset?
I hate to say it but I find the V5 one much better and easier to get results, of course if you are upgrading code from V4 it won't work an ounce without you removing every like hack and workaround you had for V4. But if you had a project near completion in V4, then upgrading would be silly.
I do find it ironic though, pre-V5 everyone complains about PhysX, why does Unity not upgrade it, post-V5 everyone complains about PhysX, why did Unity upgrade it.
Edy's Vehicle Physics for Unity 5 will still use the stock WheelCollider, but will include the fix for the suspension to work properly. Same with the upcoming Vehicle Physics Pro package.
It will be an add-on to the Pro asset. The plan is begin working on it after Pro has been completed and released.
Indeed. I find it a shame that PhysX has chosen so bad path with regards to vehicle physics. In PhysX 2 the wheel component was unusable due to an internal bug, and once released it was too late to fix it as "users and projects had already got used to it, such change would break actual projects". So they would rework it all for the next major upgrade. Then PhysX 3 comes with a wheel design based on a very questionable basis and applying arbitrary concepts with no physics meaning. It can be used under a very tight range of values and situations, but works awfully in all others as generic wheel component. In my opinion PhysX 3 is (yet another) lost opportunity of having a good vehicle physics simulation in PhysX.
Hm, u get nice vehicle asset, so, maybe, try hard-candy and write new physics engine? Or connect some another phys-engine to Unity? Coz what we got now - realy pathetic...
It seems you don't understand the amount of work that is required to create a physics engine at all. It is possible to create a custom wheel collider that works better than the existing one in PhysX 3 for Unity, that is out of question. But that doesn't mean PhysX is bad and it doesn't mean PhysX needs to be replaced by another physics engine.
nope, understand. Edy + Unity team + 1 - 2.5 year... Yep, it's not simple, it's like walking on minefield, but, Unity team makes realy great work at some parts of engine by themself, so, maybe, it'll be realy good try to make own.
And about PhysX, i'v don't think, that it realy nice as they saying about it. And, main feels -, i'v think that Unity can makes it better. They comes from nowhere and hitdown Unreal's tail, yep, they realy can do nicely physics, i know it.
There is no actual reason to create a custom physics engine. Starting the development of a physics engine just because it might become good would be rather naive and a waste of resources, because there are companies with lots of experience in that field.
Anyway, this is far too off topic and pointless.
I'm sad. I thought it was this time I would finish the race car game. Apparently'll have to wait a little longer for a solution.
I installed the spring 35000 (in 4.6 spring 25000), damper4500 (in 4.6 damper was 1), and my tank with 14 wheels and mass 30000kg works fine.
ps English is not the native language
I'm sorry, but in sample vehicle, physics wheelcollider looks awful. We look forward to hotfix.
no, it's nice for 2$ arcade game, but, i'v take unity not for making 2$ games... We need more, we need fix.
Just a couple of months
I've used the old wheel collider extensively and I'm now working with the new one. With the new one, I found it way easier to create a vehicle with halfway drivable physics, but I haven't been able to actually tweak the physics to find the desired control of the vehicle. Everything is always a bit floaty and the car is sliding around.
I don't really care about a precise physical model, I don't think this is the real problem of the new wheel collider (except if you want to have completely realistic cars). Instead I think the main thing that makes the wheel collider (still!) so hard to work with is the lack of documentation and visual feedback.
Things like "A better vehicle would have forces applied slightly below the vehicle centre of mass." are just hard to understand (what's a "better" vehicle?). Example values for different kinds of vehicles would be very useful.
Having a UI that shows the wheel friction curves and the current values, including suspension data would be necessary to work well with the wheel collider. Currently you don't see what's happening, and the interaction between all the parts is too complex to just play with the values without proper feedback. Of course you can create that yourself (I've started to work on wheel collider visualizations for my project), but all that is probably the reason why many inexperienced wheel collider users have problems with it.
Just want to add my agreement that the new Unity 5 wheel colliders are a bit insane.
Those who vote that "It is suitable for use", please show your settings Forward / Sideways Friсtion, just to understand, what you are really good at it (Physics).
I think it's funny that Edy is an asset creator and trying to fix this issue with the new PhyX but Unity (the company we pay top dollar to) is saying that a broken collider is how it is suppose to work. Fix this issue Unity, you can't just blindly just ignore this, your not EA(Electronic Arts).
Unity makes own UI, nice light and shaders, multiplatform, etc. But, use PhysiX. Still thinking - better try by own hands make new for "Unity-friendly" Physics. yep, it costs time, but...
Unity used the WheelCollider as provided by PhysX. That is not a generic solution for wheels and that's why Unity says this is the way it is supposed to work.
It costs time or is a waste of resources because there are other companies with amazing physics engines. Why should Unity reinvent the wheel?
Unity should keep PhysX but they should also quite possibly reinvent the wheel... component.
Coz wheel works as fish in socks on the moon. Coz " amazing physics engines" raping down projects. Coz we need moving forward and inventing.
According to our logic, Unity needs to replace the physics engine just because of the wheel colliders.
When you have a broken chair, do you decide to create all your furniture from scratch on your own? Wouldn't the way forward be to fix the chair or to buy a new one?
Mr. dantus, you probably do not care about the problem or do you just troll, we do not ask replace all of physics, we want to draw the attention of developers, on the malfunctioning of one of the components in the engine.
It is clear that there is much more important tasks, on which working the developers, but I'm confident that the problem will be solved.
Be assured that I am not trolling. If you have a look at the previous posts of LastLance, you will see that replacing the physics engine was suggested.
I am completely aware that the WheelCollider is not a generic solution that can be tweaked easily and I also believe it should be improved. Some of the critique in this thread is disproportional and not objective in my opinion.
I agree, a general purpose wheel collider independent of the one provided by PhysX, and built using PhysX ray casting, would've been a better strategy.