Announcement

Collapse
No announcement yet.

Slower Light Cache on smaller render vs. larger?

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

  • Slower Light Cache on smaller render vs. larger?

    I've noticed a weird behavior on the light cache calc that it will often take significantly longer to do a calc on a lower resolution image than a higher one. For example, on a very simple test scene - just a plane, teapot and sun - the light cache will take maybe a second or two to complete at 1920x1440. If I drop the resolution to say 640x480 it takes about 14-15 seconds. It will stay this slow as I raise the resolution up to 1733x1300 and then jump all the way back down to the 1-2 seconds (meaning it's not linear but seems to be hitting some threshold value). Light cache was at defaults with subdivs at 1500. If I raise the subdivs the threshold resolution goes up as well: e.g., at subdivs 2000 the 1920x1440 LC takes ~30 seconds but as soon as I hit 2310x1733 it just takes a few seconds again. In this example the entire 1920x1440 image took 40 seconds to complete, and the 2310x1733 image took just 17 seconds - so the higher resolution shot finished before the lower one even finished the light cache!

    Is this expected behavior? Anything setting I can change to compensate?

    BTW-This is on max 2016 w/ vray 3.40.02, 64gb ram, windows 10, Xeon E5 72 cores.
    www.dpict3d.com - "That's a very nice rendering, Dave. I think you've improved a great deal." - HAL9000... At least I have one fan.

  • #2
    Light Cache in general is not resolution dependent and should be calculated for the same amount of time regardless of the size of the image.
    There is exception of that rule in case there are displacement or subdivisions in the scene, then the difference in the resolution will affect the LC calc time since the geometry between different resolutions will be different.

    I have just executed a few very quick tests on different resolutions on a very basic scene and I got the same LC calc times.
    Have you run the same test on another machine?
    Would it be also possible to send us the test scene (even if it is very simple one) in order to test it here?
    Svetlozar Draganov | Senior Manager 3D Support | contact us
    Chaos & Enscape & Cylindo are now one!

    Comment


    • #3
      Here's the scene but I don't think it's necessary, LC Calc.zip

      I tested it on another machine and the LC times were identical on each run regardless of resolution. That led me to think that it was a problem with my current machine, a dual E5-2696-v3 with 72 cores. Sure enough, I set the "VRAY_USE_THREAD_AFFINITY" to 0 and everything ran fine. LC calc was almost instantaneous at all resolutions although the system was only using 8 cores.

      Just to make sure, I set the affinity back to 1 and retested. Weirdly, I saw the very first trial run finish the LC calc almost instantaneously but subsequent runs return to ~8 seconds even though the cpu is basically hitting all cores at 100%. Restarting max makes no difference - the only fast run is after I switch the affinity and restart max.

      Hope this helps and let me know if you need me to test anything out on my end.

      Cheers,
      www.dpict3d.com - "That's a very nice rendering, Dave. I think you've improved a great deal." - HAL9000... At least I have one fan.

      Comment


      • #4
        I have tested the scene on my machine and the result is always the same LC calc times, no matter the resolution.

        The VRAY_USE_THREAD_AFFINITY variable is actually not needed in version 3.40.02 since the support for processors with more than 64cores is enabled by default.
        Would you please try to remove it, restart the machine and see if the issue is still there?

        If it is it is most likely a bug and we'll have to investigate what's causing it.
        Svetlozar Draganov | Senior Manager 3D Support | contact us
        Chaos & Enscape & Cylindo are now one!

        Comment


        • #5
          Originally posted by svetlozar.draganov View Post
          The VRAY_USE_THREAD_AFFINITY variable is actually not needed in version 3.40.02 since the support for processors with more than 64cores is enabled by default.
          Would you please try to remove it, restart the machine and see if the issue is still there?

          If it is it is most likely a bug and we'll have to investigate what's causing it.
          I removed the affinity line and restarted machine.... still slow on low resolutions. I also tested in Max 2017 and get the same results.

          Does your testing machine have more than 64 cores?

          One change (I think) from before is that the first render after restarting max is always lighting fast. Subsequent renderings return to the slow LC calc. Here's a screencast that demonstrates the problem (http://screencast-o-matic.com/watch/cD10ITi0PQ). I open the LC Calc file in a restarted max 2016. The first LC calc at 640x480 is lighting fast. I rerender and the next one takes ~8 seconds. I change the resolution to 1920x1440 and the lc calc is lighting fast (I rendered again just to confirm it's still fast) and then I drop the res back down to 640x480 and the LC calc is slow again. CPU activity in the window on the right.

          I know it's only a few seconds but it adds up. The good thing is that it doesn't seem to get compounded for larger more complicated scenes, they are delayed by about the same amount, if not less! It's frustrating though at the beginning of a project where I would expect the LC to be very, very fast instead becomes slow - mainly affecting test renders.
          Last edited by dlparisi; 23-06-2016, 06:56 AM. Reason: Added note about complicated scenes being ok.
          www.dpict3d.com - "That's a very nice rendering, Dave. I think you've improved a great deal." - HAL9000... At least I have one fan.

          Comment


          • #6
            FYI - unchecking "Show Calc. phase" clears up any slowdowns! Seems like an easy workaround. Could it be a video driver problem (I'm on a gtx 970 with the 368.39 driver)?
            www.dpict3d.com - "That's a very nice rendering, Dave. I think you've improved a great deal." - HAL9000... At least I have one fan.

            Comment


            • #7
              Has there been any insight into this. For regular renders I can turn off Light Cache "Show Calc" but the "Show Calc" checkbox is not respected for IPR rendering which really kills that immediate interactivity.

              EDIT: While I haven't determined the cause of this slowdown I have determined what resolution and settings trigger the behavior. Since the light cache subdivisions number is actually the square root of the number of paths, I did some calculations with different resolutions and whenever the number of paths per pixel is higher than 1, the slowdown occurs. For example, at a resolution of 640x480, the slowdown occurs whenever the subdivisions is set above 554. (554x554)/(640x480)=.999. For 1024x768 its 886, (886x886)/(1024x768 )=.998. For 1920x1440 it 1662, which equals .999. As soon as I go above this limit and get more than 1 path per pixel the slowdown happens. For example, on the 1920x1440 scene the LC goes from 2 seconds at 1662 subdivs to 24 seconds at 1663 subdivis. Make sense? Any idea?
              Last edited by dlparisi; 01-05-2017, 02:43 PM.
              www.dpict3d.com - "That's a very nice rendering, Dave. I think you've improved a great deal." - HAL9000... At least I have one fan.

              Comment


              • #8
                It makes sense and I suspect what's going on, but I need to do more tests to figure out a way around it.

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

                Comment


                • #9
                  Can V-Ray calculate the light cachse subdivs based on resolution automatically? I mean, since 3.0 I leave the subdivs at the default value of 1000. But for our print jobs, the light cache calculation might easily take 5 minutes depending on scene complexity. Maybe V-Ray can set the perfect amount of subdivs for a given resolution.
                  https://www.behance.net/Oliver_Kossatz

                  Comment


                  • #10
                    Originally posted by vlado View Post
                    It makes sense and I suspect what's going on, but I need to do more tests to figure out a way around it.

                    Best regards,
                    Vlado
                    Thanks Vlado. I've attached a simple scene here but I suspect it might not help much. Is there a way to turn off "Show Calc" during IPR via maxscript?

                    Light Cache Test.zip
                    www.dpict3d.com - "That's a very nice rendering, Dave. I think you've improved a great deal." - HAL9000... At least I have one fan.

                    Comment


                    • #11
                      Originally posted by kosso_olli View Post
                      Can V-Ray calculate the light cachse subdivs based on resolution automatically? I mean, since 3.0 I leave the subdivs at the default value of 1000. But for our print jobs, the light cache calculation might easily take 5 minutes depending on scene complexity. Maybe V-Ray can set the perfect amount of subdivs for a given resolution.
                      It would make no sense to do that. The light cache is resolution-independent and does not need any adjustment when changing the image size (except for maybe turning off the "Show calc phase" option).

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

                      Comment


                      • #12
                        Originally posted by dlparisi View Post
                        Is there a way to turn off "Show Calc" during IPR via maxscript?
                        No infortunately - it's always enabled internally for IPR. The only thing you can do is lower the light cache subdivs. I'll be looking into this in the following days, I will let you know when I have a fix.

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

                        Comment


                        • #13
                          Looks like this was fixed in 3.6! Thanks!
                          www.dpict3d.com - "That's a very nice rendering, Dave. I think you've improved a great deal." - HAL9000... At least I have one fan.

                          Comment

                          Working...
                          X