Recently, I created a relatively simple scene with Phoenix and Corona.
In this scene, I only created a fluid simulation with multiple sources that interact with each other, mixing the RGB channel.
Regardless of the output image resolution and even in IPR, after a certain number of frames, my PC runs out of RAM.
For rendering a single frame, the scene does not require much RAM, and even a PC with 32 GB can render it in 4K without any issues.
However, after each frame, the RAM usage gradually increases until I encounter a Phoenix error: “Out of memory during volumetric rendering initialization.”
If I play the simulation without rendering, the RAM usage remains under control.
I’ve tested this on five different PCs, ranging from 32 to 128 GB of RAM, and encountered the same problem. Has anyone else had a similar experience?
I hope you can help me because it’s really painful to debug and render the animation when I have to restart 3ds Max after every 15-30 frames.
Please take a look at my attachments:
ram_statistic -4xspeed.mp4 - I’ve recorded a video showing how the RAM usage increases.
ram_statistic-error when out of ram.jpg - A screenshot of the Phoenix error message that appears when the system runs out of RAM.
My Software versions are:
3ds max 2022.3.8 (24.8 - 24.3.8.3531)
Phoenix 5.20.00 Build 20230706
Corona 10 HF2
Investigating this issue could take some time, it would be helpful if you could submit a support ticket. Please use the following link to do so: https://support.chaos.com/hc/en-us/requests/new
Additionally, please also attach your scene file and provide step-by-step instructions to reproduce the issue.
We were able to reproduce it. It seems like a bug, caused by the PhoenixFDGridTex map which is connected to the diffuse slot of Corona physical material. We have logged this in our system to be further reviewed by our devs. We will let you know as soon as we have any update on this.
Just tested Corona 11 RC3 because I saw this under bug fixes: Fixed rare issue where the rendering could get stuck and consume large amounts of RAM.
Sadly, my case with Phoenix and Corona is not resolved.
I must admit, the engine behaves a bit differently:
Initially, the RAM consumption increases (from 32% to 88%) from frame 0 to frame 7.
Then, a low RAM memory window pops up.
After that, the rest of the RAM gets accumulated (99%) until frame 13.
Suddenly, RAM consumption drops drastically (50%), but then the cycle repeats and ends with an unexpected error due to no available RAM.
I needed to completely restart my PC because most of the other programs also stopped working. I hope you can fix this by the v11 release.
Thanks for the information. This is interesting because Arpit Pandey, who replied to my support ticket, wrote :
"After our investigation, we have identified that the problem is caused by the PhoenixFDGridTex map which is connected to the ‘Paint mixing via Phoenix RGB channel’ material in your provided scene. If you disconnect the PhoenixFDGridTex map from the material, the RAM usage remains stable during rendering.
We have logged this issue as a bug report in our system to be further reviewed by our devs. If there will be any update on this, we will let you know.
It seems the issue is related to Corona, I also investigated it with V-Ray, and it seems to be rendering fine with V-Ray. I have already reported this to our devs. At the current time, we don’t have any specific workaround. As soon as we have any update on this we will let you know."
In any case, the most important thing is that it is in the progress. Because in Phoenix, there are enough cases where it is necessary to mix the colors of liquids and leave the corresponding color via wetting map of them.
This issue is fixed in the latest Phoenix nightly.
You can grab the latest nightly from here: https://nightlies.chaos.com/ If you have trouble accessing this page you can submit a support ticket and they’ll give you access.
I will render the scene a few times here and see if I can reproduce the NaN error, but that is definitely to dow ith Corona and not Phoenix. So I’m glad that at least one issue is solved here
I’ll let you know when I have some more info with regards to the NaN issue.
