Vray Proxy Error

[Dman3d]

3DS MAX 2024.2.3 (26.2.2.124)
Vray 6.2.1
Forest pack 8.2.6

Getting this error in deadline render with various VRay proxies. The file is pre-existing and pulled forward from MAX2019/Vray Next.
Some of the proxies we use were made with much older versions of vray. I cannot tell if something is actually wrong with the proxy files, they render locally and on their own with no issue.
Which model is reported seems to change depending on what machine renders it.

These are from 3 different machines however there are many errors of this nature.

Is there any utility to check vrayproxy files for errors?

2024/09/30 10:06:48 ERR: [15256] [03696] [V-Ray] [DefMeshFile::getVoxel] 59: Error loading voxel 4 for mesh file "\\mapdrives\maps\images_cd\HQ Plants\hq_palms_1\Alexander palm 03.vrmesh"

2024/09/30 10:06:48 ERR: [15256] [03696] [V-Ray] [VUtils::MeshVoxel::load] 59: Error loading mesh voxel

2024/09/30 10:06:48 ERR: [15256] [03696] An unexpected exception has occurred in the network renderer and it is terminating.

---
2024/09/30 10:06:38 ERR: [13428] [13076] [V-Ray] [DefMeshFile::getVoxel] 59: Error loading voxel 41 for mesh file "\\mapdrives\Maps\images_cd\Maxtree\Plant Models Vol2\Vray\MT_PM_V2_Gleditsia triacanthos_05_L-MLB.vrmesh"

2024/09/30 10:06:38 ERR: [13428] [13076] [V-Ray] [VUtils::MeshVoxel::load] 59: Error loading mesh voxel

2024/09/30 10:06:38 ERR: [13428] [13076] An unexpected exception has occurred in the network renderer and it is terminating.

---
2024/09/30 10:05:11 DBG: [08604] [06540] FOREST 8.2.6 NotifyPreRenderFrame

2024/09/30 10:06:17 ERR: [08604] [06540] [V-Ray] [DefMeshFile::getVoxel] 59: Error loading voxel 40 for mesh file "\\mapdrives\Maps\images_cd\Maxtree\Plant Models Vol7\MT_PM_V7_Mesh_Vray\MT_Plant Models_Vol7\MT_PM_V7_Chamaerops_humilis_02_H-MLB.vrmesh"

2024/09/30 10:06:17 ERR: [08604] [06540] An unexpected exception has occurred in the network renderer and it is terminating.

)

[Dman3d]

This does indeed to appear to be a network/switch problem. We had, for whatever reason, 10Gb switches with 1Gb connections from each to the server. They are now replaced with 20Gb/10Gb and the problem vanished.
Noticed to on 2 machines only there was never an error, when 3 or more much less 100 errors.
My guess was when the vrmeshes would load there was a limit, quota or otherwise scrum at the server/network level. Then only parts got loaded or something like that then would fail.
I do not know what else IT may have done but there was mention of a drive access issue of some sort which may or may not have played a role as someone mentioned earlier about NAS configuration. So could be either config, switches or both.

This all made jobs sort of tumble through the farm where error, error, error, render, error, render, error, error randomly on each machine. My guess is was some jobs tried to load on machines at roughly the same time.

[Dman3d]

To add, these appear to proxies I already remade/updated/
Some sort of bug or other shenanigans is my guess. Stil trying various things.

[Dman3d]

Referencing this existing post. Already UNC, changed forest distribution maps to UNC also see what happens.
[V-Ray] [DefMeshFile::getVoxel] 59: Error loading voxel 8 for mesh file - Chaos Forums

[vladimir_krastev]

HI, thanks for posting. Have you tried to render using Backburner instead of Deadline? Please send us a few of the proxies you are having issues with so we could test them. Please do that here or trough the support contact form. If you choose the contact form, place a link to this thread in the description and the ticket number here in the thread.

[Dman3d]

Backburner would not be an option at the moment.

I am bubble sorting the file at the moment, so far disabling displacement seems to remedy the error.

It may be some memory issue. I did not create this file and it is quite large.

If I cannot resolve this via further sorting and hunting down possible displacement issue will send to support and see about setting up a backburner server to test against.

[Dman3d]

Still no idea what is causing this. MAX24 Vray 6.2.1
attached are a couple of the proxies that seem to trigger errors in Deadline, there are several and seem to alternate on which cause the error first.
If it can at least be confirmed nothing is wrong with these then we can concentrate on looking elsewhere.
https://www.dropbox.com/scl/fi/9bepe...=97r8shy8&dl=0

[vladimir_krastev]

Hi, I tested your vrmeshes but you have sent them without materials. This is the result with default V-Ray material:

The proxies redner with no issues with Deadline or locally. Probably the issue is with a material or something else in your scene.

[Dman3d]

Ok thanks, will check more closely through mats.

[Dman3d]

When you make a proxy, no other information or custom properties etc carry over to the vrmesh file correct? Its only whatever a vrmesh file is, nothing else.

[Joelaff]

Try removing the network from the equation by copying the files to the render nodes and referencing them locally. Could possibly be your NAS needs oplocks disabled.

Could be entirely unrelated to this, but I fight this for a number of days with some .AUR files not loading. Finally discovered the issue.

Deadline should show you the max RAM usage for each task (scroll to the right, it’s one of the columns). Might give you some insight as to whether or not it is ram related.

[vladimir_krastev]

When you make a proxy, no other information or custom properties etc carry over to the vrmesh file correct?

If you have a material applied over the original mesh it will be applied to the vrmesh in the same scene after conversion or for instance if you have disabled the"renderable" checker from object properties it will stay disabled for the current scene.
If you load the vrmesh in a new scene it will load without materials and with reset object properties.

[Dman3d]

If you have a material applied over the original mesh it will be applied to the vrmesh in the same scene after conversion or for instance if you have disabled the"renderable" checker from object properties it will stay disabled for the current scene.
If you load the vrmesh in a new scene it will load without materials and with reset object properties.

All of this is killing us at this point. We have jobs that need to go out that are endlessly causing problems.

What I thought but wanted to be sure I was not missing something somewhere.
Our IT team is helping look into this. On top of this we have "unexpected end of JPEG" errors and Anima issues, we just got the super version whatever its called. Works on some machines, not on others.

2024-10-30 02:51:02: 0: STDOUT: WARNING: material StreamMaterial_6 has no supportable Techniques and will be blank. Explanation:

2024-10-30 02:51:02: 0: STDOUT: Pass 0: vertex program PBR_VP cannot be used - not supported.

2024-10-30 02:51:02: 0: STDOUT: Pass 0: vertex program PBR_MRT_VP cannot be used - not supported.

None of these problems seem to happen on local workstations.

IT is looking into Deadline update and possible issues with new network switches.

[Joelaff]

Have IT look into this as well: Could possibly be your NAS needs oplocks disabled. This failure happens when multiple machines try to pull the same resource over the network. Does it work under Deadline, but using only ONE node?

But it is weird if you are seeing errors about particular portions of the proxy file. That makes it sound like perhaps it *is* loading (which would not be a network issue).

Please update us when you do figure it out.

[Joelaff]

Also, we never use UNC, only mapped drives.

[Dman3d]

We use nothing but UNC. I am wondering if its a bug with FP and vray or something like that. I tried a test with FP 9.x on 5 boxes same error.
I wonder if this is some sort of user rights thing, not sure. We updated Deadline last night and it is not auto propagating the update to the nodes or workstations so thats additional fun on this.
We have a ticket in to Deadline. My workstation and other machines render fine. Tried reinstalling MAX/FP/Anima on about a dozen machines. Have to check them to see if the error perists.