Announcement

Collapse
No announcement yet.

Problems with Distributed Render on nightly build

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Problems with Distributed Render on nightly build

    Anybody else having problems with distributed renders on Phoenix?

    Trying to animate water spray from a rotary spray nozzle.
    I am using Phoenix Version 2.2.0, nightly 26125, Max 2016 version 18.0 commercial, V-Ray 3.20.03. Same setup on workstation and four render slaves all with new installs of Max trials, v-ray and phoenix from newest download source and nightly build. Licenses for all machines to render.

    ===Short version: it seems that render slaves are not reading UNC cache addresses.

    ===Long version trying to answer most questions in advance: I generate liquid sim with output cache set to local drive on workstation with UNC path as described in the help documentation "tips and tricks" for distributed rendering.
    Output cache setting is \\workstation\c\cache\w_####.aur. Input path set to same address.
    Test rendering using only workstation is successful with fluid as expected.
    Set up for distributed render using all slaves, with "Transfer missing assets" turned on, not using local host. Only the spray nozzle render appears, no fluid.
    Try one slave at a time, no luck.

    Copy cache from workstation to c:\ on slave Render1 and set Input path to \\Render1\c\Cache\w_####.aur and now only Render1 begins to render fluids.
    Other slaves will not read cache from any other UNC address, but will render spray nozzle geometry just fine.
    Copy cache from workstation to slave Render 2 and set Input path to appear as local c:\Cache\w_####.aur. Warning message appears that I am using a local machine input path with distributed rendering... but when I click OK then both Render1 and Render 2 begin to render fluids on their buckets, but Render 3 and Render 4 produce only the background and spray nozzle geometry on their buckets. Copy the cache to Render3 and Render4 and they work fine, apparently reading only from their local copy of the cache. If I set the Input cache path to any UNC address whether typed or browsed, then none of the slaves render the water, only the nozzle geometry. I know the UNC address is valid when the fluid appears in the viewport preview, and if not valid then the fluid disappears.
    Also, I successfully tested each render slave ability to access, read and write, the shared cache folder, and each of the other slaves cache folders.

    Thanks for any suggestions.
    Ron Porter

  • #2
    thanks for the detailed report, having detailed info helps a lot for the resolving problem.
    when you use unc path there is no need to use the asset system, but it shouldn't be a problem. actually the asset system is supported to make possible accelerated cache distribution, if there is one.
    my first suggestion in such cases is that some security restrictions prevent the access of the hosts to the cache directory, we had many users with this issue caused by this reason. but this is only one possibility, to resolve the problem we will need the phoenix log file on the render host, it is placed in c:\phoenixfd. make a test render and send us the log file
    ______________________________________________
    VRScans developer

    Comment


    • #3
      Hi Ivaylo!

      Thanks for your quick reply.

      It looks likely you are correct in the permissions problem.
      I have attached two log files, one with "frame not found" errors, and another with the Input path set to use the local cache folder. Again it renders fine using only local cache on the slave.
      I've tried shutting off my Vipre antivirus, added 3ds Max to the windows firewall list, and verified that I can write and read files in the workstation folder while working directly from the Render1 slave.

      EDIT: shutting off Vipre did not fix the problem, nor did anything else I tried. Still not working.

      Any suggestions?

      Thanks,
      Ron Porter
      Attached Files
      Last edited by rporter8555; 20-08-2015, 09:31 AM.

      Comment


      • #4
        to be sure you can try the texture test, put a texture in the same folder and try to use it in the remote side. the test is tricky, because if you use remote desctop and start max directly, it may pass the test because the dr spawner and the remote desctop may have different permissions. you have to do it with dr, but i'm not sure how to prevent the asset tracker from sending a copy of the texture to the host.
        ______________________________________________
        VRScans developer

        Comment


        • #5
          Problem fixed... by reading the directions!
          The answer was in the Vray3 documentation page for Distributed Rendering, Mapped Drives and UNC Paths for Texture Maps and Other Rendering Assets. (link)

          After I set up the Log On account on V-Ray spawner service on all render slaves, then Phoenix began rendering DR just fine from any network cache folder.
          Until I did this, the only way Phoenix would DR was either from a local copy of the cache, or by reading a remote cache folder on my NAS Storage.

          I did not find this step in the Phoenix Tips and Tricks section, so a suggestion might be to update the Phoenix documentation with this step?
          Just a thought... is it possible to automate the spawner service setup to include the Log On configuration?

          Thanks for your great support!
          Ron Porter
          Oklahoma

          Comment


          • #6
            good to know that, we will include link to this vray docs section in our dr help
            ______________________________________________
            VRScans developer

            Comment

            Working...
            X