RE: redshift materials show gray in viewport

[Matt Lind]

I don't think you have a full grasp of what non-associative means, Sven.

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" 
Subject: RE: redshift materials show gray in viewport
To: 

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

--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

OT: Light association WAS: redshift materials show gray in viewport

[Sven Constable]

I made a mistake in wording. An exclusive light in XSI is not the same as a
non associated light. There are three states:

Associated-inclusive -> default behavior to all obj in a scene -> obj get
illuminated or de-illuminated (negative lights) even if not associated. If
associated (attribute set) they're only affected by these lights.

Associated-exclusive -> objs associated are not affected by lights
(attribute set).

Not associated -> objs are not affected by a light at all (this is not
exposed to the user). Since it doesn't make sense, XSI sets the first state
per default.

sven

-Original Message-
From: softimage-boun...@listproc.autodesk.com
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Sven Constable
Sent: Tuesday, August 16, 2016 11:27 PM
To: softimage@listproc.autodesk.com
Subject: RE: redshift materials show gray in viewport

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: softimage-boun...@listproc.autodesk.com
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Tuesday, August 16, 2016 10:35 PM
To: softimage@listproc.autodesk.com
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" 
Subject: RE: redshift materials show gray in viewport
To: 

"?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 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.

--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: redshift materials show gray in viewport

[Dave Gallagher Softimage]

Thanks Mirko and Stephen and Matt! I will try these.


On 8/15/2016 11:33 PM, Mirko Jankovic wrote:
just to remove this case, did you try assigning proper UV space for 
texture in image node?
I've sen sometimes that happens, mostly when more objects share same 
material, after assigning proper UV space in node material then it 
shows fine.
Also in open GL settings of material choosing "Use specific image/UV 
pair" or "Track shader" instead of "Track shader tree" works.

ᐧ

On Tue, Aug 16, 2016 at 3:41 AM, Dave Gallagher Softimage 
> 
wrote:


Yes, it renders great. It's only the viewport that isn't showing
the colors I'll hunt around more, thanks!


On 8/15/2016 7:39 PM, Stephen Davidson wrote:

If you are talking about the viewport and not the render,  then
it is probably you viewport settings.  There are a lot of them.
Does it render ok?  If so,  it is not Redshift.

On Mon, Aug 15, 2016, 8:31 PM Dave Gallagher Softimage
> wrote:


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.

On 8/15/2016 5:52 PM, Matt Lind wrote:
> If the texture only displays in the viewport when the
texture editor is
> 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
>
> Subject: redshift materials show gray in viewport
> To: "softimage@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.
>
>
> 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
>
> --
> 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.



--
Softimage Mailing List.
To unsubscribe, send a mail tosoftimage-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. 


--
Mirko Jankovic
_http://www.cgfolio.com/mirko-jankovic_
__
Need to find freelancers fast?
www.cgfolio.com 
Need some help with rendering an Redshift project?
http://www.gpuoven.com/

--
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 

RE: redshift materials show gray in viewport

[Sven Constable]

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: softimage-boun...@listproc.autodesk.com
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Tuesday, August 16, 2016 10:35 PM
To: softimage@listproc.autodesk.com
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" 
Subject: RE: redshift materials show gray in viewport
To: 

"?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 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.

Re: redshift materials show gray in viewport

[Matt Lind]

I cannot comment as I've never used Arnold inside of Softimage to witness 
what you're describing.

Matt


Date: Tue, 16 Aug 2016 15:12:34 -0500
From: Pierre Schiller 
Subject: Re: redshift materials show gray in viewport
To: softimage@listproc.autodesk.com

Matt , while we?re at it (brute force representation UVws), sometimes
arnold materials do not show themselves on the Material explorer, is that
the reason why?

--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

RE: redshift materials show gray in viewport

[Matt Lind]

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" 
Subject: RE: redshift materials show gray in viewport
To: 

"?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 softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: redshift materials show gray in viewport

[Pierre Schiller]

Matt , while we´re at it (brute force representation UVws), sometimes
arnold materials do not show themselves on the Material explorer, is that
the reason why?

On Tue, Aug 16, 2016 at 2:48 PM, Sven Constable 
wrote:

> *"…**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-bounces@
> 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 

RE: redshift materials show gray in viewport

