 |
| Where are the inputs? |
So, LightWave 11.6 is out. Looks like it's got some good stuff in
there, but then I run across this...
The Input node.
This is an actual screen capture.
Seriously. I am NOT making that up.
How much thought went into the naming of this? In just ten
seconds, I can come up with over a half dozen better names than this,
and they'd all be more accurate. Let's see...
- Info
- Data
- Parameters
- Details
- Attributes
- Aspects
- Statistics
- Source
There are eight basic terms right there. It wasn't
rocket science, though when they came up with this, there were a
bunch of real rocket scientists with a lot of time on their hands
that could have helped out. If these labels are too vague, then we
can get more descriptive, by adding words like "Master",
"Scene", "Object", "Light", etc., and
come up with an even longer list like this:
- Scene Info
- Scene Data
- Scene Parameters
- Light Data
- Object Parameters
- Object Attributes
- Surface Info
- Master Data
- Scene Stats
All of those names actually relay the kind of information that
this node provides. The name that it was given? Well, you can't
really get any further from its function than that. It's completely
ass-backward from what it does. It cannot be any more wrong.
See those dots down the right side? Those are called outputs, and
it's got a bunch of those. See those dots down the left side? Yeah,
me neither. There aren't any. If there were, they would be called
inputs.
You can even check that in the manual... Oh right... You can't.
Looks like the LW group just has a hard time with words in
general. “Embarrassing” seems to be one of the especially tricky
ones.
Ok, so in the manual for 10, on page 59 to be exact, you
will find this paragraph:
The Node Editor is setup with a logical flow construction from left to right.The colored dots and labels on the left hand side of any node are that nodes inputs.Any dots and labels located on the right hand side of a node are that nodes outputs.Inputs receive information from other nodes in the network while outputs send information.
So, we have a new node, called Input,
that doesn't actually even have any inputs
whatsoever, therefore it does not receive any information. It does,
however, have a bunch of outputs.
I should have seen this
coming, but, apparently, I underestimated the sheer determination the
development crew has developed for inserting stupidity into the software over
the past few years. Hell, even the manual for 11,
er, 10 calls the final nodes – the Surface,
NodalLight, and Deformation nodes that
are always present - Destination
nodes, as you can see on page 54 of the “LightWave 10
– Surfacing and Rendering” manual (which, by the way, uses screen captures of version 9), so doesn't it make sense to call this
new node the Source node?
But no... We get an Input node that doesn't have
inputs. I can already hear the animators bitching about connecting
the input to the, uh, input, and, put the input into the, um,
output...
Oh, for fuck sakes.
Then again, this is an application that managed to get
Forward and Backward, uh, backward! (I
wish I was joking) So, in LightWave's ever-growing legacy of stuff
that's just backward, we can welcome the "Input Node".
Coder 1: I'm adding a new node that you can't get rid of! It's the dog's bollocks!
Coder 2: Swell! What does it do?
Coder 1: Well, it's like the info nodes, but it gets more scene data and other details, including specifics like render threads and other parameters, like motion, screen, and deformation attributes.
Coder 3: Don't we already have tha...
Coder 1: Shut up.
Coder 2: Okay. Sounds great. What should we call it?
Coder 1: I don't know.
Coder 2: Well, what does it do again?
Coder 1: It gets details and other info from the scene data, and outputs those to the other nodes!
Coder 2: I see. That's a lot.
Coder 1: Can we call it the Apple node?
Coder 3: Why would you cal it tha...
Coder 4: I like that, but I think those guys in the big, empty, white stores might have a problem with it. Let's see... It gets details and info and data and stuff and outputs those parameters to the nodes... This is tough... Does it have any inputs?
Coder 1: No. It's all outputs... Ah ha! Let's call it Input! It's got to have at least one input somewhere, right, so let's make that the name!
Coder 3: That doesn't make a lot of sens...
Coder 1: Too late! I coded it! It's in there for all eternity now!
Coder 4: Does it cause compatibility problems?
Coder 1: What are those?
But wait! There's more!
To make things worse, you CANNOT remove this
node. It's always there, in your way when you don't want it, and
there's not a thing you can do about that. Whether you use the
node or not. And whether you use nodes or not.
Yes, you read that right. Even if you don't use nodes, this little
gift continues to give. As if it wasn't bad enough when the Samples
settings were stripped from several nodes and lights, thereby
breaking old assets when they were saved in 11.x, you now have a new
node that's always saved when you save from 11.6.
EVEN IF YOU NEVER USE NODES!
 |
