Unity 4.5: the death knell to your open bugs.

Well, that's it folks. Major bugs you've reported are now sliding into the "won't be fixed" basket. I had my major bug (530015) confirmed as fixed... in Unity 5. Pretty sad since it first broke in 4.0.1 over a year ago.

Are your major bugs all fixed?

 

Maybe you missed it, but they did say that if you find a bug that's been marked as fixed has not in fact been fixed you should report it again as a new bug.

 

I don't see any mention of Unity 5. Where did you get that info?

 

Quite a few of mine were, yes.

If yours aren't, please re-submit them and re-post in the issue tracker, then post a link here, I'll give you all my votes.

 

Isn't there a "fixed in a future version" tag for bugs? I though that it was there...

 

The User has to buy version 5 now to get a bug fix ?

 

I kinda had a feeling this might be the case. PhysX's old cloth implementation was kinda all over the map and was fragile in even the most controlled of settings.

 

I just want to ask one thing.

In some other threads it was said that one should not upgrade the unity if one is in the middle of the project/close to release. Then here you've said that not all bugs are backported. When I'm using the not-up-to-date version and encountered bug that will be no backported, it could be showstopper for me, what should I do? I'm not talking about some minor fixes. But some bugs that may exist for a long time etc.

Also I would be interested in your policy of backport/suppor of the last major version. Majority of project (mainly libs, but also standalone apps) I've been using supported the last major version for bug fixing. That is if the current major is 4.X then the 3.Z (where Z is the last minor version) should be supported for the bug fixing at least for the 4.X lifetime. Then I could be sure that if some bad bug happens it could be solved relatively easy and not to upgrade to the next major version which could bring some other problems.

Thank you

 

As the other commenter in the issue tracker reported, this is just that way in the minimum reportable case. In my real case, it's totally broken. SkinnedCloth doesn't work, and hasn't since Unity 4.0.0. I have tested it every release. The optimized mesh point was to show you exactly how to reproduce the problem with the test case.

Yes, your priorities are different to mine: you need the next version to be awesome, while I need the current version to be awesome, I understand that. It doesn't change the frustration of waiting a year to be finally told "nope, won't fix, it had to be rewritten". I hope you can at least understand Hope frustrating that is.

 

Except this was a regression in a minor patch release of Unity. I'm pretty sure it worked in 4.0.0 and broke in 4.0.1, though it was a while ago so I could be wrong. Certainly it worked in the last Unity 3 release and all worked fine until the first time I touched my SkinnedMesh with the SkinnedMesh editor in Unity 4, though it may just have worked because it still had correct data from Unity 3.

 

Thank you!

 

Yeah, and I'm saying that PhysX cloth through the entire cycle that Unity was working with was incredibly prone to just outright breaking and never working again unless you made sure the conditions it was used in were almost always the same. It's one of the reasons we really weren't seeing a whole lot of cloth simulations for things other than flags in games made even outside of Unity.

It's one of those regressions where it's a little understandable, unfortunately.

 

What version of Unity doesn't pass iOS store? I'd heard below 4.2 was problematic, but I published an app with unity 4.1.5 and it passed first try no problem.....

 

I've taken the time to report a couple of bugs in 2014. I've taken the time to create and send sample projects, and steps to reproduce. These bugs are listed as Open. Now that 4.5 is out will they ever be addressed?

 

What does 'Open' actually mean?

My bug history shows that since August 2011 I have submitted 23 bugs with 19 'Open' and 4 'Closed'. If there were more states of progress it would probably make things a bit better. I don't even know if someone at Unity has even glanced at any of the open bugs. I would likely feel a bit better if I simply got a message that confirmed that a reported bug was actually reproduced, thus telling me that I wasn't doing something wrong.

 

The bug is a regression, but not even marked as such. That means that somewhere in your VCS history is a change where my fully reproducible bug breaks upon that one change. The cause can be found in under 20 checkout tests. The bug is also in functionality that you advertise as a major feature of the engine, but which basically no longer works in the only shipping version, thanks to this bug.

If that's not a bug worth fixing, what is?

And no, I'm told my bug will not be fixed until 5.0, not that it might be fixed in 4.6.x. Other people might be lucky, and while this might not be the end of the end, it's certainly well past the beginning of the end of Unity 4 bug fixing, if such bugs are abandoned, hence I feel my title is quite accurate - the final burial comes *after* the death knell.

 

Waz,

Usually I would agree this is a big issue but in this case, I don't because:

