Announcement

Collapse
No announcement yet.

fast frame refresh when deforming vertices animated object has many polygons

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

  • fast frame refresh when deforming vertices animated object has many polygons


    Dear Vantage team
    I will write you here about experiments I have been doing with animated trees from speedtree.
    When I export an animated tree of 2.5 million polygons as one object and export the animation as vrscene, then vantage takes 3.5 seconds to refresh each frames, which leads to much slower rendering of sequences.
    If I export from speedtree as 400 different objects( separately leaves groups, brnaches , trunk) then the refresing time is almost 0 second.
    Do you think you can find a solution internally in Vantage to split the geometry when calculation deforming vertices animations, so that it refreshes faster even if you have the one object high poly.
    Thank you very much in advance​

  • #2
    If I export from speedtree as 400 different objects( separately leaves groups, brnaches , trunk) then the refresing time is almost 0 second.​
    I guess this means most of the tree is actually not deforming ? Otherwise the performance difference you describe would be impossible.

    It would be a huge change, in the V-Ray for 3dsMax exporter itself, in order to detect and export a mesh as deforming and non-deforming parts.
    I don't know if it's even possible

    Greetings,
    Vladimir Nedev
    Vantage developer, e-mail: vladimir.nedev@chaos.com , for licensing problems please contact : chaos.com/help

    Comment


    • #3
      Can you share the exported abc, vrscene and max files, please ?
      So we can test this ourself.

      Greetings,
      Vladimir Nedev
      Vantage developer, e-mail: vladimir.nedev@chaos.com , for licensing problems please contact : chaos.com/help

      Comment


      • #4
        I guess this means most of the tree is actually not deforming ? Otherwise the performance difference you describe would be impossible.​
        Hm, actually, the difference could be due to multi-threading.
        If you have the mesh split up, each part will be processed by a different thread.

        However, this difference will disappear once you have enough unique trees in your scene.
        For example, on a 16 core cpu, 16 deforming trees should have roughly the same update performance whether each one is split into 1 or 400 parts.

        Greetings,
        Vladimir Nedev
        Vantage developer, e-mail: vladimir.nedev@chaos.com , for licensing problems please contact : chaos.com/help

        Comment


        • #5
          https://drive.google.com/drive/folde...jU?usp=sharing

          Dear Vladimir
          Here you can find two vrscenes, one where the tree is one object and the other that the tree is hierarchicaly split into 500 objects.
          As you can see all parts of the tree are animated (90 percent of the tree is aniamated)
          Can you please check the files and explain to me in detail why this is happening and if there is any easy way for vantage team to fix this.
          Splitting the tree in so many parts even though it solves the problem of lagging between frames, unfortunately it takes much more time from speedtree software to export the animation.
          So this is not a solution for animated trees!
          Thnak you very much in advance

          Comment


          • #6
            Do you mean it only improved when you split it to hundreds of pieces and it is not very fast with, say 32 pieces (or whatever your cpu core count is)?
            Nikola Goranov
            Chaos Developer

            Comment


            • #7
              Actually speedtree can split exported animations in either around 20 pieces which reduces the speed of frame refreshing from 3.5 seconds to 1.5 seconds, or in 500 pieces which totally brings down the refresh time in almost 0 seconds.
              my core count is 64 if that helps

              Comment


              • #8
                Can you please check the files and explain to me in detail why this is happening and if there is any easy way for vantage team to fix this.​
                I checked the vrscenes and the reason for the observed behavior is indeed the multi-threading.

                When using 0a.vrscene, the deforming tree updates in ~1.7s on my machine.
                When using 2a.vrscene, the deforming tree updates in ~0.28s on my machine, or around 6 times faster.
                I am on a CPU with 20 threads.
                This is expected as even a single mesh uses multiple threads for some parts of its loading.

                While we might be able to optimize the single mesh case, it will be very difficult, even impossible for some parts of the code.
                This will raise the complexity of the code and potentially create bugs.

                Do you really use only a single unique deforming tree in your scenes ?
                If you have 4-5 unique trees in your scene, you should see no difference between the 20 pieces and the 500 pieces versions.
                That's because all your CPU threads will be utilized even by the 20 pieces version.

                What's your CPU by the way ?

                Greetings,
                Vladimir Nedev

                Vantage developer, e-mail: vladimir.nedev@chaos.com , for licensing problems please contact : chaos.com/help

                Comment


                • #9
                  Hi Vladimir
                  Thank you very much for your effort.
                  I have a 64 core cpu.
                  Vantage is so versatile that really lets us have many different vantage files for each of our clips that consist a short archviz film.
                  As a result it is equally often that a scene of mine will include one hero tree, so that I film a closeup sequence of the tree in a courtyard of our project and an aerial clip that will have animated trees.
                  But much more often I will try to use maximum two species and then scatter with rotate and scale to give the feeling of a forest. So in that case the difference is still there in the frame refresh rate.
                  I have no idea about coding and how hard my suggestion might be ,but I will just put the idea, if you could make the deforming vertices animation GPU calculated,
                  Maybe take a look on how fast speedtree has managed to refresh their animation on realtime viewport, and make any conclusion.
                  Thank you very much for your time

                  Comment


                  • #10
                    I have no idea about coding and how hard my suggestion might be ,but I will just put the idea, if you could make the deforming vertices animation GPU calculated,
                    We have this already - it's used by our Cosmos animated trees and the wind animation in Vantage.
                    For them, you get realtime playback.
                    It needs special data for the structure of the tree, that's why it doesn't work for any random deforming mesh.

                    Greetings,
                    Vladimir Nedev
                    Vantage developer, e-mail: vladimir.nedev@chaos.com , for licensing problems please contact : chaos.com/help

                    Comment


                    • #11
                      When using 0a.vrscene, the deforming tree updates in ~1.7s on my machine.
                      When using 2a.vrscene, the deforming tree updates in ~0.28s on my machine, or around 6 times faster. zz0.9qz1vkf4ouizz
                      We will have some improvements for the next version.
                      On my ma​chine, these times are down to ~0.5s for "0a.vrscene" and ~0.19s for "2a.vrscene" with the improvements in place.

                      Greetings,
                      Vladimir Nedev
                      Last edited by vladimir.nedev; 29-07-2024, 07:05 PM.
                      Vantage developer, e-mail: vladimir.nedev@chaos.com , for licensing problems please contact : chaos.com/help

                      Comment

                      Working...
                      X