| This should be the new LightWave logo. |
So, when you try to load an object saved from 11.6 into anything
prior to 11.6, you're going to get an error. If you load a scene from
11.6 into earlier versions, you're going to get an error. Get used
to seeing this:
Why?
Because older versions don't have that Input Node
that 11.6
will ALWAYS save. If this is loaded onto an older
farm (something that actually occurs quite frequently in production
since it's generally a bad idea to switch software versions in the
middle of a production, but newer software frequently has some
features that can be utilized, like modeling tools), you just killed
your farm, or at least got your scene kicked off for crashing the
render nodes. That always goes over well with studios and the IT
guys. They love that shit. This has already screwed over at least one
studio that I know of, and they were not happy.
 |
| This may as well be the error message. |
This node will be added to nearly every node network there is in
LightWave – every surface, motion, deformation, etc. - whether you
want it or not, and most likely, you're not going to want it. It's
basically a beefed-up version of Spot Info (a sensible
name), with the caveat that you cannot remove it or copy it to
make your nodes neater. Spot Info is one of those
nodes that are very specialized. Most people won't have much use for
it, so it's a relatively rarely used node, especially for surfacing.
That is not to say it's not useful – it's very useful –
but those uses tend to be more rare than, say, adding an image or a
texture to something. For most people, this will just constantly get
in the way, taking up space and doing absolutely nothing but being
frustrating.
If you load an older asset, this node will be dropped into nearly
every node network in it; even nodes that have already been set up.
Yes, this node will just add itself to your existing node networks,
and sit there doing nothing other than take up space and look messy.
Basically, it's like LightWave is shitting all over your work. They
might as well have made the node look like this:
 |
| And it could leave brown smears when you move it. |
The solution? Well, personally, I would have had this node just
act like other nodes, where you are able to delete it, so it's not
always saved. Hell, I expect some minor, occasional incompatibilities
with new features, but being forced to have them on all the
time is just stupid. The Spot Info node kept gaining
new outputs with each release, but at least it wasn't used on
every... damned... node graph... always. It was only saved if you
actually added it, and even then, the only time you would have a
problem is if you used one of the newer outputs on it (or should
these be called inputs now?) and tried to load it in older versions;
basically a fairly rare situation, considering the extremely specific
nature of those newer inputs.
But this thing is saved all the time, and for no good reason. We
already know that it's CREATED internally on virtually
every node graph (some don't have this at all), so it doesn't need to
be saved in the first place. It even checks to see if the asset has
it referenced when it's loaded, so it knows whether to add itself or
not. The only information that's saved when it's not in use is the
node's position. That's not important, since, again, this thing gets
created - and positioned - internally, and if it's not being used anywhere, then what's
the point of saving it? It doesn't have any settings that can be
changed, other than the position. The only time this thing should be
saved is if it's connected to something.
And we're supposed to believe that the programmers that managed to
write that entire node system (which is in fact, basically
brilliant), and all those fancy shading and rendering methods, are
not able to find some way of doing a simple check to see if something
is in use or not, and then save it only if it is in use. It appears
that we are. Either that, or they really just don't give a damn.
 |
| Also doesn't give a damn. |
The LW3D Group's solution? A dummy node. Again, I doubt they
actually spent as much time thinking about how that would work as
they would on a good fart. The idea is you install a plug-in on
older versions. This plug-in makes a fake Input node,
to get around that error that the Input Node will now
cause on older versions of LightWave. Again, IT people love that
kind of crap.
Who would need this node?
Anyone that hasn't installed 11.6.
Who would NOT have this node?
Anyone that hasn't installed 11.6.
Who would NOT KNOW about this node?
Anyone that hasn't installed 11.6.
When they get this:
It's a little secret tool that you need to hunt down on the
LightWave website. It doesn't ship with 11.6. It's not even a
separate plug-in file you can find in your 11.6 installation and just
copy over. No, that would be too convenient. You have to look for it online.
The final insult... You cannot copy & paste this node. The inconsistency continues on. Unlike the other info nodes, there can only ever be one Input Node. Where you can make copies of other nodes to keep things neat & tidy, this is forbidden here. At least they haven't removed the Spot Info node (yet), so we at least still have that capability with that. And the amazing Input Node goes one further... You can't use it in a Compound Node. Those have their own special Input and Output nodes, and yes, they are named backwards too.
So, 11.6 breaks compatibility again, and this time, goes for the
gusto.
And as with other labeling issues, don't expect to see this fixed
any time soon. Nodes are apparently written in stone and it doesn't
seem like there's a programmer in the group that's got the coding
skillz to change them once they've been carved.
FFU SCORE:
INCONSISTENCY SCORE: 3.5
Adds itself, poorly named, cannot be deleted, breaks compatibility.