vrayBlendMtl sub materials do not respond to showTextureMap()

[gimiky]

it appears that materials within a vrayBlendMtl do not respond to maxscript calls to .showInViewport or showTextureMap(). although they will report the value for .showInViewport, they will not respond to setting\changing this value. (this goes for any texture within the blend as well)

the same sub material (a regular vrayMtl) responds fine when it is not nested in the blend, or when toggled via the material editor user interface. can anyone confirm this?

i should also note that regular the VrayMtl has this same problem when it is xref'd (when calling it on the source item).

[AJ Jefferies]

Yep - I've had lots of issues with this.

Even when manually turning on viewport display through the slate editor, a nested material causes Max to crash 9 times out of 10.

[vlado]

Do you have the same issues for other standard 3ds Max materials?

Best regards,
Vlado

[AJ Jefferies]

Truth be told, we haven't used any standard Max materials in quite a while! Will test when I can & let you know.

[gimiky]

no, it only happens with vrayBlend materials..

incidentally, i've discovered a couple other maxscript+vray odditties:

1. along with the issue above, VrayBlendMtls will "mask" any listener output that would normally happen. for example, when i have the maxscript listener enabled and i modify any material parameter it will be reported in the listener:

meditMaterials[17].reflection_glossiness = 0.97

however if the same material is *nested* within a vrayBlendMtl, no activity on this material will be reported. this is not a huge deal, but can be annoying.

2. along the same lines, vrayDirt texture maps will "hide" bitmapTexture items used within them from the getClassInstances() function. i.e. getClassInstances bitmapTexture will return empty if the scene bitmapTextures are inside of a vrayDirt. those same bitmapTextures will be reported correctly, however, if they are instanced outside of the vrayDirt. this is actually somewhat of a big deal since getClassInstances() is otherwise quite powerful.

[gimiky]

in max2010 it looks like the key to this is to use the top material when calling "showTextureMap()" instead of the submaterial. for example, consider a vrayBlend material with a base and one coat material:

VrayBlend
-BaseMaterial
-CoatMaterial1

to show the diffuse texture of the base material, it will not work to run this command (although it will not report an error either):

showTextureMap BaseMaterial BaseMaterial.texmap_diffuse

for the command to succeed, you need to reference the whole blend material instead of the sub material:

showTextureMap VrayBlend VrayBlend.baseMtl.texmap_diffuse

i think it's important to note that although this works, this is different than how standard max blend materials work, and it makes the vrayBlendMtl a special case when looping through materials that have sub materials. incidentally, the vray2sidedmtl behaves this way also.

[simmsimaging]

Yep - I've had lots of issues with this.

Even when manually turning on viewport display through the slate editor, a nested material causes Max to crash 9 times out of 10.

I have had this problem since Slate was Node Joe. The developer at that time didn't figure it out and it doesn't appear to have changed since Autodesk took it over. I almost never activate the display via Slate because of this issue. It's definitely Slate though, the normal Mat Editor works fine, even File Path Finder Pro can do it without problems.

/b