PRISM & PANDORA REQUEST - Multiple Software Version executables

#1 · 3. March 2021, 6:26

Quote from Pete Draper on 3. March 2021, 6:26
Our current render farm management software, RenderPal, has the ability to point to different versions of the same software, eg max 2017, 18, 19 etc. Locations of the same are stored on the main farm manager and nodes look for the executables in the defined locations - if they exist, they report to the manager that they can receive jobs for that version.

This is really handy as we use multiple versions of max and blender to render depending on the scene or even layer due to plugin installation, compatibility and feature set. This would also help for general installation; currently it is pretty lengthy to get Prism and Pandora installed with the amount of settings to enter and executables to point to as, for blender (for example) we run from network so that everyone is running the same installation so Prism / Pandora cannot find the default installation without forcing the override for each machine, and in a studio with a farm it is taking a very very long time to set this up, especially as users have accounts for working and another account to connect the machine to the farm as a node. These accounts have restrictions due to security, so to install Pandora we need to install the c++ redist which is another login. If this could be streamlined so that all settings for executable paths (eg an override such as "Use Co-Ordinator EXE Paths") as a single checkbox, it'll help a lot.

This setup could be stored as information in the Prism project and/or Pandora root so when a job is submitted to the farm, the desired version is selected and submitted.

For examples of what I'm talking about, please check RenderPal's documentation. The primary issue we have with this particular farm system is it's lack of integration into a pipeline and, now, stability, which we're looking to Prism / Pandora to implement. Prism is currently on 1/10 of the systems here and doing ok so far albeit from a few issues which I've noted, however the final push is Pandora.

Thanks,

Pete

Our current render farm management software, RenderPal, has the ability to point to different versions of the same software, eg max 2017, 18, 19 etc. Locations of the same are stored on the main farm manager and nodes look for the executables in the defined locations - if they exist, they report to the manager that they can receive jobs for that version.

This is really handy as we use multiple versions of max and blender to render depending on the scene or even layer due to plugin installation, compatibility and feature set. This would also help for general installation; currently it is pretty lengthy to get Prism and Pandora installed with the amount of settings to enter and executables to point to as, for blender (for example) we run from network so that everyone is running the same installation so Prism / Pandora cannot find the default installation without forcing the override for each machine, and in a studio with a farm it is taking a very very long time to set this up, especially as users have accounts for working and another account to connect the machine to the farm as a node. These accounts have restrictions due to security, so to install Pandora we need to install the c++ redist which is another login. If this could be streamlined so that all settings for executable paths (eg an override such as "Use Co-Ordinator EXE Paths") as a single checkbox, it'll help a lot.

This setup could be stored as information in the Prism project and/or Pandora root so when a job is submitted to the farm, the desired version is selected and submitted.

For examples of what I'm talking about, please check RenderPal's documentation. The primary issue we have with this particular farm system is it's lack of integration into a pipeline and, now, stability, which we're looking to Prism / Pandora to implement. Prism is currently on 1/10 of the systems here and doing ok so far albeit from a few issues which I've noted, however the final push is Pandora.

Thanks,

Pete