Ah, thank you so much Jeff/Enivob; I thought I had checked that help card for an example and missed it but I must have not had my coffee before doing so. This is quite interesting to learn about, thanks!
Though, I also tried Enivob's suggestion of turning off “Kill outside volume”, which, as it turns out, might be a super-useful debugging tool for my animated collider/tank situation here. I noticed before doing so that when I visualized velocity as a color, I had a few ‘pockets’ of what seemed like sporadic, high-velocity areas. I can't quite figure out where this is coming from, but when I disable “kill outside volume”, I see that these areas are creating big ‘splashes’, and I wonder now if my tank draining has less to do with volume preservation and more to do with these ballistic events pushing particles into the interior of my collider and then being killed.
I'm still debugging what exactly is causing this problem. To elaborate slightly, I'm reading my collider via a sourceVolume; it's a VDB with velocity fields, which are being created via a Trail sop. When I visualize the Trail, the velocities look totally sane and have nothing to indicate sudden transitions that might cause ballistic events. I'm curious if anyone has advice about other rocks I might look under to figure out what might be causing this kind of behavior?
Thanks!
Found 206 posts.
Search results Show results as topic list.
Technical Discussion » Preventing volume loss in long FLIP sim
- dhemberg
- 207 posts
- Offline
Technical Discussion » Preventing volume loss in long FLIP sim
- dhemberg
- 207 posts
- Offline
Hi Jlait, thanks for this response, I hadn't seen this strategy elsewhere. Could you provide an example HIP file that elaborates on setting this up properly? Or, may I ask for some elaboration?:
–How/where does one calculate the target volume? I'm not sourcing anything; I'm filling a tank with particles using pointsFromVolume at the SOP level.
–Where does the gasEqualizeVolume node itself go? Inside the FLIP solver or as an input to it (and, if the latter, to which input?) Tearing apart the FLIP solver isn't something I've done much of before (though I'm happy to learn).
Thanks!
–How/where does one calculate the target volume? I'm not sourcing anything; I'm filling a tank with particles using pointsFromVolume at the SOP level.
–Where does the gasEqualizeVolume node itself go? Inside the FLIP solver or as an input to it (and, if the latter, to which input?) Tearing apart the FLIP solver isn't something I've done much of before (though I'm happy to learn).
Thanks!
Technical Discussion » Preventing volume loss in long FLIP sim
- dhemberg
- 207 posts
- Offline
Hi there;
I have a FLIP sim that I'd like to run for around 1000 frames. I'm struggling with volume loss over that range though, and can't seem to figure out how to fix it. My colliders are slow-moving, and I can verify there's no water “leaking”. I can see my particle count decrease steadily over time, as if my tank is ‘draining’.
The few resources I've seen suggest strategies including:
–enabling Apply Particle Separation (I've done so, left values at defaults, see no visual difference)
–Raising Particle Radius Scale, which feels a bit like a cheat, and which effectively eliminates high-frequency details that result from a low Particle Separation value on the FLIP object.
I know this problem is an inherent one to FLIP solvers, but also know artists often create long FLIP sims to use with time offsets through multiple shots in production. I'm curious what other strategies I can take to minimize or eliminate volume loss?
Thanks!
I have a FLIP sim that I'd like to run for around 1000 frames. I'm struggling with volume loss over that range though, and can't seem to figure out how to fix it. My colliders are slow-moving, and I can verify there's no water “leaking”. I can see my particle count decrease steadily over time, as if my tank is ‘draining’.
The few resources I've seen suggest strategies including:
–enabling Apply Particle Separation (I've done so, left values at defaults, see no visual difference)
–Raising Particle Radius Scale, which feels a bit like a cheat, and which effectively eliminates high-frequency details that result from a low Particle Separation value on the FLIP object.
I know this problem is an inherent one to FLIP solvers, but also know artists often create long FLIP sims to use with time offsets through multiple shots in production. I'm curious what other strategies I can take to minimize or eliminate volume loss?
Thanks!
Houdini Learning Materials » "JoinStrings" VOP
- dhemberg
- 207 posts
- Offline
Can you elaborate on this approach? I'm basically trying to bind a per-object attribute (like, e.g. a sprite frame number), and I need to build a file path from this. The bind has to happen inside the shader builder obviously, but it's not clear to me how to use python inside a shader builder.
Technical Discussion » Rendering multiple mixing fluids
- dhemberg
- 207 posts
- Offline
Hi;
(Coming from a Renderman RIS background, which has its own notions of how to do this), I'm curious what the ‘most correct’ way to render multiple mixing fluids (or, what Renderman calls a Heterogeneous Volume) in Mantra is. A simple use case is cream in coffee, or ink in dyed water. The two fluids have different attenuation/singleScatter/HG Phase coefficients, which I'd like to vary across the volume.
The Physical SSS shader VOP, for example, seems to contain the most complete interior/volume control set (attenuation/singlescatter albedo/phase controls presented as both Artistic and Coefficient-based), but it seems not-quite-right to use subsurface to represent this.
Or, I could refract a volume that has varying color/density, but there doesn't seem to be a volume shader node that allows me to vary HG phase, nor would I be able to volumetrically-vary attenuation in that case (attenuation is a surface property of the refraction lobe).
Might anyone have some advice about how do set this up properly?
Thanks
–a
(Coming from a Renderman RIS background, which has its own notions of how to do this), I'm curious what the ‘most correct’ way to render multiple mixing fluids (or, what Renderman calls a Heterogeneous Volume) in Mantra is. A simple use case is cream in coffee, or ink in dyed water. The two fluids have different attenuation/singleScatter/HG Phase coefficients, which I'd like to vary across the volume.
The Physical SSS shader VOP, for example, seems to contain the most complete interior/volume control set (attenuation/singlescatter albedo/phase controls presented as both Artistic and Coefficient-based), but it seems not-quite-right to use subsurface to represent this.
Or, I could refract a volume that has varying color/density, but there doesn't seem to be a volume shader node that allows me to vary HG phase, nor would I be able to volumetrically-vary attenuation in that case (attenuation is a surface property of the refraction lobe).
Might anyone have some advice about how do set this up properly?
Thanks
–a
Edited by dhemberg - 2016年12月31日 11:57:57
Houdini Learning Materials » "JoinStrings" VOP
- dhemberg
- 207 posts
- Offline
Hi;
I'm curious if anyone can help explain the “joinStrings” VOP; specifically what data type its first input is (and how one might create such a data type). The documentation doesn't seem to cover this, and I can't find information out in the wild.
To give context: the thing I'm trying to do is assemble a file path in a shader. So, say:
string fileBase;
int spriteNumPP;
string extension;
string file = fileBase + spriteNumPP + extension;
At the moment, the way I'm hacking around this is in SOPS, by storing a completed filepath on my geometry using VEX. But this is super-inefficient, and, coming from an RSL background, I'm looking for a solution on the shader side of things.
I'm curious if anyone can help explain the “joinStrings” VOP; specifically what data type its first input is (and how one might create such a data type). The documentation doesn't seem to cover this, and I can't find information out in the wild.
To give context: the thing I'm trying to do is assemble a file path in a shader. So, say:
string fileBase;
int spriteNumPP;
string extension;
string file = fileBase + spriteNumPP + extension;
At the moment, the way I'm hacking around this is in SOPS, by storing a completed filepath on my geometry using VEX. But this is super-inefficient, and, coming from an RSL background, I'm looking for a solution on the shader side of things.
-
- Quick Links