Hundreds of US Dollars Wasted and In the Drain? [WheelCollider]

My suspicions have finally been confirmed.

Our team has several hundreds of U.S. dollars (> $500.00 USD) worth of vehicle scripts and assets, and almost every single one of them is completely useless in Unity 5.

A number of these assets are in DLL format, and others are a few years old and unsupported.

This is not good news at all.

 

It's simple, if that is so important to you, don't upgrade to Unity 5. The PhysX upgrade had to be done, the performance sucked. This is one of the downsides...

 

closed source assets can be a dangerous gamble.

 

That ignores the fact that UnityCar and even Unity's own Car Tutorial (before the Sample Assets version) work with both Unity 4 and 5. As well as the fact that Unity 4 is no longer supported.

An even bigger gamble moving forward with IL2CPP.

 

I don't think it's a waste... It's like saying I bought a game on Xbox 360, and then someone gave me an Xbox One for free. I still have the 360, so just because my game doesn't play on the new system, doesn't mean I can't continue using it on the old system.

 

It doesn't matter why it doesn't work, you can't change the code of the assets and there is nothing that can be done.

 

The issue here is when an amateur developer starts spending a lot of money she or he assumes wrongly that technology won't change. For a start, only buy assets which do have source. Or invest in your own solutions. You can mimic the behaviour of the original wheel colliders if you have source or the interest to do so. If that isn't happening, shouldn't you blame the asset authors? it's their responsibility after all to remain current.

 

I'm sorry your having such struggles but as suggested, maybe it's not a good idea to update your project to Unity 5.

Having custom built DLL's especially if they're old is risky to try and upgrade, we try and make upgrading relatively painless but we can't account for absolutely everything. This goes triple for major releases and the fact that we have upgraded our physics and so much more.

 

What makes you think so? If it wasn't supported they wouldn't be continuing with new 4.6 releases.

--Eric

 

Wrong. The issue is that WheelCollider dates back to at least 2008 (when I started using Unity). Was the older WheelCollider perfect? Far from it. But it would've been fair to assume that it wouldn't change its fundamental behavior anymore than a BoxCollider or Capsule Collider.

Except where did I indicate I'm "struggling"? I've only raised attention to an issue that only seems to affect one or two physics components, and the many projects (not just my own) that depend on such components working as they've worked for several years.

 

I stand corrected. I wasn't aware of Unity 4 continuing past 4.6.3.

 

They do what they can to avoid it, but occasionally stuff has to break in order to make progress. It's happened before and I'm sure it will happen again. (Not with the .x releases, but the big X.0 releases...that's the time to expect it.) The alternative is being chained to old suboptimal stuff forever.

--Eric

 

Not upgrading is the best solution.

A major version change always introduces breaking changes. Its up to you to judge if 5 is worth more then the value of lost assets and project fixes. Its quite common for studios to stay on the version of Unity they have until a project is complete, then upgrade between projects.

If 5.0 didn't introduce breaking changes it would be called 4.7

 

sounds like my rts project will need some work to bring back up to speed. lots of wheelcolliders.

luckily I did all the code using them myself, so only a few hours lost hopefully.

 

It's only a waste if you approached it in such a way that you / your programmers can't translate the logic between versions. What use is something like that anywhere unless UT were to announce that Unity x.x is the final version?

I wish everyone followed this. The only thing blizzard breaks when they label something 2.0 or 3.0 are hopes and dreams.

 

It's not a matter of translating logic (at the scripting level). The tire friction model of the new Wheel Collider is completely revamped.

Exactly. I should know. Yet, of the all the DLL's we have, it had to be one with wheel colliders that break. Interestingly, the one or two closed/compiled shaders and rendering plugins we have are working without problem.

 

Unity uses PhysX for it's Physics and Unity 4 uses an old 2.X version. PhysX had a big rewrite for version 3, which included big changes to the vehicle model. The alternative to upgrading PhysX and breaking compatibility was to stay on the old (and slow) PhysX forever.

 

Yes, there was quite a buzz about the PhysX upgrade. And what would a company like NVIDIA care about backwards compatibility? The preferable approach would've been a Wheel Collider implemented in C# using ray casts, rather than the assortment of Nvidia PhysX vehicle APIs.

 

If some of the assets are more than a year old, hopefully you've re-couped their value with sales!

Maybe you can reverse engineer the DLL's for studying purposes?

Also, here is a good start if you haven't seen it already

 

Unity can't be responsible for other developer's DLL's. Those developers are responsible for updating their code & DLL's to work with future versions. Have you sent them an e-mail, IM or called them to ask them to update their stuff?

I know that isn't what you want to hear, and I can feel your pain, but taking in assets that you do not have the source code to is a risk.

 

Are you able to do that yourself? I know it's a pain, but if other aspects of 5.x are of interest to you then maybe it'll be worth it? As far as I'm aware it's fairly standard/documented math under the hood.

 

"Hundreds of US Dollars Wasted and In the Drain?"
You may want to rephrase that - makes it pretty clear who's to blame.

 

Preferable to you, maybe. A raycast-dependent C# wheel collider sounds pretty durn slow to me.

Backwards compatibility in major releases should never be assumed. Bad investments happen. You can either blame Unity's makers, or learn why you made a bad investment and avoid it in the future.

 

It's probably comparatively slow, but it's also probably still more than fast enough. Plenty of wheel collider implementations are (used to be? Haven't used one for years) based on raycasts, and you typically won't need a huge number of them.

 

Put together a bunch of stuff that is just "fast enough", and the end result will be something that isn't fast enough.

 

No way. That's kind of the definition of not being "fast enough". By "fast enough" I mean "meets the performance requirements for the required aspect of the overall project". Anything else isn't "fast enough", it's a "random guess".

In any case, Master Thief has more raycasting than would be needed for wheels in the average racing game, and that runs great on 6 year old mobile hardware.

 

Great news for makers of average racing games

 

I know, right...

The actual nerve of me to buy couple of assets, then somehow expect them work even somewhat properly in a subsequent version.

Ludicrous!

 

A subesquent version that didn't exist at the time you purchased them, though?

I certainly can't promise that my software will work on a thing I don't know about yet. My crystal ball just never seems to work when I try.

I'm being held up in porting one of my old games to PSM because of incompatibilities between a 3rd party asset and Unity 4.3 for PSM. Unity for PSM didn't exist when I bought the asset, and nor in fact did Unity 4. Is it the asset developer's fault that I'll have to work around that? I don't think so.

Or, y'know, anyone targeting hardware newer than an iPhone 3GS.

 

Well the WheelCollider up until v5.0 worked without any fundamental changes since v2.x (at least from what I remember). Sure, PhysX had to be upgraded, but I felt they could've offered some legacy upgrades, just as they did for legacy shaders and legacy coding conventions.

Anyway, lamenting time over, time to get on with it.

 

Major version releases breaks compatibility, I would understand your complain if this was a minor version update.
You have to break a couple of eggs to make an omelette, and it is necessary to change things to make them better.

I think It was very necessary a change in that old and buggy WheelCollider implementation.

 

Yeah, since it was the same PhysX version all that time, and people kept bugging them for a new version. So here it is.

--Eric