1. Physx 2.x cloth is what is actually buggy. That thing is never used by game developers. Unity probably only included it because they knew people would moan if it wasn't included.

2. The Physx 3.x cloth is a rewrite and is actually quite good.

To fix the 'bugs', unity would have to replace all of Physx inside 4.x, breaking everyone's projects in the world that use Physx. As you can understand, it's simply not doable in this case.

Cloth being bad in Physx 2.x is widely documented on the web; no game developers will touch it. Which is the reason for middleware like shroud etc (which I totally recommend as a drop in replacement for your situation).

In short, Unity cloth has never been that usable, and http://www.cloak-works.com/ is a really great alternative used by AAA. If I were to add cloth, I would get that. It is also free if you do not have many cloth simulations

 

I was wondering if you had approached sales about possibly getting a free copy of 5.0 and perhaps beta access due to the circumstances of your showstopper?

 

You said you think it's a regression. But you haven't actually tested that?

http://unity3d.com/unity/download/archive

There's the old versions. Why not give 4.0.0 a run and see if it really is a regression or not? If it is, then update your ticket with all the pertinent information and maybe there's a way they can track that info down, rather than waiting for the next major version.

As it stands, Unity Tech is obviously confident they can't fix the bug in this version. Everything they've said makes perfect sense, too.

 

As someone that has never used cloth would cloth in Unity 5 be suitable as replacements for polygon meshes for all hair and clothing? Would you need to restrict the number of characters to say 1 or 2? Could cloth simulate fox hair for example?

 

But it's not the users fault that it is broken. When a feature is included in the list of official features, then it should not only work on the paper. The user has bought a product with working cloth physics. And when it is broken in one main version, then it should be fixed in exactly this main version. The user should not be forced to buy the next version to get his bug fixed. So i know exactly where Waz is coming from.

When it would be one or two features, no problem. Some bugs are really hard to catch. But those never fixed show stoppers are no exception anymore, unfortunately. They become the rule. That's the result of the "we don't fix every bug" politics.

There's a good reason that Unity 4.5 was a heavy bug fix release. Let's hope Unity has understood the problem now.

 

Is anyone else getting a lot of internal compiler errors in 4.5? I never had one before, and right after updating to 4.5, I get them about every 10th time I save a script.

I can close Unity and relaunch it, and everything works fine for a little longer.

 

Unity will fix regressions usually, but unless this is actually a regression, they won't. Shroud is so much better anyway, than Physx Cloth, so there's no compelling reason not to use Shroud: it's not passing the buck, it's just flat out better in all respects. I'm not even sure Physx 3.x is better than Shroud as it stands either.

@Goat: can't comment on Unity 5.

 

Shroud hasn't seen any updates since the initial release and doesn't support any runtime modification of the parameters, so you can't use it for anything adjustable or even add a new collider so it can interact with the environment. There really isn't a fully featured cloth sim available for Unity currently, so hopefully the Unity 5 cloth will at least be a step in the right direction.

As for this particular bug it sounds like there is a workaround, but I'm amazed you ever had the existing cloth working for anything more complex than a demo, it has always been horribly buggy.

 

Not sure how I feel about this topic. Because I always thought Unity's Skinned Cloth was incomplete, mostly undocumented, and was getting a major rewrite in Unity 5. Last time I looked at youtube I could only find one video where a guy claimed he got skinned cloth to work with his rig. Maybe I had terrible luck though since I tried to use it with a Mecanim humanoid rig. Perhaps it actually works on non-mecanim rigs

 

It's a bug in the editor, not physx runtime. It's clearly just that the skin data is making assumptions about the mesh data that are no longer valid.

Compelling reason not to use shroud: this was all working fine in Unity 3, porting to Shroud just because Unity degrades? That is absolutely passing the buck, and pure apologetics. I paid for Unity 4. What did I get?

There is no workaround - that's UT not understanding that a cut-down example won't show all possible consequences of a bug. It's like when someone posts an abstract example on StackExchange and some newb replies that "if all you're doing is printing hello world, you don't need a class definition anyway" ... groan.

 

That's OK, I was thinking along the lines of procedural clothing UMA characters and giving them hair but that be a ton to learn anyway for me but since I don't have to fight with GUI soon gotta do something.

 

You should at least get a refund for your broken product you purchased!

 

SW EULAs always have the caveat that they're not fit to be used for what they were designed for.

Maybe not to encourage negligence on the part of the designers but to discourage negligence on the part of the users. And to avoiding spending too much of your life fussing over the past rather than tending to the future.

