Search the Community
Showing results for tags 'bounds'.
Found 2 results
Hello everyone, So the basic idea I'm trying to achieve is some geometry emitting a flame following a path. Not really difficult and I've got the basic version down. The trouble starts when I try to implement a rotated container for efficiency. My object doesn't travel at 90 degree angles on a perfectly aligned grid, that'd be boring! So why should I waste time simulating all that empty space? So what I've got is a geo node with a CHOP Network inside, constraining it to follow a path from a separate geo node. I create some velocities for my path-following, constrained object, then rasterize to volumes, as per the H17 workflow. Then in my curve object, I create orient data according to it's points, which I feed into a "Point Position" for my smoke object inside my DOPnet (I then drive it's "point number" parameter with a setup that determines the point along the path that is nearest my constrained object's center). Hooray, the container rotates along the path! Don't party yet... The point position node sets the "Position" data to pivot 0, and the translate data to match whatever "point number" it's looking at, causing the rotations to be applied around world center. But only for the incoming volumes, not the container. The container is positioned exactly where you would expect (perhaps because of the "Gas Resize Fluid Dynamic"). This seems kind of stupid, and I'm not sure when this would be useful. Maybe if the transforms were on the source volumes but NOT their containing object? I don't know. To solve this we next add an RBDState node because apparently it's one of the only other nodes that can write to the position data (THAT took a while to figure out). In the RBDState node we set the pivot to reference the translate of the original emitter (which is constrained to move along the path), and the translation (confusingly parameterized as "position") to zero, and set both of these parameters to "Set Always". Good god we're so close... But no. The container is correct, following our emitter's orientation along the path. The volumes are there too, centered where they should be, but wait... They're double rotated now. They get the rotation that's applied to the source volumes by the CHOP net in the object where they're created, AND the same rotation applied again from the "point position" node. I'm having a devil of a time with this. If anyone can help I'd be very grateful. There's another thread here: where someone managed to fix this by editing the old "Source Volume" node, but it doesn't seem to work the same way with the "Volume Source" node, or at least that I could discover. inverse_transforms_demo_4.hip