Sparse grid reducing drastically over one frame

Hi all,
I’m stuck on this sim and can’t work out what is breaking it. It builds up adding density over 200 frames, then the sparse grid shrinks in over one frame (see gif above) and the rest of the cache/sim is broken from there.

Got any ideas I could try? Ive tried so many different things and still getting this result. I’m sure its something stupid.

I’ll email a dropbox share of the shot folder. Anything you could think for me to try in the meantime would be appreciated.


  • Eddy version 1.7
  • Nuke version 10.5v4
  • Operating system win7
  • GPU model 1080ti
  • Graphics driver version 388.31

Hi Matt,

This does look odd. I’ll look into this.

Have you tried caching the sim to disk using the caching node? I’m curious if this is related to running the sim live(?).

It looks like you loose pretty much all your data between two frames. There are only a few things that could possibly cause a large issue like that. So if you want here are a few things you could try while I get to the bottom of this on my end:

  • Disable automatic caching - if for some reason a cached state is read by mistake this could be the result.
  • Disable multigrid acceleration - the multigrid solver is quite robust but if it fails for whatever reason it could cause an issue like this.
  • Disable automatic grid padding (or as a debug test set automatic grid padding aggressiveness to 0) - the auto padding heuristic should not be able to cause something like this but as it modifies the active space it would be good to rule it out anyway.


Hi Andreas, thanks for getting back to me.

Thanks for the suggestions, I haven’t tried disabling multigrid. As a side note, i always have grid padding aggressiveness at 0 since it was made default. Should I be changing this every-time? Or only if i saw unwanted clipping or something.

Anyway, I’ve got the sim to run correctly tonight!
I may have found a bug though im not sure. If I use different character rigs for the collider portion it simulated fine. if I use the proxy rigs it breaks every time. On closer inspection now, the proxy rigs i received have one mesh error which may be causing problems. Its a tiny non-manifold face inside the characters armpit. Looking closer at the mesh that works, it has similar errors though so I’m at a loss here.

in any case, I have a reliable case you guys can use to test if you wish.
With the data i sent via email,

  • open eddySilt_020_060_VORTECHS.nk
  • run sim to see error if you wish.
  • ReadGeo10 and ReadGeo3 in the Collider sections are the culprit. (similar small mesh errors in each)
  • Switch these out for the **** versions in the same folder. and re-run to see it working.

Examples of the mesh errors. theres one in each proxy character. They show up with a Mesh-Cleanup in maya with Non-Manifold turned on.

With any characters i get now i plan to remesh and reduce in Houdini or Zbrush for this type of work.

Thanks again.

Thanks for the info - very helpful!

The main issue is indeed that the mesh is non-manifold. In general it is recommended to use manifold meshes for Eddy collision objects. However - non-manifold meshes should still work so I’ll look further into what went wrong here.
In the non-manifold case the mesh to volume node would interpret the mesh as a shell with a thickness defined by the Shell Width parameter.

As a result the surface of the crab is double sided and the inside of the crab is hollow. This can be seen by slicing the resulting distance channel data using a crop window:

You’ll find that once the mesh is a closed manifold the resulting volume will be a better (higher resolution) match of the crab geo.

1 Like

Ahh of course. I’ll look into making a closed manifold version of the characters.

Just some more info, with those proxy models, the time in shot it broke the sim wasnt consistent. It was usually around frame 150 of a sim give or take 30 frames. It also happened the same in multiple shots.

Thanks again