That's the SW industry SOP. When you publish you will have a similar EULA.

 

Just out of curiosity - what makes this cloth simulation so extremely vital for your project?
Also if it is such an integral point of the whole project: why do you insist on setteling for an inferior technology that is apparently known to be very volatile to begin with?

 

It's not vital. But it was in the previous version and added to the immersion, making the character feel more alive. Old time players are still asking what happened and when is it coming back.

Skinned Cloth worked fine and well in Unity 3, that's why I happily used it. I've no idea why people think it was undocumented - I find the documentation for it perfectly fine. As for it being "known to be volatile", it's still advertised on the Unity "Quality" pages - Interactive and Skinned cloth are the first links on http://unity3d.com/unity/quality/physics! I don't see anywhere there that says "Note: cloth stopped working a year ago and won't been fixed in the current version.".

The bug is clearly not in PhysX, so the buck can't be passed there if that's what you meant by "known" (even if it was, that PhysX version predates Unity 4 by a year and a half), it's clearly in the Editor in the UI to define the coefficients to be passed to the engine, it looks perhaps to be in any case where the number of verts in the model is different to the number of *distinct point positions* in the model (i.e. any model that uses seams of any kind - almost anything but the most trivial of models reveals it).

 

I have to support Waz here and say that UT is shirking their responsibility to fix this bug by claiming that is is a PhysX problem when it clearly is not. Sad to see Hippocoder jumping on board with UT for this. UT should just admit the problem and fix it.

 

That's not a compelling reason, it's the sunk cost fallacy.

I fully understand, and I'd be pissed too. But, honestly, being stubbornly pissed about it isn't going to get your game shipped. No amount of complaining on the forum is going to get this fixed for you.

Pragmatically speaking, depending on how far off your game is I'd recommend one of the suggestions already given here - contact sales and support to see if you can get your issue resolved with an upgrade to 5.x, or plug in a 3rd party solution and ship your game. If you never want to give Unity another cent then that's up to you, but don't let it spoil your current work.

 

I think we all understood that you are frustrated by now. You iterate that in each and every post of yours.
It seems that you have by far reached the point where you are putting way more energy into each iteration of why you think you are right and why you dislike Unity for it, though.

Okay - from what I've gathered it's for a fantasy game and specifically for the character's robe, correct?

Now I haven't ever worked with Physx cloth so I can't comment on any of the problems you are having or what causes them (even though I do believe hippocoder and Unity in what they are saying). I know that other products that integrated really awesome cape physics needed to have people work on it full time to have it work. This does not change the fact that you will probably not be getting this thing fixed. Why don't you put energy into working around it some other way?

So from your bug report and the infos you've given I see three possible solutions ...

1. (this is the one I am just guessing since I don't have access to the model or project of yours):

... if it works with the model unoptimized: Why can't you just use said model unoptimized?

2. If the cape is integral enough for you then go for shroud. By all means - do it if you want physics at all costs.

3. Thrid approach - which would probably be my approach to it in this case I don't have a 24/7 cape physicist:
Just rig the damn thing and animatite it by hand or ragdoll/chain physics!!!! Will it look the same way like a physics cloth does? No. Will it cause you less trouble? Certainly.
A rigged cape approach can even be used on modular items. If the character is not wearing a cape item just leave the bones blank and don't bind them with anything. If DOTA2 can do it - so can you:



Is there any solution for you in there?

 

I first shipped a year ago - it's a project I continue to build on and support, not the usual one-shot fire-and-forget. Unity breaking the feature meant I had to disable it, disappointing customers. By this time, reverting to Unity3 was too late - I had already ported and shipped on iOS (cloth is disabled on mobile anyway for performance reasons).

Sure, there are other cloth solutions I could put my time into rather than improving other aspects of the game. But that is sinking costs in advance - it has always been more sensible to wait two or three more months for a new Unity version in the hope Unity fixes their bug (I do not have a crystal ball). As others have commented, having better visibility to bug processing helps us make better business decisions.

Those making excuses for cloth not working should come up with an apology for why it's okay to be on the advertised features list of Unity 4.

(Edit: Clarifying while avoiding bumping: I meant the more formal definition of apology, not the one interpreted below)

 

Allright ... I give up. Congratulations.

 

An apology isn't used to justify transgressions they're used to, well, apologize for transgressions. It's up to the victim to move on when they don't have any legal recourse. The apologizer has already moved on as stated.

 

Never rely on promises. Promises are hard to implement. And tend to give a compiler error at best