Announcement

Collapse
No announcement yet.

Vray and EXR files in 1.5 Part 2

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

  • Vray and EXR files in 1.5 Part 2

    After working with doing this work flow for about a week now I am noticing some issues and wonder if anyone has further info about the process.

    1) So we have the ability to write to EXR from the VFB by simply adding the .exr to the end of the file name instead of vrimg. However we do not have the ability to control how the EXR is saved. This may be causing some of the issues when actually using the EXRs in a Comp app.

    2) Performance in compositing applications is slow. This is from my test with AE, Combustion, Fusion and Shake. I do not have Nuke so I cannot comment on that. However I have done a bit of resaearch and futher testing and found that there are two things that can effect performance. EXRs can be written as scanline or tile-based. I believe VRAY writes tile based images. This can be a problem in compositing apps. Also you can set variety of compresison methods for EXRs. The VFB defaults to ZIP16 which needs ot be deocmpressed per frame, this can also degrade performance.

    I have taken the passes rendered by VRAY into a compositing app and rerendered them as individual EXR files. The performance when using the same layers is noticibly faster. This is using the same amount of layers as the EXR with the file self contained.

    If VRAY cannot save a different way from the VFB is there a conversion tool that can do this and maintain all the layers?

    I am doing a test right now where I save the individual passes as seperate files with no EXR compression. I will let you know the results here as well.

    The above is not to be considered full fact, just what I have found thus far from usage. Any enlightenment would be appreciated. I know the EXR workflow is important to the VRAY community and is more accesible every day as more compositing apps support it.

  • #2
    To 1) True and there is a reason for tile based saving, not for compressions settings. see 2)

    To 2) The problem is saving to tilebased EXRs, ZIP16 performs EXCELLENT when scanline-based (we did a lot of testing). But there IS a reason to save tilebased : EXR saving is added as a replacement for VRIMG rendering. the main advantage is beeing able to render without a VFB to conserve a lot of ram. That's impossible with scanlinebased EXRs (wich was the main reason that vrimg was created in the first place). Turning away from tilebased EXRs means you will definately loose that possibility.

    Regards,
    Thorsten

    Comment


    • #3
      I thought it was something like that. Is there any way known to convert those to scanline?

      Thanks for the insight.

      Comment


      • #4
        we use an internally developed command line tool to do so. Nuke does the trick. we convert via backburner. The only reason we did the tool was to free the nuke render licenses during conversions.

        Regards,
        Thorsten

        Comment


        • #5
          So nuke you can just open them import and then convert?

          That internal tool would be a great seller!

          Wish there were a commercial version :P

          Thanks for the feedback.

          Comment

          Working...
          X