Announcement

Collapse
No announcement yet.

Dynamic Distributed Render

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

  • Dynamic Distributed Render

    Problem: We often render large print renders, sometimes we use distributed on the farm and sometimes we don't, depending on availability and time. Sometimes the farm frees up midway through a render and it would be nice to be able to enable the farm from there out without having to stop to enable distributed and re-render.

    Note: Our farm has about 550 cores, so there is a lot to manage and keep track of.

    Possible Solution 1: Make the distributed buckets always active. If we were to fire off every render with distributed on and every machine on the farm always checked it would be a simple solution. Unfortunately it seems like after the initial firing off of a render, the vray server if busy is ignored from then out, even if it frees up later. So you can't just always leave this checked. It can seem to overwhelm the server on the farm too if multiple renders try to access it, sometimes crashing it. A solution would be to have it check availability at a regular interval, or have an "server free" variable that is always checked for. Making this regularly check instead of just initially checking for free nodes would be a tremendous time saver and would cut out a lot of farm time-management issues. Then we could just leave all of the farm and distributed always checked, and we can all share it freely and it would always be fully booked.

    Possible Solution 2: Make the Distributed Render window and features always active, even during render, so you can re-open it midway through a render and enable machines on the fly. This would be ideal for manually controlling the environment and including something like a priority in this dialogue would be a cool bonus. This would solve distribution problems and would really help in crunch times. Both of these options together would solve all of our large distributed render problems.


    I hope that is clear enough. I'd be happy to help answer questions or develop a solution if I can. Just let me know.

    -Joel E.
    -Joel E
    https://www.biglittlepictures.com

  • #2
    Possible Solution 3: Create distributed render manager that manages all slaves and masters. Assign here workstations to slaves and jobs to DBR. This way you can add/substract nodes buckets and everything else during the render without canceling anything. Set up rules, access, etc etc. Fully dynamic bucked distribution.

    Just my 5 cents.

    Thanks, bye.
    CGI - Freelancer - Available for work

    www.dariuszmakowski.com - come and look

    Comment


    • #3
      The V-Ray SDK already supports this internally and we use it for some projects; I just have to figure out a suitable way to control this from the 3ds Max UI while rendering. I don't think we'll do a separate render manager though; most likely just allow you to bring up the DR settings window during rendering so that you can change things from there.

      Best regards,
      Vlado
      I only act like I know everything, Rogers.

      Comment


      • #4
        That would be great. Which thing does support exactly? Also would it not be less work if you were to do it from external app that could then link to maya/max/xsi/etc etc?

        Then even people from different jobs/offices could tweak up render farm to maximize potential..
        Last edited by Dariusz Makowski (Dadal); 30-05-2013, 07:35 AM.
        CGI - Freelancer - Available for work

        www.dariuszmakowski.com - come and look

        Comment


        • #5
          That sounds great. It would really be a huge help.
          -Joel E
          https://www.biglittlepictures.com

          Comment


          • #6
            Originally posted by DADAL View Post
            Which thing does support exactly?
            Internally, V-Ray now supports adding and removing DR servers on the fly.

            Also would it not be less work if you were to do it from external app that could then link to maya/max/xsi/etc etc?
            I'm not sure - it might be more work Inter-process communication is always tricky.

            Best regards,
            Vlado
            I only act like I know everything, Rogers.

            Comment


            • #7
              Adding DR servers on the fly

              Love it, would be great inside max's UI, especially at the moment.

              Comment


              • #8
                Dbr is one area of vray that would benefit from improvements. I found MR was more robust.
                Win10 x64, 3DS Max 2017 19.0, Vray 3.60.03
                Threadripper 1950x, 64GB RAM, Aurous Gaming 7 x399,

                Comment


                • #9
                  Originally posted by DPS View Post
                  Dbr is one area of vray that would benefit from improvements. I found MR was more robust.
                  To each his own I guess... I know many users that would say the opposite

                  Best regards,
                  Vlado
                  I only act like I know everything, Rogers.

                  Comment


                  • #10
                    I would rather cut my hands off than every use MR DBR again... but thats on MAYA side. I guess MAX in ur case is a lot better...
                    CGI - Freelancer - Available for work

                    www.dariuszmakowski.com - come and look

                    Comment


                    • #11
                      Max's MR DBR was/is fairly solid in my experience. But so is Max's Vray DBR. Both are extremely vulnerable to human error or config issues though and basically require a lot of up-front work and babysitting, and the compression thing is troublesome. But 3.0 looks to address some of these issues. I'm hoping before long DBR will simply be a "click to use" affair and won't require any hard work at all with maps or ports or whatever.
                      Alex York
                      Founder of Atelier York - Bespoke Architectural Visualisation
                      www.atelieryork.co.uk

                      Comment

                      Working...
                      X