Looks like volumes that are being directly loaded with file/filecache inside GEO node are not being transferred over to DR machines. Only volumes that are “baked” pre-render by V-Ray, are transfered(as part of scene i guess).
I would expect for any textures/proxies/vdbs that are not found in their paths, to be transferred, when “Transfer missing assets” is checked on the ROP.
Thank you.
You’ve been hitting known limitations left and right these past few weeks. I’m afraid that’s also one of those. Volume sims are usually really large so V-Ray expects the cache files to be placed in a network location reachable by both the workstation and the DR hosts. On one hand, I’m not sure it would be a good idea to transfer the cache files to every single DR slave individually. On the other, it can be confusing when you fire up DR and your sim is missing.
I suppose the very least we could do is throw a warning in the UI itself - the console output should be giving you a warning but it’s easy to miss.
All the best!
What can i say, “Transfer missing assets” should transfer missing assets 
i cant DR from shared location, because i have mixed enviroment here with Linux slaves and my workstation is now W10, and having volume to load from $JOB\Project\Volume.vdb will not work. V-Ray will translate $JOB to local Windows drive W:\ and that is sent as path to DR machines. Of course such a thing does not exist on Linux so no volumes in render. So i can`t use shared path, and you`re not transfering…
What about not resolve the $JOB for DR , can i do that? then Linux standalone slave will look in it`s system enviroment $JOB path?
I tried with preserve variables, but that does not work either, not even for textures and DR.
when i use ${WORK}/texture.jpg , DR will still error out with 2020/Apr/10|12:07:07] [111 MB] warning: Bitmap file “w:/texture.jpg” failed to load: error reading file:file does not exist , So standalone server already receive the paths resolved…
I was just about to give you a script that handles a difference in the variable mapping for volumes and hit this when trying it out 
I’ll check with the devs if the code for preserving the variables can be extended to DR, and come back with info as soon as possible.
@psanitra , we’ve fixed the environment variables issues for DR - it should work correctly both for textures and volumes now.
The limitation with volumes not transferred through DR is still present - I’ll ping you when there’s any changes there.
Hope that helps!
@Gosho.Genchev Thank you!
@Gosho.Genchev I tested it and it seems to work for textures and volumes.With exception of IES lights,you probably missed that one, path there still gets expanded. Any change to add that to the next nightlies? Thank you!
Hey, Peter,
should be fixed with today’s builds.
All the best!
@Gosho.Genchev i updated to build from 29th today, and textures in lights still get expanded. For example V-Ray rectangle light with texture as ${JOB}/020_Asssets/Textures/Lights/LightTexture.exr
That’s embarrassing I’ll double-check all parameters that can take file paths right away. I’m sorry about this…
All the best!