I am simulating an ocean with a BOSS plane as a Guide and a boat as a emissionRegion.
After about 100 frames of successfull cache writing Maya throws this error in the Output window and freezes.
bifrostfluid.dll!Bifrost::MeshVolume::Worker<Bifrost::MeshVolume::Traits<Bifrost::VoxelShape> >::operator=
bifrostfluid.dll!Bifrost::MeshVolume::Worker<Bifrost::MeshVolume::Traits<Bifrost::VoxelShape> >::operator=
tbb.dll!tbb::interface7::internal::task_arena_base::internal_initialize
tbb.dll!tbb::task_scheduler_init::initialize
tbb.dll!tbb::task_scheduler_init::initialize
tbb.dll!tbb::internal::thread_sleep_v3
MSVCR110.dll!_beginthreadex
MSVCR110.dll!_endthreadex
KERNEL32.DLL!BaseThreadInitThunk
ntdll.dll!RtlUserThreadStart
Hello,
Would you be able to package up your scene and attach it so we can test it on our side?
Also, any details about your hardware and OS would be helpful.
Thanks!
Any update or help on this? This is becoming a showstopper and i really regret not having used Houdini for the Sim.
I already tried it with different MVS settings without succes.
Hi,
Can you give us some more information with what is in your scene:
If you are able to reproduce the hang with a simpler scene to avoid the NDA and send it our way, that would be helpful.
Thanks
Thanks for getting back. I am pretty certain that the problem comes from collision geometry. It is a geometry being destructed by the ship (Houdini Sim imported as Alembic and used as collider).
I am using a cached BOSS surface as a Guide using the BOSS cache workflow.
The emission region boat mesh is also a collider. I will later try your suggestion with the motion field to push out particles. But i dont think the boat collider is the problem. I think it is the other collision geo. Beacuse it is very detailed.
That's useful information.
Have you isolated the crash to being caused by the destructed collision geometry for sure? If so, here are some more suggestions:
If it still crashes without foam:
On my side, I was able to simulate 130 frames on Windows 10 in Update2 without a crash, so at least we know the basic workflow is not the issue (see image).
I could send you the scene if you like.
Thanks!
Hey, thanks again.
I already tried robust method with cosrsen interior. There is no foam in the scene now. I want to add it later.
Without the destruction collision it simulated without erros beyond the 100 frames as expected.
I am simming right now with higher resolution and some changes. Will let you know if it crashed. I added a Motion field. But maybe it will not help as you said it has mostly to do with foam..
It crashed again. Why is there no logging? Even when using the verbose mode i get almost no info at all!
How is one supposted to work with bifrost in production? My time is running out. I will check if i can upload the collision geo Alembic file for you. Is there a private place to upload?
Hello,
After reproducing your issue and conducting many tests and trying various workarounds I finally narrowed down the cause of the problem:
The Houdini rigid body simulation mesh used as Bifrost collision geometry has several instances of rogue polygons flying out into infinite space.
This creates a volume so large that Bifrost can't compute the voxelization for collision, and so it stalls.
I was able to avoid this issue by cleaning up the Houdini mesh: Frame by frame isolating the rogue polygons and deleting them. After doing this, I could break through the threshold of frames where I was getting the crash (for me it was 108 frames) and the simulation continued as normal, up until the next set of frames where the mesh had not been cleaned.
I recommend optimising your collision mesh for simulation, to allow Bifrost to do its job properly.
Thanks!
Kosta
Hey Costa!
Thank you for looking into this issue. I will check with our Houdini guy and the try again.
Good to have some good support on Bifrost on Autodesk side.
Cheers!
Florian
Hey Costa,
might using the Boundary Control on the colliderProps solve the problem? Did you try that already?
Hi Florian,
I did in fact try that but it didn't work. I was baffled by this until I realised our current implementation of boundary works by first looking at the entire geometry and then just keeping whats inside the boundary, instead of just not caring about what's outside the boundary. Because of this, it still fails in this case.
Hopefully we can improve our implementation of this feature to make it more efficient.
Thanks,
Kosta