VDB Jitter continues...

[Jebbel]

Hi guys,

 

Be easy on me; Houdini noob here  . Just started learning H14 two weeks ago and now working on FLIP fluids for a commercial. The footage is great! We shot with a Phantom camera at 1600 FPS and am now matching fluids that need to flow out of glasses (people are jumping in the air).
Actually managed to almost complete it but then came across jittering in the VDB meshing. It seems to be related to the influence scale and droplet scale (and ofc. all parameters attached). 

 

In the end I got way better results with a ParticleSurface node attached to a smooth node (Next time I will add a SOP peak as well . Anywho... It seems I get way less jitter, more detail and more control with this type of meshing so I'm trying to figure out where the strength of VDB lies (and how it works). And my second question is: Can anyone explain how CFL condition works in relation to building a realistic fluid sim.

 

Thanks guys!

 

Jeffrey.

Edited February 20, 2015 by Jebbel

[pbarua]

I never got VDB jitter issue.

 

If you are working on large scale where speed does matter VDB is far ahead from standard particle fluid surfacer.

If you are on low scale like glass of water, chocolate, honey etc..... standard meshing is better option. It gives you better mesh compare to VDB. 

[pbarua]

In short if camera is close and didn't simulated enough particles, go for standard meshing. To be honest from Houdini 12.5 I never personally used this and even forget this sop exists.

Edited February 20, 2015 by Pradeep Barua

[Jebbel]

Thank you Pradeeb,

 

So what I'm getting from your explanation is that VDB meshing needs a lot of particles to be accurate? I will definitely test that out . For now... and for this scene the standard surfacer seems to the way to go.

[ranxerox]

 the CFL condition determines when substepping will occur,  according to how fast a particle is moving in relation to the particle separation parameter.  The larger this value,  the faster your simulation should run in general,  but the less accurate it will be.  If you can get away with a large CFL condition,  than do it,  because your sim will run faster.  I believe it is most noticeable in areas where collisions occur.  If you are confused than just leave it at default..  it is really there for optimization.  If you are having noticeable errors in collision areas,  you might lower it.

 

 -G

 

Hi guys,

 

Be easy on me; Houdini noob here  . Just started learning H14 two weeks ago and now working on FLIP fluids for a commercial. The footage is great! We shot with a Phantom camera at 1600 FPS and am now matching fluids that need to flow out of glasses (people are jumping in the air).
Actually managed to almost complete it but then came across jittering in the VDB meshing. It seems to be related to the influence scale and droplet scale (and ofc. all parameters attached). 

 

In the end I got way better results with a ParticleSurface node attached to a smooth node (Next time I will add a SOP peak as well . Anywho... It seems I get way less jitter, more detail and more control with this type of meshing so I'm trying to figure out where the strength of VDB lies (and how it works). And my second question is: Can anyone explain how CFL condition works in relation to building a realistic fluid sim.

 

Thanks guys!

 

Jeffrey.

[Leroy Harra]

I was battling this same issue recently.. It appeared especially badly when on extreme slomo. Sometimes things get connected on one frame and disconnected on the next one, holes appear and disappear and so on..

 

I managed to make it quite a bit less jittery in the end, i think i used a small voxel scale (more details and polygons after the convert), and droplet scale was referencing the influence scale with a multiplier of 0.9 or something. The values cant be the same so i linked the droplet to the influence scale. If i remember correctly i used values close to 1, after running a lot of iterations -all i got out from bigger values introduced more popping, drops connecting into a "line of liquid" and holes..

 

Also i think it helped when i used VDB Smooth after the initial surface was built, which made it much more stable.. Just play around with the amount of iterations and the different methods of smoothing. You will lose detail when smoothing, but maybe it helps on your case. On the convert VDB to polygon thingie, try the adaptive, it creates a less complex mesh and sometimes helps with the surface. Its very sensitive value, creating really lowpoly meshes especially when the source vdb surface is not very high res..

 

Havent tested the old method, my client was happy with the result so that time i didnt investigate that much further on it but i got the feeling that super-slomo is very tough on the VDB meshing method.. I suppose it also always helps to use more res on the sim underneath.. Need to dig into this more, slomo liquid is always hard to do anyhow as its got such weird characteristics when filmed..

 

-Iiro

[Leroy Harra]

Btw, You might want to check out Alessandro Pepe's website http://pepefx.blogspot.fi/, there's a post called "Ink in water" (the VDB advect is pretty fast trick, too), but he also introduces a simple way of replicating points afterwards..

 

The code he's using is as follows: (you need to paste the code to attrib wrangle, and create the parameters searchrad,mindist,maxpoints etc. for the code. also you need to plug the same node to input1 & 2)

 

float searchrad=ch("searchrad");

float mindist=ch("mindist");

int maxpoints=ch("maxpoints");

int fillpoints=ch("fillpts");

 

vector clpos;

int handle=pcopen(@OpInput2,"P",@P,searchrad,maxpoints+1);

int i=0;

while(pciterate(handle))

{

    if (i==0) // the first point found should be the closest, in this case, itself. We want to skip it.

    {

        i++;

        continue;

    }

    pcimport(handle,"P",clpos);

    if (length(@P-clpos)>mindist)

    {

        vector pointstep=(clpos-@P)/(fillpoints*2+1); // this ensures there are no duplicate point

                                                                                  // at the cost of doubling the fill points number

        for (int t=0;t<fillpoints;t++)

            addpoint(geoself(),@P+(pointstep*float(t+1)));

    }

}

 

you can make a digital asset out of this for simply multiplying points, its quite handy sometimes when you just need more points.. You can set the minimum and maximum search distance and the amount of neighbors and it creates more points between the original ones. Just attribtransfer your previous point attributes (v, Cd etc.) back to the new ones as i dont think it cares about them.. You might get more mass for your volume this way without needing to re-sim..

 

-Iiro