[Wynott]

Seems to send ALL textures from the scene to each node when rendering.

Have been working through a lot of design scenarios with a lot of different materials. Scene material library is getting bloated. Maxwell doesn't seem to cull the unused textures before transferring files to the render nodes. Seems to me this would be pretty straightforward to determine what materials are on hidden layers and not bother exporting the textures for them?

[JDHill]

The plugin's point of view is that if a material exists in the scene, it should also exist in the MXS file (there is nothing especially related to network rendering here, textures will be copied by the networking system as a function of their being referenced in the MXS file). An option for skipping materials not actually in use due to hiding/etc could be added, but its implementation would not be so simple as one might assume, given Rhino's material inheritance rules.

[Wynott]

That makes sense to me.

So really it should be the monitor that goes through the MXS and then decides what it doesn't need to clog up the network with.

[JDHill]

I don't think that would work; the engine should issue an error for missing resources, even if they're not necessarily in use. On the other hand, the problem is something that can be avoided altogether, by ensuring that the textures you use are available on the machine where the scene will be rendered, and then forgoing the use of "send dependencies" in the network job setup. My general recommendation is that textures be kept on a share mapped to a drive letter, where a common drive letter is used for this purpose on all machines; the share can be on the local machine, or on the network, such that you end up with materials containing paths like z:\some.file, which work wherever you happen to use them.