Unwanted ground collision

[JuhaHo]

I wonder why there seems to be a ground collider in my simulation. The ground collider has been disabled. 

I'm using beta. I have purchased the Proversion and I will install it when I get new workstation to avoid license transferring issues.          

[tim@wangsoderstrom.com]

Hello,

You need to disable groundcollision in the physx rollout in the tyflow object:

[tyFlow]

Yes, the default PhysX ground and gravity is an idea borrowed from PFlow. Sometimes it's handy, sometimes...not As tim showed, easy to disable.

As for PRO, remember that license migration is pretty easy so no need to wait for your new workstation if you want to start using your license. If you run into transfer issues when you get your new machine (let's say you get rid of your old machine and forget to deactivate first), no problem, just email support@tyflow.com if that happens and I'll get you sorted out. Please feel free to start using your license today!

[JuhaHo]

Thanks very much, it was simple and worked.

Anyway, I have another issue with this scene since the beginning. I have this chute filled with liquid. The liquid comes from left and particles from top. I have used the same collision object for liquid and particles. It seems to be watertight with liquid, but leaking some particles. The leak occurs on the region where the fluid hits the wall on the right side. There are other particle leaks elsewhere. Is there anything, I should try to stop the leaking?

[JuhaHo]

I also ran into interesting issue. Max crashes during exporting particles into tyCache. When saving the scene on crash window, the new scene has changed collision geometry mode from mesh to sphere. Any ideas?

[tyFlow]

If it’s crashing, please submit the minidump.

[JuhaHo]

Please find attached the Minidump file.

[tyFlow]

Hmm, looks like a memory issue but you're also running a fairly old build. Could you post the file (or send to support@tyflow.com) so I can take a look directly? How much RAM does your system have?

[JuhaHo]

It would not be easy to send the scene due to NDA issues and also it's linked to 150 GB PhoenixFD simulation on another scene.

I'm doing this with laptop that has 32 GB RAM. I will install the tyFlow Pro license to my main workstation with 96 GB RAM. Anyway it's occupied by running another Phoenix FD simulation, that will take two more days.

[tyFlow]

Ah, with other heavy sims could be purely a RAM limitation then. Try exporting on your laptop with flow caching disabled.

[JuhaHo]

I managed to adjust the simulation in way, that it doesn't crash anymore with laptop. Anyway my point in my previous posting was, that for some reason the Collision objects had changed from mesh mode to sphere mode in crash back up. I didn't know if it was changed during simulation or during crash.

Anyway here's another. The simulation seems to be throwing particles up from liquid. I would expect them to slow down, when hitting liquid and still continue moving downwards. Is it in my PhysX liquid settings or PhysX shape settings.

[JuhaHo]

I'm getting some progress, but I'm still struggling with particles flying through the collision objects. I guess, they get extreme speeds driven by the Phoenix liquid simulation. What would be the tyFlow operator to look at?

[d4rk3lf]

Decrease the Timestep value, to 1/4 or less in Tyflow icon.

[JuhaHo]

Decrease the Timestep value, to 1/4 or less in Tyflow icon.

Thanks,

In the meanwhile I ran a simulation with modified PhysX values. I doubled both substeps and Pos Iteration values. It was much better. Next I will test Your suggestion.

When using PFlow with Phys X, the ideal substep value was 3. The bigger the value, more unexpected results I got. In tyFlow it seems to be different.

[JuhaHo]

[attachment=2200]I wonder what is the main difference between PhysX and non PhysX operators when simulating particles in fluid? PhysX setup is working fine when particles come from separate source, but do not work at all when the system is initially filled. On the latter case, they don't stay inside the liquid. So, I wonder if I should have additional operator to define the buoyancy. On ideal case particles should be floating for a while before getting wet and then they start to travel towards the bottom outlet of the system.

My question is, what non PhysX operator would be suitable for buoyancy in such scenario?

[JuhaHo]

Speaking of cache,

I have this scene of 2 000 frames. When creating Phoenix simulation, it crashed on frame 1 922 after simulating a week or so. I restarted the scene and moved to frame 1 922 where I should be able to start restoring the simulation. It started creating tyFlow cache and crashed again after two days when reaching the frame 1 922. So I disabled the cache option and started the scene again. Now it continued to frame 1 922 in just a few days without caching. Then I was able to start restoring the Phoenix simulation. It started with going to frame 0 again to update the tyFlow simulation. I think, after two days Phoenix is able to start restoring the simulation. However the most likely outcome is, that my HP workstation does some kind of service boot, before the frame 1 922 is reached.

[JuhaHo]

Am I correct? 

Without caching possibility, it's quite a challenge to create simulation together with Phoenix FD. It seems for every substep, tyFlow generates new simulation which means simulation times are extended to weeks per frame. Is there anything I can do about it?

[tyFlow]

tyFlow simulations cannot be 'resumed' the same way a PhoenixFD simulation can. If the simulation is consistently crashing on a particular frame, almost 2000 frames into your scene, you're probably just running out of RAM. Have you monitored the machine to make sure RAM usage is not being depleted as the simulation progresses?

You could also send me the minidump to look at which would show where the crash is happening. Instructions are in the sticky post.

[JuhaHo]

Thanks,

I disabled the caching due to crashes, because I thought it's a RAM issue. I have 96 GB, but it seems to be too low. It's not crashing anymore. However, I didn't realize, it seems to be starting new simulation round for every substep each round taking days. Maybe I should reduce the particle amount for initial simulation to be able to use caching again. Then I could do some additional simulations with only one way connection to Phoenix FD.

Here's by the way my test scene. I check the settings here and copy them to my main scene.
https://vimeo.com/683703290

[JuhaHo]

After weeks of processing Phoenix FD simulation Max crashed before the scene was even fully loaded so that Phoenix FD could start simulating. I'm still stuck at frame 1922 of 2000.

[tyFlow]

Can you post the minidump?

[JuhaHo]

Here,

I had a least eight crashes today, so I'm not sure if these are related.

[JuhaHo]

After few days of simulating, I just got a bluescreen.

[tyFlow]

Thanks for the minidumps.

3dsmax_minidump.dmp is showing a crash happening in the Edit Path modifier, during a 'poly detach' operation (so, not related to tyFlow).

3dsmax_minidump00.dmp is showing a crash happening while tyFlow is loading your Phoenix container's particle data. The crash is caused by an inability to allocate enough memory to store the data, so you're just running out of RAM. Typically that's what a bluescreen will entail as well. I can see the allocation is for 12 million particles...which, isn't that many but depending on the scene and other calculations/caches involved, would not be a surprising amount to get an allocation failure for. Have you monitored your task manager around the time the crash occurs? How much free RAM does your system have before crashing?

[JuhaHo]

Thanks,

So I might want to reduce the particle amount when creating Phoenix FD bidirectional linked simulation. I think the link from tyFlow to Phoenix is needed only when hitting the liquid surface. I could then create another tyFlow cache for those particles filling the liquid. There a one way connection from Phoenix to tyFlow is required, because it's the liquid that moves the particles. I'm building more than 50 meter high container filled with liquid and particles.

There's also a need for changing the particle weight based on particle age. They are first light, but when getting wet, they'll become heavier and start traveling downwards. I'm sure there's an operator for that, but which one.