[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: 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 

Re: redshift materials show gray in viewport

[Matt Lind]

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 
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.

Re: Modulate ICE Turbulize mesh with weightmap?

[Morten Bartholdy]

Didn't think of that one - thanks!

//Morten


> Den 16. august 2016 klokken 12:21 skrev Olivier Jeannel 
> :
> 
> 
> Modulate by volume connected in the amplitude of the turbulize ?
> 
> On Tue, Aug 16, 2016 at 12:13 PM, Morten Bartholdy 
> wrote:
> 
> > I would like to do a simple flagstyle nonsimulated turbulent animation in
> > ICE using Turbulize mesh. I need to modulate the effect with a weightmap
> > but ran into it not being applicable as a scalar value for resizing a
> > vector. I guess this is because the weightmap contains a value per vertex,
> > so how do I use that for modulating the turbulize effect?
> >
> > Cheers
> > Morten
> > --
> > 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.
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: Modulate ICE Turbulize mesh with weightmap?

[Morten Bartholdy]

Thats a nice one Patrick - thanks!

Morten


> Den 16. august 2016 klokken 12:21 skrev patrick nethercoat 
> :
> 
> 
> you can multiply your turbulize variance by the weight map like this.
> 
> 
> 
> On 16 August 2016 at 11:13, Morten Bartholdy  wrote:
> 
> > I would like to do a simple flagstyle nonsimulated turbulent animation in
> > ICE using Turbulize mesh. I need to modulate the effect with a weightmap
> > but ran into it not being applicable as a scalar value for resizing a
> > vector. I guess this is because the weightmap contains a value per vertex,
> > so how do I use that for modulating the turbulize effect?
> >
> > Cheers
> > Morten
> > --
> > Softimage Mailing List.
> > To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
> > with "unsubscribe" in the subject, and reply to confirm.
> >
> 
> 
> 
> -- 
> Brandt Animation
> www.brandtanim.co.uk
> 020 7734 0196
> 07717 38 39 40
> --
> 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.

Re: redshift materials show gray in viewport

[Stephen Davidson]

Here is one place to look...
http://softimage.wiki.softimage.com/xsidocs/property521.htm

If you are using multiple UV sets, the correct one may not be selected for
viewing in the viewport

Best Regards,
*  Stephen P. Davidson*

*(954) 552-7956*sdavid...@3danimationmagic.com

*Any sufficiently advanced technology is indistinguishable from magic*


 - Arthur C. Clarke



On Tue, Aug 16, 2016 at 1:33 AM Mirko Jankovic 
wrote:

> just to remove this case, did you try assigning proper UV space for
> texture in image node?
> I've sen sometimes that happens, mostly when more objects share same
> material, after assigning proper UV space in node material then it shows
> fine.
> Also in open GL settings of material choosing "Use specific image/UV pair"
> or "Track shader" instead of "Track shader tree" works.
> ᐧ
>
> On Tue, Aug 16, 2016 at 3:41 AM, Dave Gallagher Softimage <
> davegsoftimagel...@gmail.com> wrote:
>
>> Yes, it renders great. It's only the viewport that isn't showing the
>> colors I'll hunt around more, thanks!
>>
>>
>> On 8/15/2016 7:39 PM, Stephen Davidson wrote:
>>
>> If you are talking about the viewport and not the render,  then it is
>> probably you viewport settings.  There are a lot of them. Does it render
>> ok?  If so,  it is not Redshift.
>>
>> On Mon, Aug 15, 2016, 8:31 PM Dave Gallagher Softimage <
>> davegsoftimagel...@gmail.com> wrote:
>>
>>>
>>> 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.
>>>
>>> On 8/15/2016 5:52 PM, Matt Lind wrote:
>>> > If the texture only displays in the viewport when the texture editor is
>>> > 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 
>>> > Subject: redshift materials show gray in viewport
>>> > To: "softimage@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.
>>> >
>>> >
>>> > 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
>>> >
>>> > --
>>> > 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.
>>>
>>
>>
>> --
>> 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.
>>
>
>
>
> --
> Mirko Jankovic
> *http://www.cgfolio.com/mirko-jankovic
> *
>
> Need to find freelancers fast?
> www.cgfolio.com
>
> Need some help with rendering an Redshift project?
> http://www.gpuoven.com/
> --
> 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.

Re: Modulate ICE Turbulize mesh with weightmap?

[patrick nethercoat]

you can multiply your turbulize variance by the weight map like this.



On 16 August 2016 at 11:13, Morten Bartholdy  wrote:

> I would like to do a simple flagstyle nonsimulated turbulent animation in
> ICE using Turbulize mesh. I need to modulate the effect with a weightmap
> but ran into it not being applicable as a scalar value for resizing a
> vector. I guess this is because the weightmap contains a value per vertex,
> so how do I use that for modulating the turbulize effect?
>
> Cheers
> Morten
> --
> Softimage Mailing List.
> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
> with "unsubscribe" in the subject, and reply to confirm.
>



-- 
Brandt Animation
www.brandtanim.co.uk
020 7734 0196
07717 38 39 40
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: Modulate ICE Turbulize mesh with weightmap?

[Olivier Jeannel]

Modulate by volume connected in the amplitude of the turbulize ?

On Tue, Aug 16, 2016 at 12:13 PM, Morten Bartholdy 
wrote:

> I would like to do a simple flagstyle nonsimulated turbulent animation in
> ICE using Turbulize mesh. I need to modulate the effect with a weightmap
> but ran into it not being applicable as a scalar value for resizing a
> vector. I guess this is because the weightmap contains a value per vertex,
> so how do I use that for modulating the turbulize effect?
>
> Cheers
> Morten
> --
> 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.

Modulate ICE Turbulize mesh with weightmap?

[Morten Bartholdy]

I would like to do a simple flagstyle nonsimulated turbulent animation in ICE 
using Turbulize mesh. I need to modulate the effect with a weightmap but ran 
into it not being applicable as a scalar value for resizing a vector. I guess 
this is because the weightmap contains a value per vertex, so how do I use that 
for modulating the turbulize effect?

Cheers
Morten
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.