No announcement yet.

FBX import bugs in Houdni 12

  • Filter
  • Time
  • Show
Clear All
new posts

  • FBX import bugs in Houdni 12


    I don't think this is a Speedtree issue, likely either the Python in the Houdini FBX importer, or Houdini itself. However:

    -Trying to import a 10 second Wind anim (MC format) from the default Broadleaf High Detail takes 20+ minutes and I usually kill it. This is on a brand new fast machine
    -Turning off Auto Updates allows very fast importing of the MC + Tree, but it ends up with no Materials

    I'm currently faced with writing my own importer which I don't really have time to do.

    Houdini 12.0.641 Linux 64bit, Speedtree Cinema 6.1.3 Linux 64bit


    Peter B
    Last edited by pbowmar; 06-04-2012, 05:02 PM.

  • #2
    I think Houdini converts the wind animation the first time you load it into something else (the guy who wrote the SpeedTree OTL isn't here right now or I would ask him).

    However, we definitely haven't seen extreme delays like that, and we've imported some big trees. Did you have the same trouble with Houdini 11?

    We'll look into making MDD files that Houdini can read to maybe get around the issue.


    • #3
      Hi Greg,

      Yeah, there is some conversion going on that is brutally slow I'll try H11 if I get the chance, that might be a good workaround too.

      I think I'll do some surgery on the Python as well, just to work around some of this. Happy to share what I do


      peter B


      • #4
        H11 is the same. It's not clear to me what the Python code is doing during the import. If I import the FBX "vanilla" (i.e. via SESI's FBX importer) I get the animated tree with 10 second cache imported in 5-10 seconds. So it's something the Speedtree FBX Importer OTL is doing... Will try to dig deeper when I can.


        • #5
          Hi Greg,
          I've been trying to do exactly the same as Pete and I'm experiencing the same problem. This is in Houdini 12 with SpeedTree 6.2.3.

          I think the reason it can be so slow is that when you load the point cache, SpeedTreeFBX uses CHOPs to store animation data which means that Houdini evaluates the entire time line to generate a channel for every vertex in the tree. For the broadleaf, that amounts to 780444 channels, i.e. an xyz channel for each of the 260148 vertices. So even if you have 1 second of wind animation exported, if your timeline is set to cover 10 seconds (e.g. 250 frames at 25fps), then Houdini will still evaluate the cache for the extra time in an attempt to provide meaningful data, even if there isn't any in the cache. For that number of channels, it causes a big delay.

          This is the one problem with using CHOPs in this way. It doesn't load data on demand, it loads everything into memory and evaluates everything at every moment in time for the scene. So far, I've found the best thing to do to get successful Houdini import is:

          1) Set your scene timeline to the same duration as the incoming data.
          2) Export the wind at a lower frame rate and let Houdini interpolate.

          Even so, for the broadleaf, 3 seconds of wind animation at 8 fps amounts to 0.5Gb of memory being stored in the CHOPs node. Considering that this is just one tree, it's obviously not an ideal situation. CHOPs really isn't cut out to deal with this amount of data in this way. Even on a 12Gb machine, this sort of data allocation means long delays and causes instability.

          What I'd like to propose is that SpeedTree caches the data out in a format so that Houdini can load the data on demand instead of on every frame. A BGEO sequence would be ideal, but I have no investment in what method is used as long as it's fast and doesn't use CHOPs to store per-vertex animation data.

          Many thanks,


          • #6
            Thanks for the further information.

            We'll look into some other point cache format. Have you tried the MDD format? It's an option in the FBX exporter dialog. It won't come in with the FBX automatically, so you'll have to hook it up yourself. But, I believe Houdini works with MDD a little better.


            • #7
              I highly recommend Alembic. It's free, OSS, cross platform and rapidly becoming the industry standard (at least in VFX) since all major apps support it. I had some problems with MDD (vert counts not matching geo counts) but I haven't been able to experiment to find the issue...


              • #8
                We have plans to include allembic output in a future version.


                • #9
                  Thanks for the reply Greg.

                  Yes, I tried all the different cache formats and I got a weird result with MDD (probably due to the same issue as Peter had with regards to the point count)