Announcement

Collapse
No announcement yet.

Displacement takes forever to render on i7 processor with XP64

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

  • Displacement takes forever to render on i7 processor with XP64

    I've searched the forums a bit, trying to come to a definite conclusion as to why displacement sometimes (often, but not always) takes forever to render.

    Typical scenario is as follows:

    My scene has some displaced geometry (approx 10% of the image).
    I hit "render".

    LC-calculation commences, but is quickly caught in the "presampling displacement - unloading geometry - building light cache"-loop. At this time my processor is at 13-50% usage. (One core = 13% (100/) Memory use is not out of the ordinary (1-2Gb).
    LC-calculation finishes, but it takes atleast 5 times longer than without displacement.

    IM-calculation starts. The first few buckets calculate fine, but as soon as there is one bucket rendering displaced geometry, the progress is slowed down.
    Processor usage jumps between the cores, but no core is hardly ever at 100%. Total CPU usage average at 13-20%

    When it's time to render the final image, the same thing happens again. CPU usage somewhere just above 13 %. And it takes.... forever.

    Comparing this to rendering the scene without displacement is like night and day. All cores running at 100% and the image is rendered in a raction of the time.
    A frame that takes an hour to render without displacement can go well over 24 hours with displacement.


    My displacement settings are quite simple. In the most recent case: 3d-mapping with a 200x200px png-file - 0.5mm displacement amount - 3px edge length, view dependant, 256 max subdivs, tight bounds.


    Why does this happen? Is rendering with displacement unable to multi-thread? Is there some magic switch that makes it work alright? Is there a decent work-around?

    My system is a 8-core i7 processor with 13 gigs of RAM. Using XP64, Max2010 (up to date) and Vray 1.50 SP3a.
    www.whiteview.se

  • #2
    are you using static/dynamic/auto memory?
    Chris Jackson
    Shiftmedia
    www.shiftmedia.sydney

    Comment


    • #3
      It's on default... so Auto. But does it matter? On Spot3d it reads "..Note that some objects (displacement-mapped objects, VRayProxy and VRayFur objects, for example) always generate dynamic geometry, regardless of this setting."
      www.whiteview.se

      Comment


      • #4
        Alright... Problem solved. I guess.

        Haven't at all fiddled with the Raycaster params settings. I figured it was somehow optimized by default, but increasing the Dynamic Memory Limit to 2000mb from the default 400 really improved the rendering.

        I'll do some more serious tests, but yeah... I think that might have done it.
        www.whiteview.se

        Comment


        • #5
          You beat me to it, but yes definitely a dynamic memory limit type problem. The info box normally warns you if its too low, and if the text above the progress bar ever says unloading geometry then you know you need to raise it. I often have mine as high as 10000mb (as I also have 13gb in the machine).
          www.peterguthrie.net
          www.peterguthrie.net/blog/
          www.pg-skies.net/

          Comment


          • #6
            Yeah, I had to go pretty high to get the scene to work right - but now it renders like a charm!

            I think it's a bit weird it doesn't automatically adjust itself to avaliable memory. But still, I guess it's good that you can cap it.


            However, the main issue remains: The 3dsmax.exe-process never go up to a 100% cpu usage. I wonder if there's a fix, or if I just have to live with it.
            Last edited by windowlicker; 12-10-2009, 01:42 AM.
            www.whiteview.se

            Comment


            • #7
              set dynamic memory to a couple gig under whatever the total machine memory is and you'll be flying as fast as you can.

              as for 100% usage....geometric pre sampling is only single threaded and cannot use more than one cpu to do....
              WerT
              www.dvstudios.com.au

              Comment


              • #8
                Ah alright. Yeah, well I was afraid of that. Maybe in a future vray version it's not?

                Thanks for clearing my problems out, guys!
                www.whiteview.se

                Comment


                • #9
                  It is one of the things that we will work on for future builds, yes.

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

                  Comment


                  • #10
                    Originally posted by vlado View Post
                    It is one of the things that we will work on for future builds, yes.

                    Best regards,
                    Vlado
                    Vlado was this implemented yet? Having same problem as "windowlicker"
                    If not, is it in VRay 2.0?
                    Kind Regards,
                    Morne

                    Comment


                    • #11
                      We are doing some work on it, so we'll see.

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

                      Comment


                      • #12
                        Just encountered it as well. Would be great to have a fix.
                        LunarStudio Architectural Renderings
                        HDRSource HDR & sIBL Libraries
                        Lunarlog - LunarStudio and HDRSource Blog

                        Comment

                        Working...
                        X