Rebuild all V-Ray shaders?

[leehenshall]

I have a situation where all the shaders in a Maya scene have become corrupted. The scene is mostly fine except the multi mattes will not render. After many hours troubleshooting it seems the only way to fix this scene is to create fresh vray materials.

The scene contains around 50-100 shaders. Does anyone know of a good way of automating this? A script to replace all the materials in the scene and reconnect the attributes/maps? Or is there a way to tell vray to update all the scene materials with new ones?

Many thanks

Lee

[svetlozar.draganov]

V-Ray doesn't have such tool.
Have you got a backup version of the scene and did you find out what exactly broke the shaders?
Can you send us a part of the scene with a few MM-shaders so we could investigate if there is a way to recover them without rebuilding from scratch?

[leehenshall]

At my clients office they have recently rolled out a new software deployment system with the ability to run multiple versions of software using custom environments to manage all the production software.

The jump in V-Ray version was from 3.1 - 3.4. The asset I opened was created with 3.1 and had issues with 3.4.

Maybe somewhere from 3.1 to 3.4 there may have been changes to V-Ray that effected the multi mattes or the custom attributes in the Maya shader.

I managed to find a backup of the asset which works so I've fixed the issue by rolling back and re doing my work that was lost in the corrupted version.

I'm guessing the scene had been opened in one version of vray, saved then opened in another version then saved again thus corrupting the shaders with unknown data that could not be removed or something a long those lines. There was a small period of time where some people in the studio were using 3.1 and others 3.3 or 3.4.

My guess is the corruption happened during that time.

I can't share any of the information in the scene because it contains information protected under a NDA but my suspicion is that this issue was caused by a pipeline issue unique to this studios environment rather than a V-Ray development issue.

Never the less a rebuild shader option would be a nice debugging tool to have but i doubt there is much demand for it to be worth a developers time.

Thanks for your response.

Lee

[yolov]

We haven't had other reports for a problem similar to this one, so it would be best for us to have a scene that we could test, which I understand won't be possible for the moment.
In fact, V-Ray should be pretty much backward compatible, meaning that scenes saved with 3.1 should render without a glitch on 3.4.
You could give us a detailed description of what went wrong so we can try and replicate it here and fix any potential issues.
As for a shader rebuilding tool, that probably won't be easy to make, if by that you mean replace one shader with a newly created one of the same type keeping all connections and settings? That would also mean tracking any overrides, custom attributes, vray attributes, grouping, connections to render layers...

[leehenshall]

I must admit that I've not seen this issue before. It could be something that's unique to this studios IT environment.

Initially all users had the same disk image installed on the local machines hard drive. Maya 2015 SP6 with V-Ray 3.10.01. A new software deployment system was then implemented that allows users to launch different versions of software using remote custom environment environments. For Maya & V-Ray there is a remote environment that can launch 3.1 - 3.2 - 3.3 - 3.4 based on which version a user chooses. The logic is to allow for new software to be easily rolled out in a uniform and predictable way so that all users are on the same software build and so there is still flexibility to open legacy software for when an old project needs to be worked on.

Unfortunately the main issue with this workflow is that there is a significant risk for user error to occur especially at the early stages of this workflow when the team were still getting used to this way of opening software. At the early stages there were instances where some artists were unknowingly opening scenes in newer versions of V-Ray such as 3.3 or 3.4 and then saving the scene. Another artist then might have opened that scene in 3.1. I'm not an expert in software development but I can imagine if a 3.1 scene gets opened in 3.4, saved and then opened again in 3.1 it could create "unknown data" that could corrupt the scene.

There have been other issues that are not shader related. I've had artists report that light attributes have gone missing such as the intensity multiplier. The only way to fix this is to re open the scenes in 3.1 or role back to an older version of the scene. Another issue is plane light texture maps not being recognised at render time causing those lights to render as black.

It's difficult issue to diagnose but hopefully this helps you understand the situation.

My thoughts are that this is really just teething problems caused by an internal infrastructure rebuild. If you guys can replicate the issue that would be great but if not I think it's just an unfortunate set of circumstances.

[leehenshall]

I'll speak to my clients team and see if they are interested in dedicating time to replicating the problem in scenes that are non confidential but this could be unlikely.

[yolov]

I can imagine if a 3.1 scene gets opened in 3.4, saved and then opened again in 3.1 it could create "unknown data" that could corrupt the scene.

That is very likely to be the cause.