Dr. Royce

Update: So I got the inverse transforms going via an attribute wrangle running over points before the rasterize node. This effectively pre-transforms the input volume to account for the Position data in the DOP. It works for the first few seconds, then starts to deteriorate and I'm not exactly sure why. Perhaps because the Wrangle is momentarily moving the geometry back to the origin to apply the transforms, then back into it's intended place?

Anyway, if anyone could take a look at this and help me make sense of what's happening that'd be amazing.

Thanks,
-M.

akvahouse
Hi guys, I tried to rotate fluid container and got a strange result, the simulation just rotates, as if you make a transform node after the node cache file.
I want to optimize container size and don`t rotate all scene, can I do this job in Houdini?

Just wanted to chime in, I'm having the same problem. Changing the position data will rotate both the container AND the incoming source volumes. Still trying to figure out how to separate the two. I made another thread about this over here: https://www.sidefx.com/forum/topic/61429/?page=1#post-274051 [www.sidefx.com]

I saw a thread on ODForce (https://forums.odforce.net/topic/16845-rotating-pyro-grid/?tab=comments#comment-150934) where someone had fixed this by altering one of the SOP Solvers inside the volume sourcing node to fetch the transforms from the Position data, invert, and pre-apply them to the incoming volumes, but unfortunately this was using the pre-17 “Source Volume” node, and I can't figure out how to apply the same fix to the new “Volume Source” node. The new one doesn't seem to directly import the volumes at all, so I'm not quite sure how to apply a SOP solver to them. Maybe inside the pyro solver node? Or perhaps you could pull the orient form the position data into your SOP and pre-apply the inverted transforms there. Seems kind of silly, but whatever works I guess.

Thank you for the quick response! I checked out your hip file. It got me a lot closer, using a separate geo node to bring in the transforming geo (with velocity) from the constrained node, then convert to VDBs via the “Volume Rasterize Attributes” node. Adding velocity after the obj_merge reimport gave me weird results and it seemed to work fine adding them beforehand.

While this approach works, I have to think there must be a more streamlined way? It seems so unwieldy to have to create extra geo nodes just for this.

This has brought me around to what seems to be a deeper issue: properly rotating the bounding region for the pyro solve. I set up points along my path that give me the appropriate “orient” data values to use inside a Position data node (or a point position, but that has it's own problem). The issue I'm running into is that this rotates the simulation AND rotates the incoming volumes. So my bounds are oriented efficiently, but my velocities are now facing the wrong way. I saw another thread where someone had solved this by editing the inner workings of the “Source Volume” node, but since that has been deprecated, I'm having trouble trying to imitate the same changes on the new “Volume Source” node.

Summary: I need to make inverse quaternion transforms on the incoming volumes in order to counteract the quaternion transforms which are necessary to properly orient my solver bounds (the “orient” field of the “Position” data). I think.