Announcement

Collapse
No announcement yet.

A few wishes

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

  • A few wishes

    Here our some wish list items formutated using VRay in commercial production.

    VFB ability to define bit depth of various render elements, I likely don't need 32bit float for a multimatte, for instance, often 16bit int, or even, gasp, 8bit would do. In theory this would save on memory when rendering bigger images.


    Ability for VRayHDRI to update animated textures in the viewport. This works with the built in bitmap node, but not VRayHDRI.

    Could the order for the Triangulation render block order reverse with each rendered frame (even if rendering Nth frame, it should reverse every other frame rendered, not every other frame). This should improve tile and geometry caching on larger scenes, as VRay will have just rendered those areas.

    The VFB mouse hover function should automatically turn off when net rendering with the VFB. If the user wants to turn it on and view the VFB interactively they can, but they usually want it off for net rendering.

    Would be nice if the log window could spit out a report on memory used for both geometry caching and tile caching. I'd like to know if the cache overflowed or not. This can tell me if I need to bother making various changes to handling of images or geometry..

    Would be nice if the line in the log that shows the number of light cache samples also said the amount of memory used.

    Would be nice to be able to have the log window show up on render nodes when net rendering with 3dsmaxcmd.exe.

    Distributed rendering should automatically turn off when using 3dsmaxcmd.exe to render. This gets us all the time.

    Would be nice to have the mouse hover feature of the VFB have a way to lock the point of interest (like shift click or something). This way you could switch to another window and have VRay continue to render the area you want in stead of tracking the mouse all over the screen when in the background.

    Thanks.

  • #2
    Image2TiledExr should add the "tiled" string to the file name BEFORE the frame number. As it is now we have to rename image sequences after converting them. Would use maketx for the EXRs, but sometimes it seems to crash on EXRs, while it works fine making tiled .tx files for integer formats.

    Image2TiledExr should properly handle input and output of the Data Window (region) in EXR files. If the tiled format won't support a data window, then it should at least load the entire frame (not just the data window and stretch it as it does now) when creating the tiled versions.

    Would be *really* nice to have the ability to add the current scene name and path, render date and time, node name, render time, and max memory usage to the metadata of EXR files.
    Last edited by Joelaff; 28-12-2014, 02:12 PM.

    Comment


    • #3
      I believe that VRayHDRI generates IFLs with full paths. These should be relative paths, like the built in Bitmap node generates (or better yet give the option either way). The problem with the full paths comes when net rendering, especially when we are working on a big project where we distributed all the assets to the render nodes via GoodSync prior to rendering. The absolute paths then still reference the network paths, rather than the local path.

      We would really like to be able to add the following items to EXR metadata: scene name, node name, node vRay version, node memory, max memory used when rendering, render time, render date and time stamp, any other cool useful info.

      The new render mask feature is incredible. Would be cool if it used the opacity channel to define the area rendered for selected or included objects. A lot of the time in VFX we have objects or talent on planes with opacity maps. The planes are often much larger than the visible content. This uses a lot of extra area for the render mask (of course a multimatte or other mask will fix this, but you do have to make it).

      Comment


      • #4
        Thanks, will note these things down so that we can look into them.

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

        Comment


        • #5
          I know one of the biggest drawbacks to DR is transferring the scene to the slaves every time you want to render. For a large scene of hundreds of megabytes or even over a gigabyte this takes quite a bit of time. This is compounded by the fact that the scene has to be sent from a single machine to a bunch of slaves.

          What if the scene were cached on the slaves and only a binary diff of the differences between the two versions was sent? There are some open source binary diff tools out there like xdelta or bsdiff. This might save a ton of overhead. It could be triggered once the scene exceed a certain size (where it would be more efficient to do it the old way) this size could be set by an environment variable so it could be tuned for different pipelines/networks.

          Just a thought.

          Comment


          • #6
            Originally posted by Joelaff View Post
            What if the scene were cached on the slaves and only a binary diff of the differences between the two versions was sent? There are some open source binary diff tools out there like xdelta or bsdiff.
            It's not impossible, I guess. Do these work well on (compressed) Max files?

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

            Comment


            • #7
              Hmmm. Initial tests not very promising. The patches were 80% of the file sizes, and it took too long to process.... I didn't try uncompressed Max files.

              Nevertheless perhaps there is some method to transfer only the differences.

              Comment


              • #8
                Well, you can always use X-Refs. If you use automatic asset transfer, they will be cached on the slaves and updated as needed.

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

                Comment


                • #9
                  "Would be nice to have the mouse hover feature of the VFB have a way to lock the point of interest (like shift click or something). This way you could switch to another window and have VRay continue to render the area you want in stead of tracking the mouse all over the screen when in the background."

                  for this i zoom in to the image in the VFB a LOT and leave track mouse turned on, usually works
                  www.peterguthrie.net
                  www.peterguthrie.net/blog/
                  www.pg-skies.net/

                  Comment


                  • #10
                    Originally posted by peterguthrie View Post
                    "Would be nice to have the mouse hover feature of the VFB have a way to lock the point of interest (like shift click or something). This way you could switch to another window and have VRay continue to render the area you want in stead of tracking the mouse all over the screen when in the background."

                    for this i zoom in to the image in the VFB a LOT and leave track mouse turned on, usually works

                    Ha! Cool work around. Not quite as good since you have to re-activate and zoom back out to see things (rather than having the window open next to something else you are working on), but I do usually KVM switch to another machine anyway, since the 3d machine is really just for 3d. Nevertheless should help. Thanks.

                    Comment


                    • #11
                      Yes, xrefs are good when they work. Wasn't able to use many on this last BIG project for technical reasons. But we did convert a lot of stuff to vRay proxies, which helped a lot. Pretty much just didn't use DR much even for testing on this scene because of the overhead.

                      Comment


                      • #12
                        try xRef SCENES.
                        They have historically been a heck of a lot more stable (if you need to SRT them, add a dummy, and parent the scene.)
                        Lele
                        Trouble Stirrer in RnD @ Chaos
                        ----------------------
                        emanuele.lecchi@chaos.com

                        Disclaimer:
                        The views and opinions expressed here are my own and do not represent those of Chaos Group, unless otherwise stated.

                        Comment


                        • #13
                          Thanks. We work with both scenes and objects. Objects are more troublesome. However, things have generally worked well since 2014.

                          Comment


                          • #14
                            Have they?
                            Official word is the development of xRefs had been dropped since V.2012.
                            Glad to hear the whole approach is stabler!
                            Lele
                            Trouble Stirrer in RnD @ Chaos
                            ----------------------
                            emanuele.lecchi@chaos.com

                            Disclaimer:
                            The views and opinions expressed here are my own and do not represent those of Chaos Group, unless otherwise stated.

                            Comment


                            • #15
                              Purely anecdotal... They seem to work better.

                              Comment

                              Working...
                              X