"…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 -----Original Message----- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind Sent: Tuesday, August 16, 2016 9:00 PM To: softimage@listproc.autodesk.com Subject: Re: redshift materials show gray in viewport XSI has a concept called “Instance data”. Instance data is data that is generically common to all objects for a given parameter, but has unique values per individual object (or 'instance'). For example, all geometry have a concept of texture UVW coordinates, but the actual UVW coordinates are unique per object even if you apply a material with a texture UVW coordinates property of a specific name already attached to it via an image shader. The assigned texture UVW property may appear to be a single property, but what is actually happening is XSI is creating a unique copy for each object with the same name to make it appear as if it’s the same property applied to all objects. XSI does this so named-based mechanisms such as overrides can function to affect multiple objects in a sweeping generic way. Somewhere around XSI 7.0 or so, the shading and rendering architecture received a complete overhaul under the hood. It received another significant overhaul around Softimage 2011. These updates broke some of the fall through inheritance users became accustomed to as XSI would often automatically assign an instance specific data to a parameter to be active if it were the only property on the object for that parameter value. After the updates, this courtesy feature broke and often would display the property in the parameter to make it appear it was assigned, but in reality it wasn't actually assigned. The user had to explicitly assign the property by clicking and choosing it in the parameter's dropdown menu. This primarily affects texture UVW properties, vertex colors, user normals, and weight maps. Best analogy is associative lights in a light's PPG. 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. In your case of redshift materials not showing properly in the viewports, what is likely happening is you are assigning a material, but the instance specific data is not be explicitly assigned to the object. This usually happens because your specific instance isn’t *exactly* the same as for other instances using the same material. The instance data may different on one or more objects using the material, or it may not exist on all objects using the material. In some cases, there are other differences under the hood that are not readily apparent to the user. In any event, to solve the problem, you must explicitly assign the texture UVW coordinates to the object by going into the shader/PPG where the texture UVW coordinates are specified and manually click on the menu to assign the property – even if already visible in the menu. when you use the texture editor, XSI brute force assigns a texture property to the shader in use to guarantee a texture appears in the viewports...because what good is a texture editor if you cannot see the texture. When you close the texture editor, this brute force assignment is removed. That's why you experience the behavior you describe. Matt Date: Mon, 15 Aug 2016 18:31:32 -0600 From: Dave Gallagher Softimage <davegsoftimagel...@gmail.com> Subject: Re: redshift materials show gray in viewport To: softimage@listproc.autodesk.com Good thought Matt. But in Softimage 2011 it appears to work fine when applying a texture to a Phong, but not when I switch to the redshift material. However, when I remove the material and reapply it in Softimage 2014, I do see the texture after all, so it looks like it is a version issue. ------ Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
------ Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
