Announcement

Collapse
No announcement yet.

IRR - use camera path - file size

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

  • IRR - use camera path - file size

    Hi

    I've been playing with the new irr/'use camera path' mode, and I must say that i'm pretty impressed - yesterday I had to calculate every 5th frame for one camera (multiframe inceremental), and it took almost 2hrs to finish. Today, using the new 'use camera path' mode the irradiance for the whole flythrough took.... 4mins .

    So if everything was set up correctly, and I'm not seeing ghosts here - that's SOME improvement.

    Now the question is this: I'm about to set up all the machines for the night to render some arch flythrough. Yesterdays irr file was about 280 megs (multiframe incremental), while todays is about 19megs. Is that correct?
    I mean - does that mean that in the older mode there was so much of obsolete data?
    Or is the new file somehow compressed/optimised?
    Or maybe I'm doing something wrong, and the new file (using 'use camera path' and rendering only first frame of the flythrough) is rendered incorrectly/too small?
    the purpose of a ninja is to flip out and kill people.
    the purpose of an architect is to flip out and design for people.
    ________________________
    www.1050.pl / www.kinetik.pl

  • #2
    There are a lot less samples in the "Use camera path" case - after all, just one set of prepasses is calculated. This is why this method is only useful for short fly-throughs where the camera does not move a long distance. If the camera path is long, that one set of prepasses will not be enough to capture all the details everywhere.

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

    Comment


    • #3
      thanks Vlado!

      so to be sure I'll have to do some tests and see for myself which mode is best for the type of flythrough i'm dealing with atm.
      the purpose of a ninja is to flip out and kill people.
      the purpose of an architect is to flip out and design for people.
      ________________________
      www.1050.pl / www.kinetik.pl

      Comment


      • #4
        Originally posted by vlado View Post
        There are a lot less samples in the "Use camera path" case - after all, just one set of prepasses is calculated. This is why this method is only useful for short fly-throughs where the camera does not move a long distance. If the camera path is long, that one set of prepasses will not be enough to capture all the details everywhere
        Is it possible to just up the min/max or subdivs values to increase the amount of samples?

        Regardless, in SP3 you've added support for incremental Imap thru DR and now it appears we don't really need it (at least for some animations). You never rest do you?
        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


        • #5
          Originally posted by dlparisi View Post
          Is it possible to just up the min/max or subdivs values to increase the amount of samples?
          You can increase the min/max rates, yes.

          Regardless, in SP3 you've added support for incremental Imap thru DR and now it appears we don't really need it (at least for some animations).
          I'm sure both methods have their uses; the "Use camera path" option is primarily targeted at animations with moving objects - the possibility to use it for fly-through precalculations is somewhat of a side effect.

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

          Comment


          • #6
            Vlado I haven't tried it, but is it possible to use a combination of this option and "every nth frame" to make an animation-mode IRmap? For example, calculate every 10 frames but by having "use camera path" on, it calculates 10 frames ahead per IRmap. Surely this would be faster than calculating every frame like you usually have to do for an animation IRmap (moving objects/lights) while not making the IRmaps insanely large, because they're only 10frames of data.

            Comment


            • #7
              k, just finished one test.

              irr calculated using 'use camera path' mode, irrmap rendered at frame 0 in about 3mins, 19 megs in size. irr settings: -3/-1, 30 samples/10 smp int, noise threshold 0.01 for irr pass, 0.05 for
              final render.

              140 frames, about 7 minutes per frame (1280x720) using 2 render nodes.

              here are some frames at half resolution, 0, 20, 50, 80, 110 and 140 respectively:













              (it still needs work, in postproduction atm - skies, CC and stuff like that)

              the camera pans about 60m, passes by a few hipoly trees, lots of reflections/refractions (blurry too), some translucency and so on.
              no flickering, everything is very smooth.
              'use camera path' was definitely a way to go here.

              now I'm going to try and see how this works on another take - a 360 degrees spin around the entire scene, seen from above (with lots of trees in the background etc).

              btw - Vlado, as You said it's suitable for animations with moving objects. how about animated lights - like sun? will it work too or is it better to use 'animation (prepass)' and 'animation (rendering)'?
              the deadline is getting close, and I'm not sure I can afford more than two tests here
              the purpose of a ninja is to flip out and kill people.
              the purpose of an architect is to flip out and design for people.
              ________________________
              www.1050.pl / www.kinetik.pl

              Comment

              Working...
              X