Optimize Pyro Container, H17

[Mechanica]

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

[tamagochy]

Use clusters

[vtrvtr]

Here's an example of orienting your box in H17.5. Since Sidefx is doing most sourcing on SOPs now, I did the same for the matching orientation

 

https://giant.gfycat.com/ExcitableDaringArizonaalligatorlizard.webm

 

 

houdini175_orient_pyro_odf.hipnc

[Mechanica]

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! 

[Mechanica]

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. 

Edited March 19, 2019 by Mechanica

[Andrea]

@vtrvtr nice stuff!

 

The bounding box is following the path and the curve orientation but the translation is applied twice here in 17.0.352 . I have tried to import in DOP the original geo and you can clearly see it.

Ideally I think for solve this issue we should first orient the bounding box and then populate the voxels with the source volume, if it makes sense. 

 

[vtrvtr]

@Mechanica

Sorry for the late reply. I didn't do anything to the source, you can absolutely control the emission to suit your needs. The file there is exclusively to demonstrate the container transformation

Also, there's a reason this setup isn't mentioned anywhere officially. You'll have to fiddle with it to get it working properly. You might also want to use clusters, as previously suggested. Which is another setup that needs fine tunning

There's a thread in this forum about smoke tricks that contains a custom resizing method. You might want to take a look at that

@Andrea

I don't have have 17.0 currently, so I can't test, but unless I'm misunderstanding you, it doesn't seen to be translated twice in 17.5

[Mechanica]

@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?

Edited March 19, 2019 by Mechanica

[Andrea]

Thanks for the explanation on how to fix the vel problem Mechanica.

I think that, at least for now, the best option is to convert the animation of an object to follow one axis and after the simulation rotate everything back. Sadly it's not always possible.

 

I wish this could be a lot simpler. For example just create a box in SOP, rotate it how you prefer and use this as bounding box. 

[Homestudio29]

On 19-3-2019 at 8:44 PM, Mechanica said:

@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?

Sorry to bump this old thread. But when I do exactly what is described here I get the error: "Read-only expression on the left side of the assignment (2)", so @vel is a read only in my case. Did you have this aswell or how did you avoid it?

 

Kind regards,

Chris

[Lou]

Did you make sure that you put " ../Position " in Position Data Path on the initial data of your smoke object? For my case that was the problem.

 

[marles]

hey @Homestudio29
if you want to avoid this error message you have to write "vel" into the "binding to export" parameter on the snippet vop node. That allows you to export/rewrite the vel field, otherwise you are only able to read this one and you get the error message.

[loudsubs]

Been trying to crack this one since they changed the sourcing.  Few variations here. Done in 17.5

vel_test2.hip