How To Avoid Volume Stepping?(with an animated source)

[Atom]

Hi All,

I have this animated dragon that is emitting smoke from selected mesh faces. In the fluid source I have turned on Motion Blur and set Frames To Bur = 9 and Geometry Samples to 24. This helps a bit with the volume stepping but I wonder if there is another way to have completely smooth volume trails from an animated emission source?

Edited July 14, 2017 by Atom

[goldleaf]

I like to connect trailed points (or particles) then polywire those curves, to get smooth emission from fast geometry. Something like this, but I'll have velocities on the geometry, and noise it up sometimes to break up the shapes a bit further.

When going this route, sometimes you have to dial down how much density is emitted on each frame; if there is a lot of overlap, it can dump too much density and cause a lot of expansion and slowness.

fast emitter.hipnc

Edited July 15, 2017 by goldleaf

[Atom]

Thanks for that node recipe. I'm going to give that a try. From what I can tell upfront, it lets me use less motion blur geometry samples for sure and I still get a nice smooth source. You are also right about dropping back the source amount to keep the density from building up too much.

Edited July 15, 2017 by Atom

[dudenay]

Most of the time, when i have this kind of troubles with particles or volumes, it's due to missing Sub Steps. When a movement is too fast, increasing Sub Steps on the dopnet or on the popnet>simulation helps to smooth the animation.

But of course, as you say, a smooth source is better.

Edited July 15, 2017 by dudenay

[Atom]

My sim times are already long so I am  trying to avoid substepping. But I may try it out on a test just to see what difference even a single substep can make. Right now I am kind of happy just throwing more geometry samples at the motion blur. I am currently using 52 geometric samples over 5 frames to smooth it out like butter...

Edited July 16, 2017 by Atom

[dudenay]

I can understand why you try to avoid Sub Steps, it has a computation cost! Goldleaf solution is pretty smart.

May be you can also add a Trail node in your Geometry volume source, and  set its result type to "Compute Velocity". So you'll can advect your geometry movement to the volume. I'm not sure that it will totally fill the gaps but it should help with a low computation cost. I made a very small setup with the Goldleaf file. In the Dopnet, you can compare when you source with the velocity or without the velocity.

fast_emitter_velocity.hipnc

[Atom]

That is a nice addition. Did you mean to reference the polywire geometry?

 

In this revised file I chose the polywire geometry for the Object Merge instead of just the plain torus. I also added a bit of Motion Blur to the volume source and linked division size from the pyro to the division size of the FluidSource node.

ap_fast_emitter_velocity.hipnc

Edited July 16, 2017 by Atom

[dudenay]

Yes, I sourced the Torus to make it obvious and simple but actually it is the point to add this to the Goldleaf "node recipe". I've cleaned it a little bit and added some Microsolver, just for fun . And thanx for the link page by the way, i saw your answer and i'll go check the page sometimes.

ap_fast_emitter_velocity_v002.hipnc

Edited July 17, 2017 by dudenay

[tamagochy]

There are couple of errors in file. I've fix it and for my opinion no need to use blur options in source volume. Working much faster ))

ap_fast_emitter_velocity_v003.hipnc

Edited July 19, 2017 by tamagochy

[dudenay]

In the dopnet, I forget to change the type to vector in the gas disturb > disturb_vectorfield > Control_field node of the microsolvers. It's working better now. You pushed the values of the gas_disturb Control Range, which make their influences stronger. Still in the gas_disurb nodes, you tweaked the block size values. You also added the density mask in velocity of the source_volume.

In the Polywire > fluidsource / scalar volumes  you've changed the out feather length in SDF from geometry and tweaked down all the values of the motion blur tab. In fluidsource / velocity volumes / stamp point you reduced it of half.

Do i miss something? Thank you for those fixes ! I appreciate.

[tamagochy]

You are right, its all changes.

[Atom]

I don't think you want to change those GasDisturbs from float to vector. What you really want to do is to use the length of the vector to feed the float input.

[lukeiamyourfather]

On 7/14/2017 at 4:26 PM, Atom said:

The simulation needs more substeps at the top level. The emission source is only one factor here. There are still other parts of the simulation that are moving very quickly (too quickly for the number of substeps). If you increase the substeps it's likely you'll see additional detail and refined motion throughout the entire simulation as well as fixing the emission issues.

[Atom]

Luke, do you have a suggestions for the numbers I should use for substepping? I assume the mean on the pyrosover and not the dopnetwork. Is there some MIN/MAX fall back you routinely use that gives good results?

Edited July 19, 2017 by Atom

[lukeiamyourfather]

25 minutes ago, Atom said:

I assume the mean on the pyrosover and not the dopnetwork.

I mean the DOP network. If you adjust only the Pyro solver I don't think it will affect emission from geometry (double check this, I'm not certain). If you increase the DOP network substeps you can usually decrease the substeps on the solvers contained in it to roughly the same value (e.g. 1 and 100 versus 10 and 10).

[benne5]

I would also add that if you decide to adjust your substeps on the pyro solver you can also adjust your CFL condition.  Higher values will allow the volume to go through more voxels while lower values will limit the voxels it can go through.  

[dudenay]

On 19/07/2017 at 2:25 PM, Atom said:

I don't think you want to change those GasDisturbs from float to vector. What you really want to do is to use the length of the vector to feed the float input.

If you dive inside the gas disturb > disturb_vectorfield > Control_field node you'll see that I've added a length node. To measure the length of the velocity vector, you must specify that you feed the node with a vector. As you can see if you change from float to vector, it's working better. I got that trick from the Applied Houdini Volume tuts by Steven Knipping. Give back to Caesar what is Caesar's...