Wet map - water texture causing dark shadows on geometry,

[JD3D_CGI]

I don't understand why the water is getting to the inter penetrating segments though.

In any case, it looks like it would be impossible for phoenix to do this then, because there's no way anyone can animate hands washing without some degree of intersection right?

[Svetlin.Nikolov]

Hey,

I suggest to split the hands into two separate meshes and give it a try this way. The problem with open/overlapping geometries is that the solver velocity field becomes incorrect because voxels which are outside the geometry start acting as if they are inside and vice versa - this might cause accumulating of high velocities or might not - depends on the topology of the scene. This is why often one can get away even with problematic geometries without even noticing - because explosions don't necessarily happen all the time there is an issue. In this case the bulk of issues happen only when the two hands intersect - the fingers interpenetrating messes up 1 or 2 voxels for 3-4 frames, while the intersecting hands created much more havok than this

I hope not long from now we'll be able to introduce a robust voxelization mode that would be able to deal with any kind of geometries so you won't have to worry about such issues.

Cheers!

[JD3D_CGI]

I'm not sure how to split them into separate geometry? Like with point caches maybe?

I guess you said you tried it and or didn't work? Maybe there's a way to I can go frame by frame for theatre offending sections?

Would making one a boolean cutting the other work?

And can you recommend a way to determine if two objects are intersecting if they are separate geometry?

[JD3D_CGI]

Thanks for your help by the way!

[flipbook]

Would xmesh or alembic (cached to one object) allow phoenix to see it as combined?

[Svetlin.Nikolov]

Hey,

I'm adding a preview of the voxels which the solver can't figure out as we speak - it will be the last entry in the Output rollout -> Special channel dropdown for tomorrow's nightlies and you'll be able to preview it in the viewport after running a sim. Note that this will be dependent on the grid resolution as well - with lower or higher resolutions the problematic voxels might change their numbers or disappear completely, depending on how the simulator grid is oriented around the geometry. Also you can turn off liquid emission or animate it only for the first frame so there will be some activity in the sim, and then reduce the Steps per Frame and let a quick simulation pass though all the frames so you'll be able to see if there are any issues more quickly. I hope this would be a useful addition because it's not easy figuring out if something is wrong in such cases - right now you can search the Phoenix log for "[WARNING]" and there it shows up, but it's not too friendly that way.

What we did for splitting the hands into two separate meshes was an ugly hack though - duplicated the hands geometry and removed all left arms from the Skin->Envelope of the first copy and vice versa, thus getting four arms of which two were animated.

With the arms being in separate meshes there were way less problematic voxels, and since not each such voxel may cause an explosion, chances are good that this would work. I would be able to tell if everything would be okay in a few hours after the sim finishes..

Here are a couple of shots with the hacked mesh and the original one, using the same grid resolution but a narrower container, which should speed up the sim without changing the voxelization: