Announcement

Collapse
No announcement yet.

Tool to bake Displacements to Proxies

Collapse
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Tool to bake Displacements to Proxies

    Attached, a simple script that leverages the new feature able to bake displacement modifiers into proxies.
    The script is only meant to illustrate the process, it comes with no support, and it's unlikely it will be updated, save for major issues or changes.
    I, the author, or Chaos Group take no responsibility for any issue that may arise from using it.
    You're free and encouraged to modify and redistribute it, provided it stays free of charge.


    What it does:
    *) It's able to bake the selected nodes, or all the nodes, with a displacement modifier applied into a V-Ray proxy.
    *) It can optionally set up the renderer so it does the least work to get the vrmeshes out.
    *) It can optionally re-import the proxies in place of the original geometry, crucially without animation support.
    *) The operation is undoable.

    What it doesn't do:
    *) The vrmesh names are built from the original nodes' names. As the script won't change characters in node/filenames, If the node name contains filename-unfriendly characters, the process will fail, and the script will crash.
    F.e.: "my node // 1234$$>" will crash the script.
    This also applies to writing rights and such.
    *) The script does not support animation, controllers, custom properties or hierachies. If the node to export is animated, consider replacing it manually, and properly. Or consider expanding the script to do so.
    *) The script will only render the proxies from whichever camera is currently selected/main. Doing so for multiple cameras would produce multiple vrmesh files, and the substitution of those in the scene would have to be done in accordance to which camera was seeing them. This is best left to someone's specific needs, and pipeline. Alternatiovely, if a displaced object is seen from different cameras, which produce different meshes (i.e. displacement is set to per-pixel), it's likely more convenient to not bake it.
    *) The script needs to make instances unique, lest entropy ate filenames. Feel free to avoid the step and change the logic as needed.

    Recommendations:
    *) Consider saving out just the nodes to bake, and process the saved file.
    It's not strictly necessary, the script allows undoing.
    However, if the operation was very long, things may happen, and data may get lost.
    *) The script always overwrites the VRMeshes in the destination folder. Ensure you're ok with that.

    The script in action can be seen here.
    Attached Files
    Last edited by ^Lele^; 02-11-2022, 04:57 AM. Reason: V002 has a more graceful return from rendering for displacement only. Also, no VFB is opened at all, saving some more RAM.
    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.

  • #2
    That's pretty slick. Thanks.

    So these vrmesh files are then completely, no longer needing any displacement, right? So the overhead of doing the displacement itself is handled once (when baked), and now VRay just has to load and render a vrmesh, right?

    Comment


    • #3
      Originally posted by Joelaff View Post
      That's pretty slick. Thanks.

      So these vrmesh files are then completely, no longer needing any displacement, right? So the overhead of doing the displacement itself is handled once (when baked), and now VRay just has to load and render a vrmesh, right?
      Correct.
      There are details to consider: proxies are going into the dynamic memory pool, and obey its optional limit.
      The displacement could have been set up, instead, to use the static pool, which can be quicker than the dynamic, by virtue of the loading/unloading operations the dynamic does (proxies are loaded partially, and when hit by primary or secondary rays.), and the membership to the main embree acceleration structure of the static pool (the one prepared before rendering start, but crucially after static displacements are calculated.).
      You should still be able to move the proxy back to the static pool by reimporting the mesh.
      This could prove difficult for the video card, though, so approach it with wisdom.

      If displacements were dynamic to begin with, you can expect a serious speed up, as proxies ought to be quicker, particularly if cached locally on a quick drive.
      If you have assets on an already strangled network, your best bet is to leave the displacements as procedural, and pay the rendertime price, likely still lower than pulling potential Gb of data off a strained NAS.

      Mileage will vary, we're all ears for feedback.
      Last edited by ^Lele^; 19-07-2021, 08:02 AM.
      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


      • #4
        Originally posted by ^Lele^ View Post

        Correct.
        If you have assets on an already strangled network, your best bet is to leave the displacements as dynamic, and pay the rendertime price, likely still lower than pulling potential Gb of data off a strained NAS.
        Mileage will vary, we're all ears for feedback.
        Yeah, proxies and tiled textures put a giant strain on the network. We use a push model to sync push assets to local drives of the render nodes before the render. (Share a folder on each node, then use GoodSync on one main machine to sync the assets to the nodes. It only copies what has changed (like an rsync).)

        Comment


        • #5
          Most helpful indeed, particularly if one renders animatons, or via Dr: copy once, reuse many times.
          Much more convenient also in terms of transmission sizes, with networks often more at ease with big files, rather than the comparatively tiny transfers of voxels/texels on demand.
          With many machines rendering together, the strain quickly builds.
          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


          • #6
            Nice one Lele!
            I am a bit late to the party but this is going to be very handy.
            Chris Jackson
            Shiftmedia
            www.shiftmedia.sydney

            Comment


            • #7
              V002 has a more graceful return from rendering for displacement only. Also, no VFB is opened at all, saving some more RAM.
              Grab it at the top.

              Thanks go to Dimitar for the kind feedback.
              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


              • #8
                moved post to new thread
                Last edited by super gnu; 30-11-2022, 01:18 AM.

                Comment


                • #9
                  In a semi-related note, is there any possible way to bake/convert/export something as VRayFur to a standard mesh or geometry node?

                  Comment

                  Working...
                  X