Distributed & Backburner Render Issue
#1
Hello, I am using 3ds max 2020 and version .16067 of TF. Ever since I started using TF I have an issue where distributed rendering (Vray) and rendering over Backburner doesn't work. Network render just has no sim in it at all. The only way I can get the network to render is to cache out the TF sim and then manually adding that folder of cache files to each computer on the network in the exact same place. In my case c:/folder/sim files.

Is there a way to not have to cache the files and just have it work or at the very least just cache files to my project folder and just have the other machines access it (similar to my textures or Phoenix FD sims)

This plugin is so amazing that I started trying to put it in everything but the render process is a bit of a nightmare. Hopefully, it's just user error Smile

Distributed rendering attached.


Attached Files Thumbnail(s)
   
  Reply
#2
Caches should be going on a network share so you don't need to copy any files to local machines.

It's generally always a good idea to cache out any sims before rendering, so you know you are guaranteed identical results. It's no fun trying to figure out why one machine is rendering things differently, or whatever.

Regardless, you're probably getting different results because you haven't checked "strict determinism" in the Particle Bind settings of your tyFlow object. See the documentation for more info.
  Reply
#3
(01-30-2020, 04:50 PM)tyFlow Wrote: Caches should be going on a network share so you don't need to copy any files to local machines.

It's generally always a good idea to cache out any sims before rendering, so you know you are guaranteed identical results. It's no fun trying to figure out why one machine is rendering things differently, or whatever.

Regardless, you're probably getting different results because you haven't checked "strict determinism" in the Particle Bind settings of your tyFlow object. See the documentation for more info.

Thanks for getting back to me. I tried "strict determinism" and it still didn't work with the distributed rendering. I'll try that when I get a chance on the network render with the files cache on my network drive.
  Reply
#4
The only other time where "strict determinism" would fail (beyond you having encountered a literal bug) is if some machines are using OpenCL, while other are not. So if some of your render machines do not have a capable GPU, that could be causing the discrepency. This is of course assuming, judging by your screenshot, that the cloth is using Particle Bindings and not PhysX.
  Reply
#5
(01-30-2020, 05:55 PM)tyFlow Wrote: The only other time where "strict determinism" would fail (beyond you having encountered a literal bug) is if some machines are using OpenCL, while other are not. So if some of your render machines do not have a capable GPU, that could be causing the discrepency. This is of course assuming, judging by your screenshot, that the cloth is using Particle Bindings and not PhysX.

Here's the setup. My production machine uses a 2080ti however the 3 render computers have no GPU. They just render off the processor.

(01-30-2020, 05:59 PM)jimmwagner Wrote:
(01-30-2020, 05:55 PM)tyFlow Wrote: The only other time where "strict determinism" would fail (beyond you having encountered a literal bug) is if some machines are using OpenCL, while other are not. So if some of your render machines do not have a capable GPU, that could be causing the discrepency. This is of course assuming, judging by your screenshot, that the cloth is using Particle Bindings and not PhysX.

Here's the setup. My production machine uses a 2080ti however the 3 render computers have no GPU. They just render off the processor.

It looks like turning off OpenCL acceleration under particle bind solver did the trick. It seems to be working fine under distributed rendering.

Thanks for all your help!!!!


Attached Files Thumbnail(s)
   
  Reply
#6
Ah yup that will do it. Constraint processing can happen in a different order between OpenCL/no-OpenCL, which will give different results. Glad it's solved! (Although make sure OpenCL acceleration is also disabled in your Particle Physics operator if you run into the issue again)
  Reply


Forum Jump: