Announcement

Collapse
No announcement yet.

Houdini vs Phoenix grid resolution

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

  • Houdini vs Phoenix grid resolution

    Hey there,

    I´m collaborating on my short film with a houdini guy and we´ve been trying to compare some stuff.
    Some of it might be like comparing apples and oranges, but maybe you can answer these:

    1. The most important question: How do we compare resolution? Is it as simple as 1 houdini voxel = 1 phoenix grid cell? Someone on facebook suggested that...
    2. I noticed in the vdb I got from houdini, that there was a much larger range in opacity in the grid for the smoke. I´m not sure if thats matters in any way, but I´m having a harder time tweaking that for some reason and it also seems to render much slower, but that might just have been, because due to the larger range I ended up producing a curve that made it less dense and more transparency usually means higher render times.
    The question is: what would give me a bigger range of opacity in the smoke rollout?
    3. We also noticed that the phoenix caches were much smaller in size. That turned out to be because teh vdb from houdini had a lot of fields (aka channels) we wouldn´t need, so once he cleared out the caches were closer in size.
    But that left me with the problem in return, that my vdb files from phoenix ended up being way too big. 1gb .aur became 4.5 gb as a .vdb.
    I used the commandline tool to convert .aur to .vdb, but there is no option to exclude channels from export.
    If thats not possibly in another way, that would be on my wishlist....

  • #2
    Hey,

    1 voxel is 1 voxel, no matter the software, yes Note that Phoenix does not remove any data from the cache files, so all grids in VDBs from Phoenix will be as large as the container for the moment.

    Not sure which is the opacity grid though. VDBs contain simulation data, such as density, but the opacity is a render setting that you can apply to a loaded cache from the software that would shade it. However, if you mean that just grid channel ranges are different, then yes - for some reason they are. This has already been discussed int he forums not long ago, but in short - Phoenix smoke usually goes from 0-1, though from a source you can emit 5 smoke or 10 smoke or even more, though you don't really need to do that. Temperature in Phoenix is in Kelvins, so it can range from 0 to several thousand, and by default it goes from 300, which is room temperature, to 2000. RGB goes from 0-1 per color channel, and velocity is in voxels/sec, so it usually is in the range of 0-several hundred. In other software there are different channels and for some of their ranges at least I have no explanation But no matter the range of the data in the cache file, you can always remap it to anything using the volumetric render curves.

    AUR caches are usually much smaller than VDBs because we've spent a lot of time refining our compression algorithms. It's a lossy compression, so you can balance between the cache file size, the speed of saving and reading files (the more compression, the slower), and the quality of the data in the cache file from the Output rollout.

    We also have the excluding of channels in the cache converter's TODO list, let's see when we can get there...

    Cheers!
    Svetlin Nikolov, Ex Phoenix team lead

    Comment


    • #3
      Well, the opacity msut correlate to the smoke channel, because thats what I base the opacity on and there is a similar thing in houdini.
      The whole confusion came from the fact, that the cache file I got to play around was so much bigger and rendered so much slower, so I just assumed it must have been a much higher resolution.
      But if the remapping does the trick, then yeah, i was probably right about not remapping it correctly.

      I never quite understood how the amount of smoke would correlate to anything...does it add more speed or pressure, or just opacity and if so, wouldn´t that be completely omittable, if you can just change the via the opacity curves?


      The excluding channels would be nice, would be even nicer to have the conversion integrated into the GUI. Having to get stuff from phoenix to houdini is probably not that common, not sure how many people actually have to convert to OpenDVB at all...

      Comment


      • #4
        Reviving a very old thread, but for anyone reading - in the nightlies we already have removing of grid channels via the cache converter - linking to this thread: https://forums.chaosgroup.com/forum/...81#post1093981
        Svetlin Nikolov, Ex Phoenix team lead

        Comment

        Working...
        X