Jump to content
  1. General

    1. 26.4k
      posts
    2. 2.2k
      posts
    3. 1.6k
      posts
    4. Marketplace

      For all commercial tools, HDA's etc.

      438
      posts
  2. Houdini

    1. 65.8k
      posts
    2. 49.1k
      posts
    3. 12.3k
      posts
    4. 5k
      posts
    5. 15.2k
      posts
    6. 1.1k
      posts
    7. 698
      posts
    8. 708
      posts
  3. Coders Corner

    1. 6.3k
      posts
    2. 13.2k
      posts
    3. 4.8k
      posts
  4. Art and Challenges

    1. 3.5k
      posts
    2. 9.8k
      posts
    3. 572
      posts
    4. Effects Challenge Archive

      This is where the cool unofficial challenges live on!

      297
      posts
  5. Systems and Other Applications

    1. Other 3d Packages

      Maya,XSI,Blender,etc

      1.6k
      posts
    2. 1.5k
      posts
    3. Hardware

      Graphics cards etc.

      2.1k
      posts
    4. 422
      posts
  6. od|force

    1. 1.5k
      posts
  • Who's Online   2 Members, 0 Anonymous, 258 Guests (See full list)

  • Member Statistics

    46,591
    Total Members
    10,714
    Most Online
    Robertexcet
    Newest Member
    Robertexcet
    Joined
  • Forum Statistics

    46.3k
    Total Topics
    231.1k
    Total Posts
  • Posts

    • In case anyone stumbles across it, the amazing Tomas Slancik solved it on the SideFX forum. Turns out point deform uses an internal "id" attribute, and the fact that I had one going in on my control curves was throwing it.
    • I'm doing just an rnd/experimenting setup of a thing with lots of eyes that open/close based on the proximity of a target. My idea was to have a lid curve that bends based on the target and that would point deform the lid parts of the critter's geo. (It's okay if the blink isn't a nice arc--it will be run through vellum with an eyeball collider). This worked on small setups when it was just eyelids, but now that I have the whole critter the guide curves are not "catching" the lids. If I polywire the control curves it will warp the whole critter, but still not the lids. I've probably done something stupid, but I would love to know what that stupid thing is, if anyone can take a peek. The target that controls the opening/closing is animated, so you can just scrub along the timeline to see it in action. blinkcritter_problem.hiplc
    • Vellum reads SOP point attributes once at sim init, then runs entirely in DOP space with no link back to the source SOP. Animated Cd, animated stiffness masks, time-varying pin weights,  all silently dropped from frame 2 onward. The standard fixes (hand-rolled popwrangle microsolver, separate cache + Geometry Wrangle DOP, learning that microsolvers don’t run on the creation frame) are nontrivial plumbing.  This HDA is that plumbing in one click. Same popwrangle-in-Pre-Solve pattern SideFX  Free download: https://kleer001.github.io/funkworks/vellum_attr_stream Houdini 19.5+, any edition. FX users: a build script is included to compile the HDA clean under your own license.  More free tools at https://github.com/kleer001/funkworksuses internally for muscleupdatevellum. 
    • I’m locally rendering (render to Disk button in arnold rop) a VDB volume sequence in Houdini 21 with Arnold (renderer) using standard_volume in ROP, and while all cache files exist and single frames render correctly, random frames in the sequence render without any volumes but render lights and polygon/meshes without an error or crash reports. It seems that Arnold starts rendering before loading vdb cache or before cooking volume file nodes. Does anyone have same issue and solve it? 
  • Topics

×
×
  • Create New...