redshift materials show gray in viewport
Dave Gallagher Softimage
Hey you Redshift users. I have a question about using redshift with Softimage 2011's viewport.
When I apply a redshift shader, the object then shows as gray in the viewport regardless of the render color. There doesn't appear to be setting to change that.
Then adding redshift materials to the eyes make it very hard to see anymore.
I notice opening the file in Softimage 2014, the shaders show correctly (sort of- the color is pretty skewed). So, do I need to upgrade to see the shaders?
And, regardless of the version, the textures don't display unless I open the texture editor and fiddle with the settings. That seems to wake it up and it suddenly displays the texture. BUT! As soon as I close the Texture Editor, the skin turns gray again. I haven't seen this behavior before.
Thanks for any help!
Dave G
Matt Lind
open, then it means that object doesn't have a texture officially assigned
to it. This is true for all materials/textures, not just redshift.
I'm not a redshift user, but the symptoms indicate you haven't applied the
material to the object, and therefore the object defaults to using the scene
material.
Matt
Date: Mon, 15 Aug 2016 17:43:51 -0600
From: Dave Gallagher Softimage <davegsoft...@gmail.com>
Subject: redshift materials show gray in viewport
To: "soft...@listproc.autodesk.com"
Hey you Redshift users. I have a question about using redshift with
Softimage 2011's viewport.
When I apply a redshift shader, the object then shows as gray in the
viewport regardless of the render color. There doesn't appear to be
setting to change that.
Then adding redshift materials to the eyes make it very hard to see anymore.
(sort of- the color is pretty skewed). So, do I need to upgrade to see
the shaders?
And, regardless of the version, the textures don't display unless I open
the texture editor and fiddle with the settings. That seems to wake it
up and it suddenly displays the texture. BUT! As soon as I close the
Texture Editor, the skin turns gray again. I haven't seen this behavior
before.
Thanks for any help!
Dave G
Softimage Mailing List.
To unsubscribe, send a mail to softimag...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
Dave Gallagher Softimage
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.
Stephen Davidson
Dave Gallagher Softimage
Mirko Jankovic
ᐧ> To unsubscribe, send a mail to softimage-request@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
------
Softimage Mailing List.
To unsubscribe, send a mail to softimage-request@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
------ Softimage Mailing List. To unsubscribe, send a mail to softimage-request@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
------
Softimage Mailing List.
To unsubscribe, send a mail to softimage-request@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
Stephen Davidson
Best Regards,
Stephen P. Davidson
(954) 552-7956
sdav...@3Danimationmagic.com
Any sufficiently advanced technology is indistinguishable from magic
- Arthur C. Clarke
> To unsubscribe, send a mail to softimag...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
------
Softimage Mailing List.
To unsubscribe, send a mail to softimag...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
------ Softimage Mailing List. To unsubscribe, send a mail to softimag...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
------
Softimage Mailing List.
To unsubscribe, send a mail to softimag...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
--Mirko JankovicNeed to find freelancers fast?Need some help with rendering an Redshift project?
------
Softimage Mailing List.
To unsubscribe, send a mail to softimag...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
Matt Lind
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 <davegsoft...@gmail.com>
Subject: Re: redshift materials show gray in viewport
To: soft...@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.
------
Sven Constable
"…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: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Tuesday, August 16, 2016 9:00 PM
To: soft...@listproc.autodesk.com
Subject: Re: redshift materials show gray in viewport
Pierre Schiller
To unsubscribe, send a mail to softimage-request@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
------
Softimage Mailing List.
To unsubscribe, send a mail to softimage-request@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
--
Matt Lind
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" <sixsi...@imagefront.de>
Subject: RE: redshift materials show gray in viewport
To: <soft...@listproc.autodesk.com>
"?By default all lights in the scene are shown to be inclusive, but they are
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
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 softimag...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
Matt Lind
what you're describing.
Matt
Date: Tue, 16 Aug 2016 15:12:34 -0500
From: Pierre Schiller <activemoti...@gmail.com>
Subject: Re: redshift materials show gray in viewport
To: soft...@listproc.autodesk.com
Matt , while we?re at it (brute force representation UVws), sometimes
the reason why?
Sven Constable
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.
Dave Gallagher Softimage
Thanks Mirko and Stephen and Matt! I will try these.
------ Softimage Mailing List. To unsubscribe, send a mail to softimag...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
Matt Lind
A non-associative light is a light which doesn't care about associations.
It will illuminate everything in the scene regardless whether objects are
associated to it or not. That IS the default behavior of lights in
Softimage. Therefore, to show a light by default as 'inclusive' when it's
actually non-associative is misleading and poor UI. To not have a parameter
setting for non-associative is even worse and why I labeled it horrible
because once the light is made associative (regardless of whether it's
inclusive or exclusive), how can a user make it non-associative after the
fact if you change your mind? You can't. You have to create a new light.
An inclusive light is a light which ONLY illuminates objects associated to
it. Since no objects are associated to a light when the light is created,
and objects are affected by such a light by default, the light is not
inclusive and disproves your theory.
Using your logic, if all lights were truly inclusive and illuminate all
objects by default, then it would require all light associations lists to be
fully populated with all objects in the scene at all times, and maintained
when objects are added/removed from the scene. Since we can clearly see the
light association lists are empty by default, your theory is again
disproven.
I know this feature very well, Sven. I've written many shaders that have to
support it. Contrary to popular belief, light associations are actually a
feature of material shaders, not lights. The associative data the user
interacts with resides on the lights, but during export of the scene for
rendering, the translator rewrites the association data as user data on the
object. When the material shader is called, it has the responsibility of
looking up that user data and deciding whether to honor it or not. That's
why many custom/3rd party shaders do not respect light associations (because
the shader programmer didn't know he had to do it).
Matt
Date: Tue, 16 Aug 2016 23:26:32 +0200
From: "Sven Constable" <sixsi...@imagefront.de>
Subject: RE: redshift materials show gray in viewport
To: <soft...@listproc.autodesk.com>
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