Jump to content

Mechanica

Members
  • Content count

    11
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Mechanica

  • Rank
    Peon
  • Birthday December 29

Personal Information

  • Name
    Dr. Mechanica
  • Location
    Earth
  1. Substepping between different DOPnets

    In case anyone else reads this and is wondering the same thing, what I ended up doing is creating my particles in the same DOPnet as my pyro, then sourcing them into my pyro sim by way of a "Gas Particle to Field" node and a "Fetch Data" node. The "Gas Particle to Field" does about what you'd imagine, the caveat being that the particles must already be attached to the smoke object. So the "fetch data" (placed in line between the smoke object and the solver) gets the "Geometry" data from the POP simulation and appends it to the smoke object. Then the "Gas Particle to Field" can be pointed to that "Geometry" data. With a smoke sim I think it's probably okay to leave the incoming particle data named "Geometry", but with a pyro sim you might need to rename it if the sim has some geometry data already. Mine did and I'm not sure why exactly, but it could have been from something else I was doing. Here's a nice little write up about it: http://www.tokeru.com/cgwiki/index.php?title=HoudiniDops#Advect_smoke_with_particles Hope this helps someone.
  2. control pyro field for flame thrower

    Hey there, Controlling the size of your flames is going to have a lot to do with the size of your sources, and your combustion settings. Without a bit more info though, it’s hard to give you any specific advice, but you could try lowering the “Gas Released” under the combustion tab to get less expansion. If you post a hip file of some sort people can probably give you a little more help.
  3. Hey all, I'm trying to get a better grasp of best practices for managing substeps between two separate DOPnets. I have a DOPnet that takes in moving geo and outputs particles, which I rasterize to a volume, then source into another DOPnet as fuel, temp, etc. for a pyro simulation. What I'm wondering about specifically is how to keep these two DOPnets in sync. i.e. I want to make sure only newly generated fuel is sourced into the pyro sim, not fuel that's already "burned". My concern is that if the POPnet creates particles with life longer than a substep on my pyro sim, they will be copied into the pyro multiple times. It seems like it would be best if the particles and Pyro were created in the same DOPnet? I don't know enough about how any of this works though.
  4. Optimize Pyro Container, H17

    @vtrvtr No need to apologize. I appreciate you responding at all! I was having a lot of trouble with your file as it just didn't seem to do anything! Then I realized the scene view was pinned for some reason. Doh. But @Andrea is correct. Volume sourcing appears to behave differently between 17.0 and 17.5, which makes me think the way they did it in 17.0 was probably not intended. Essentially in 17 the volume was sourced in, then translated according to the point position, then a bounding box built around it, which is very inflexible. In 17.5, the point position only moves the bounding box, as one would expect, so it probably works about as mentioned: build bounding box, then source voxels. So the solution to my problem was to upgrade. Also of note, even after upgrading, my velocity volumes were not being sourced in properly. This is an old problem, but I guess it's still there. I followed this tutorial to learn how to fix it: https://gumroad.com/l/lAcVQ. Essentially you need to source your velocities into a temp field (let's call it tvel), rotate them by the orient, then add them to the vel field. I took some screenshots to illustrate this. Might be old hat for people, but it was news to me: I hope this helps anyone having the same issue. Not sure how one would fix this pre-17.5, but with a good understanding of DOPnets it could probably be done?
  5. Optimize Pyro Container, H17

    So, I figured out how to solve my issue, but it's a janky workaround and it creates more problems. Essentially, you can't move your source volumes at all if you want to use pointPosition. You have to let it do everything. This could be okay if you only had one source volume and nothing else in your scene. But if you have geo that your sim is supposed to line up with, you have to calculate an animation path for your source volume, as it would travel attached to your main geo, then make frames and orients from that. Convoluted, but doable. What if you have 2 or 3 separate source volumes (say, temperature, fuel, and extra velocity) all positioned slightly offset from one another? Okay, you can create 3 separate animation paths for them, then... what? Have 3 separate smoke objects? That doesn't make any sense. You could merge them, track what would be their animation path, and bring them into your DOPnet with a single Volume Source node. It's really hard to maintain the volume's position relative to the other geometry this way though (for example, the body of your rocket). I'm stumped. Edit: Nevermind, merging doesn't work, as the pointPosition transforms are applied to each volume individually. So they all end up in the same (wrong) place.
  6. Optimize Pyro Container, H17

    Thanks for the responses! Vtrvtr, I tried your file but the DOPnet doesn't produce anything. I guess because I'm on 17, not 17.5. Didn't realize they'd changed so much. I notice in your example though the emitted smoke appears very stiff, like it's being dragged along by the source, instead of emitted out into space. As in, when the source goes around a bend, the smoke that's already emitted shouldn't follow it like a stick, it should maintain it's own momentum, right? How would you approach trying to implement that? Clever way you're using the carve to animate along the curve by the way, that's nifty!
  7. Hey everyone, I'm looking for a little help on a pyro sim I'm doing. I've got a fuel and temperature source that move along a path, emitting flame. The goal is to make a look like the flame is propelling an object forward, like a jet engine. I'm able to achieve most of this easily enough, but my sim has a lot of wasted space because the sim container doesn't rotate with the movement of the source. This really slows everything down and it's driving me crazy. I've tried a few things that used to work in H16 (the "point position" node specifically), but H17 sources volumes differently and won't play nice (the sim will rotate the already rotated source volumes again). Most of this I learned here https://gumroad.com/l/TqUNR, which no longer works properly with H17's volume sourcing. Anyway, if anyone could help out with this it'd be great. inverse_transforms_6.hip
  8. Rotate pyro container

    Man, those are really great tutorials, but unfortunately the techniques they implement seem to be completely broken in H17. Appears to be an issue with the new Volume Source node. It just doesn't want to play nice with the "Point Position" node. So disappointing.
  9. Rotate pyro container

    Hey thanks so much! I have actually seen this one, though I'm thinking now I probably ought to go back and just take another look through it and see if I missed something he's doing. I appreciate the tip! Edit: This is probably exactly what I'm looking for. Realizing that I bought and watched part 1, but not part 2, which seems to cover the info on forces etc. Thanks again!
  10. Rotate pyro container

    Hey, thanks for even taking a look! Yeah, sorry it’s a little complex. I tried to simplify it as much as possible while still keeping everything that seemed essential to the equation. I’ll see if I can make it lighter. Interesting idea. I had a version somewhat like that where I ran the the sim stationary at world origin, only pulling in the rotations from the current point on the curve, then afterward constraining everything to the curve. I managed to make this work, but the problem I ran into here was the pyro being emitted acted like a stiff object being pulled along by the sphere, as opposed to particles emitted into space. What I mean is, the flames would shoot out into a big mushroom, and then drag along in that shape like a weird parachute, instead of being pulled out long. What I didn’t try was rotating the curve itself. That’d be curious, to have the curve pivot on it’s own orient points so that the current point’s axes always aligns with 0,0,0. Then move EVERYTHING into place post sim. I can give that a try. Edit: Thinking about it more, won't rotating the curve itself just make a sim that moves in a straight line? That way it won't throw things out into space, creating a flame that rotates with the source, like a stick stuck in a ball?
  11. Rotate pyro container

    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
×