Can't Make Up Its Mind Whether It's Incoming Or Outgoing

Or a big "Fuck you", five years in the making.

I wish they would make up their minds about whether something is a bug or not.

When the Gradient node was introduced, people complained it worked backward. For example, if you create five keys of different colors in a regular gradient, and set the key type of the middle key to Stepped, that key will instantly change values. There would be a sharp change on that key. That's because regular gradients in LightWave affect the incoming curve, just like the Graph Editor.

Not so with the Gradient node when it was added in 2006. If you did the same set up in that, and set the middle key to Stepped, the actual change would happen on the next key. The sharp change in color would happen on the fourth key, not the third one. That's because this gradient works on Outgoing curves.

The Gradient Node in 10.0, displaying its sense of inconsistency.

Obviously, this was completely inconsistent with how other gradients worked everywhere else in LightWave...
A regular Gradient layer.

It's almost like there's this strange entity - let's call him Mr. Inconsistency - that keeps putting stupid stuff into the program, a lot like this guy.
That logo looks oddly familiar...

When this inconsistency was brought to the attention of the developers, people were told that this is just how this node works. It's different and it's new, and it's not a bug. It was made this way on purpose, essentially. You see, inconsistency seems to be a design goal in LightWave.  I wish I could find the forum posts about this, but those have all vanished.

Now, fast forward to 2011, to a time where node users have had five years to become accustomed to this node. That's five years worth of assets that have had the opportunity to take advantage of this node, which is one of the most useful and common nodes to use. That's a lot of assets and a lot of familiarity with something that was specifically stated to work as it was intended.

The 'fixed' Gradient Node.  Can you spot the difference?  Right, who could?

Well, until it was secretly decided it should be changed. With LightWave 10.1, the developer secretly changed this node so it now works like all the other gradients. That is, it now works on the incoming curves. There was no mention of this anywhere; nothing in the release notes, nothing in the manual (whoops, no manual for LW11), nothing. Not even a damned readme file.

So what's the problem? Anyone that uses different key types now has a gradient that looks different from when it was originally set up.

That means that any assets created in the past five years, that used this node, will probably not render correctly anymore. Now, just to be clear, you can expect some minor changes to rendering, especially from one major version to another, but this change occurred with version 10.1, not on 10.0. And as I mentioned, not a word was mentioned about this change to anyone either.

It was a surprise.

As in, “Surprise! We fucked up your stuff for you and you get to hunt through every damned node graph you ever made to find out where!”

Because, in production, you just have all kinds of time to do shit like that.

So one day, about two years ago, I'm talking to the owner of a studio I used to work at. I did some stuff there and I used that gradient to create an effect. It was beautiful. After I was gone, he needed to render some more shots using that same effect, but he had since upgraded the studio to 10.1 or 11. Naturally, that effect no longer rendered correctly. He had no idea why (neither did I), and mentioned he had to set the entire farm back to 9.6 to get that job done. The LightWave group is apparently very comfortable about this too.

I can understand fixing something that's rendering wrong, but to openly defend it first as being wrong by design, and then waiting several years before actually fixing it is unacceptable. Not telling anyone about it is insulting, and the method used to fix it was nothing short of stupid.

First of all, this kind of fix should have been brought to the users' attention, either in a forum, or at least in the documentation, though since there's little of that for 11, that pretty much leaves us with the forum. The forum that many people in studios just don't have time to keep up with. But it would at least be something.

The developer had to know this would cause problems, especially after the node had over five years to propagate through production. Secretly changing it like this showed an utter lack of consideration for the users, and lazy programming as well. There were other, less disruptive options that could have been used to do this fix that would not harm anyone. Here's three, off the top of my head:
  1. A second Gradient node could have been added, and the old one moved to a legacy menu location. This way, new assets would tend to have the new Gradient since the older one would be less accessible. Older assets would still work because the old node is still present. This would be much like the old Kappa nodes and Omega, which are now hidden in a Legacy submenu.
  2. The Gradient node could have had a new option added to define which way it worked, and defaulted to the old way if an older asset was loaded. It would just take a simple flag and a check to see if that flag was present. If it was missing treat it the old way. If it's present, then read it and find out which way the keys should work.
  3. A combination of these two. Make a new gradient that lets the user decide which way the keys work, and place the old, current one in a legacy location.

I must have spent literally minutes coming up with these safer, more user-friendly solutions. I wonder how much time the developer spent on the solution we got.

What you do not do: Wait five fucking years and secretly change it in such a fashion as to maximize the damage, and force studios to go back a few versions to get their stuff done. That's something that 11.6 has made even harder to do since it craps over all the assets with the Turd Node.