Adding velocity vectors to SOPs inside animated geo

   2549   4   0
User Avatar
Member
9 posts
Joined: Dec. 2018
Offline
Hey all,
I'm trying to wrap my head around how this is supposed to work. I have a geo node that I'm animating along a path by way of a CHOP network. Inside my geo node I have some geometry which I'm adding velocity to in order to drive a pyro sim. Where I'm running into to trouble is when I set up my DOP network, the velocities that I created aren't being oriented according to the constraints imposed by the CHOP Network. If I understand properly, they're being processed according to world z instead of object z, which is what I need. I may be misunderstanding how things work.

A secondary part of this is that the bounding box created by the smoke object (or is it created by the “Gas Resize Fluid Dynamic”?) is also not orienting to the geo the way I need it to.

I've attached a file which I hope adequately demonstrates what I'm talking about.

What is the most efficient way to fix these issues?

Thanks,
-M.
Edited by DrRoyce - Feb. 27, 2019 17:55:31

Attachments:
constrained_veloctiy_example.hipnc (738.8 KB)

User Avatar
Member
9 posts
Joined: Dec. 2018
Offline
Okay, I made some progress.
I set the position data path on my smoke object to “../Position”, then added a position node after the smoke object and referenced it's rotation fields to the world rotation data from the constrained geo node (via right click->References->Scene Data…).

Now I need to get the bounds right. I set the “Gas Resize Fluid Dynamic” node to use the object level constrained geo node as it's tracking object, which almost works, except the transforms all seem to be inverted. Not sure how to uninvert them.

I'm sure this is all a janky roundabout way to do this. I'm hoping someone can tell me what I'm doing wrong here.

Thanks a bunch,
-M.
Edited by DrRoyce - Feb. 27, 2019 18:42:50
User Avatar
Member
731 posts
Joined: Dec. 2006
Offline
Does this work? I took your birth geo, object merged it into a new object, calculated the velocity, and then added it to the original vel you created. I also did all the volume stuff *before* the transforms… there is no need to recalculate it on every frame, so this should be a lot faster. I didn't jump into DOPs though, not sure what's going on there.

Image Not Found

Attachments:
constrained_veloctiy_example2.hipnc (816.6 KB)

Sean Lewkiw
CG Supervisor
Machine FX - Cinesite MTL
User Avatar
Member
9 posts
Joined: Dec. 2018
Offline
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.

Attachments:
inverse_transforms demo.hipnc (1.9 MB)

User Avatar
Member
9 posts
Joined: Dec. 2018
Offline
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.
  • Quick Links