I have a flip + whitewater sim which I've cached with all properties, now I'm slowing it down 4x (i.e. timewarp frames 1…6000 stretched to 1…24000) and I'm using timeblend (i.e. cache -> timeblend -> timewarp -> NULL_OUT)

Most of it is working, but for some reason there are some artifacts, some (very few) particles are not being interpolated. You can see what I mean in these videos (I'm rendering as seq of tiff with alpha and I've tried 3 diff alpha matting methods -ignore, straight, premult - and it's noticable on all).

https://www.dropbox.com/sh/wo2fm2qjd87vhbw/AACkLgoOCqFzehwz8pLyLEfGa?dl=0 [dropbox.com]
(especially obvious when watched frame by frame).

in the link above I've also included a tiny segment of my raw data and a minimal hip file which shows how I'm doing the timewarp+timeblend

I have no idea what this is, or even how to debug it. Any ideas welcome!

I thought timeblend required the vertices count to remain constant, like an animated character? This is not the case with a fluid sim. You have vertices being added and removed as the sim progresses.

Yes, you should in flipsolver active add ID attribute in case that you want timeblend it.

Hi, thanks for the answers.

In the flipsolver, I do have ID enabled, and I also have reseeding disabled, and ‘kill outside volume’ also disabled. The particle count per frame is constant.

The whitewater is obviously created and destroyed on the fly. However the artifacts that I'm seeing aren't consistent with what I'd expect from particles being created / destroyed on the fly.

I'd say about 95-99% of the whitewater particles are being interpolated. It's just very small clumps which aren't, and they are just being updated in position every 4 frames (which is how much I'm slowing it down by).

It's quite clear in the video's on my dropbox link, especially on very top edge of the wave as it falls down (especially on the alphaignore.mov, and when stepping throw frame by frame. it's only a 3 second video).

The frozen particles are because they don't find a version of themselves in the next frame. When the timeblend doesn't find a matching id, it just doesn't blend the particle. Thus they freeze just before they are deleted.

In the attached I've unlocked Time Blend and added an attribute wrangle with:


if (idtopoint(1, @id) < 0))
removepoint(geoself(), @ptnum);


in the blend path. This will delete all points which don't exist in the next frame. Since we are using as our start the floor frame, there is no need to worry about points that are in the next frame but not the floor frame.

idtopoint() I think is new to H15, but it is a utility function around findattribval:

//
// Look up functions
//
int idtopoint(const string opname; const int id)
{
if (hasattrib(opname, ‘point’, ‘id’))
{
return findattribval(opname, ‘point’, ‘id’, id);
}
// No id attribute, so match by ptnum, but test we
// have not gone past the end!
if (id < npoints(opname))
return id;
// Not found
return -1;
}

Hi Jeff, thanks so much, super useful!

The method you posted works and does remove the non-interpolating points. But I'm trying to understand why this is even happening. Using your fix I was able to isolate and examine the points that weren't interpolating and found that every frame about ~12K points out of ~600K points are missing, i.e. exist for only 1 frame (~2%). In the geom sheet I couldn't see anything else special about those points. Why could this be happening? (i've included that analysis hip, and also my original foam generator hip+otl in the same dropbox link).

cheers,

A large share of those points are being deleted because they have hit end of life. Looking at age & life shows them within a frame of deletion.

The younger ones I am not so certain. I presume that since this is a white water foam solver, they are being deleted because they have stopped counting as foam particles. If they transition to spray or bubbles I believe they get deleted if those paths are not enabled.

You could run a pre-pass over your data to look X frames ahead and see if the particles still exist. If not, you can add an attribute storing their pending death, and then use an alpha to fade them off so they don't just vanish.

I'd also recommend switching to .bgeo.sc rather than .bgeo.gz. This sequence loads twice as fast for me by doing that for only 10% more space

ah interesting. Yea the ones that die because they reach the end of their life should be faded out already (I ramp size based on age/life), but it's the young ones that are puzzling me. But the pre-pass sounds like a doable workaround.

thanks for the tip on .bgeo.sc, I hadn't even heard of it.