There *are* three values but the third is just not translated. It's non-associative but present. The result however (an obj is illuminated by a light) is the same as associative-inclusive (in semantics this sounds illogical somehow, but it makes sense work wise). A strictly non associative light would be useless until associated, because it would be identical to associative-exclusive, no? The only case a non-associative light would make sense, is a scene where it doesn't exist. I don't'think that can happen.
sven -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Matt Lind Sent: Tuesday, August 16, 2016 10:35 PM To: [email protected] Subject: RE: redshift materials show gray in viewport I strongly disagree Sven. It's horrible and misleading because the parameter's dropdown menu only shows 2 possible values - inclusive or exclusive. But if you check the SDK for both Softimage and mental ray, you'll find there are actually 3 possible values: non-associative, associative-inclusive, and associative-exclusive. associative-Inclusive means only illuminate objects associated to the light associative-Exclusive means only illuminate objects NOT associated to the light. Neither of these settings are the default behavior of a light. A light, by default, attempts to illuminate all objects in the scene which means it's non-associative. So to say a light is inclusive when it's actually non-associative is misleading and poor design. Therefore, the proper UI for the feature should be a 3rd entry in the dropdown called "non associative" and it should be the default value. Only when the user explicitly chooses inclusive or exclusive should the light turn into an associative light and illuminate (or exclude) objects in the scene. That would remove all ambiguity. Matt Date: Tue, 16 Aug 2016 21:48:50 +0200 From: "Sven Constable" <[email protected]> Subject: RE: redshift materials show gray in viewport To: <[email protected]> "?By default all lights in the scene are shown to be inclusive, but they are not actually 'inclusive'. XSI is only showing that as the default value. You must explicitly click and set the association to inclusive or exclusive for it to actually kick in and become active. Horrible UI design as it's misleading, but that's how it is." I would not call this a horrible and misleading design because it actually helps keeping a scene slim and effective. It makes more sense if you see it as an attribute, that?s not active until propagated to a scene element for a reason. If it would be the other way around (all objects will be accociated to every light per default, it would surely slow down a scene. Let's say big scenes with thousands of objects. Those connections always applied to passes where XSI has to take care of where objects are part of passes/partitions or not. Imagine the same amount of work for lights (and even other connections in a scene). It would multiply the amount of work in the background, for no or very limited reason. So the design is "until a light is not explicitly associated/deassociated to an obj, that connection (attribute) is not set". Therefore all objs are lit by every light per default, what is to be expected. Makes sense to me as an artist and seems to be clever in terms of architecture, don't you think? sven ------ Softimage Mailing List. To unsubscribe, send a mail to [email protected] with "unsubscribe" in the subject, and reply to confirm. ------ Softimage Mailing List. To unsubscribe, send a mail to [email protected] with "unsubscribe" in the subject, and reply to confirm.
