03-29-2023, 01:37 AM
No problem, and yea it's a lot to figure out.
So from the get-go...tyFlow can't simulate across multiple machines at the same time (distributed-simulation, or whatever that might be called). Getting tyFlow running on a render machine would purely be to either cache out a sim to free up your workstation (which would require a PRO license on the node to export a tyCache, and generally needs to happen through Deadline), or to render a scene with tyFlow elements in it.
The reason you'd want to set up tyFlow RENDER on the node, is so that execution of the tyFlow code would be multi-threaded. For example, if you're rendering a swarm of 10 million particles, tyFlow FREE on the node could still render it, but the initialization phase of the render (where the renderer collects all the data it needs to render - including particles), might take 2-3 minutes on a single thread, whereas it may only take 10 seconds when threaded (I'm just pulling those numbers out of thin air and everything is scene dependent - but you get the idea).
So that's the background of why you'd want tyFlow RENDER - you can still render on a farm machine with tyFlow FREE, but the data-collection phase of rendering (for any renderer) may take longer is tyFlow is limited to a single thread.
In terms of actually setting up a farm, usually what happens is you have a piece of software which you connect to to send render jobs. So from 3ds Max you'd "submit" your job to the render farm (a dedicated machine running either Backburner - Max's render manager, or Deadline - AWS's render manager). Then the render manager connects to all the farm machines and gives them the file to render, tells them where to put the resulting images, etc.
The actual work on the farm machines is done by 3ds Max running in server mode. It's just Max without a UI. You can actually run this version of Max yourself by running 3dsmaxcmd.exe found in your Max install folder. You pass your scene file to it as a command line argument, and any other settings you want (Autodesk has docs outlining all the arguments it can take), and it'll run in server mode and simply render the file you pass to it and close when done. You can automate this process yourself with batch files to some extent, but using a render manager is much easier and gives you a lot more control over the file being rendered, the machine, etc.
So in summary, you don't need to use tyFlow RENDER to render on a farm...it just speeds up tyFlow execution if you don't have tyFlow licenses on your farm machines. And render managers like Backburner or Deadline are just fancy automation systems. If you just have one other machine it may be easiest to simply load Max on it normally and render files on it the same way you would your workstation.
So from the get-go...tyFlow can't simulate across multiple machines at the same time (distributed-simulation, or whatever that might be called). Getting tyFlow running on a render machine would purely be to either cache out a sim to free up your workstation (which would require a PRO license on the node to export a tyCache, and generally needs to happen through Deadline), or to render a scene with tyFlow elements in it.
The reason you'd want to set up tyFlow RENDER on the node, is so that execution of the tyFlow code would be multi-threaded. For example, if you're rendering a swarm of 10 million particles, tyFlow FREE on the node could still render it, but the initialization phase of the render (where the renderer collects all the data it needs to render - including particles), might take 2-3 minutes on a single thread, whereas it may only take 10 seconds when threaded (I'm just pulling those numbers out of thin air and everything is scene dependent - but you get the idea).
So that's the background of why you'd want tyFlow RENDER - you can still render on a farm machine with tyFlow FREE, but the data-collection phase of rendering (for any renderer) may take longer is tyFlow is limited to a single thread.
In terms of actually setting up a farm, usually what happens is you have a piece of software which you connect to to send render jobs. So from 3ds Max you'd "submit" your job to the render farm (a dedicated machine running either Backburner - Max's render manager, or Deadline - AWS's render manager). Then the render manager connects to all the farm machines and gives them the file to render, tells them where to put the resulting images, etc.
The actual work on the farm machines is done by 3ds Max running in server mode. It's just Max without a UI. You can actually run this version of Max yourself by running 3dsmaxcmd.exe found in your Max install folder. You pass your scene file to it as a command line argument, and any other settings you want (Autodesk has docs outlining all the arguments it can take), and it'll run in server mode and simply render the file you pass to it and close when done. You can automate this process yourself with batch files to some extent, but using a render manager is much easier and gives you a lot more control over the file being rendered, the machine, etc.
So in summary, you don't need to use tyFlow RENDER to render on a farm...it just speeds up tyFlow execution if you don't have tyFlow licenses on your farm machines. And render managers like Backburner or Deadline are just fancy automation systems. If you just have one other machine it may be easiest to simply load Max on it normally and render files on it the same way you would your workstation.