Hello,
we are currently evaluating Krakatoa for usage in high-res print-jobs. For this, I requested an evalution license, which works beautifully. The test job are the splashes and foam created by the motion of a container vessel on an ocean. The simulation for this is coming from realflow, exported as prt-sequence with around 300k particles. Using the workflow described here thinkboxsoftware.com/krakato … and-frost/ I was able to increase the particle amount to lets say 10 million. That seems to be a critical number on my workstation here: If I increase the amount to more than that using the settings in the prt volume, all my 64gb of ram are full and the rendering is coming to a halt. In one of the help files I found this statement here: “Remember, ten million particles might sounds like a lot, but in the world of Krakatoa, that is typically a preview setup!”. To be honest, it looks a lot like preview in 8k resolution, so I feel I would have to raise the settings a lot. But I can’t, because even at 10mio particles the ram is full. I feel like I am doing something wrong. Are the any tips I could try? There is nothing heavy in the scene, except for the prt loader, the frost mesh and the prt volume used to fill up the frost mesh. Three spotlights, nothing too fancy. Something that also worries me is the time Krakatoa need to draw a single frame. For 8mio particles it need 1:25mins, without motion blur. Is that good or bad?
What you are seeing is probably unrelated to the particle count.
Krakatoa allocates internally one frame buffer for every CPU used to render.
Thus, rendering on 8, 16, 24 or 32 threads at 8K resolution can eat up all the memory easily - how many cores do you have?
Open the Krakatoa GUI, click on the Preferences button at the bottom of the Main Controls rollout, go to the System Preferences rollout and uncheck the option for Mutli-Thread Particle Drawing. Then try to render again. 10 million particles should use only around 300MB for the particle data…
We have it on our ToDo list to add an option to specify the number of threads you want to use. We already have that in Krakatoa MY and C4D. It should be added to KMX soon. But right now you can either use 1 thread or all threads, so if you have a new system with lots of cores, it can get problematic really fast. But even on one thread it should be quite fast to render. Please give it a try and let me know how it behaves…
Of course, for 8K resolution you will probably need hundreds of millions of particles.
Note that in Krakatoa v2.3, you do not need to go through Frost to increase the number of particles - the Krakatoa Particle Cloner modifier now features Particle Repopulation that produces similar results in a fraction of the time by putting the source particles on a voxel grid and adding the new particles around without the need to generate a mesh from the data first!
Bobo,
thanks for the quick and detailed answer.
The machine I am working on has 32 cores. Maybe that is the culprit. I’ll give a shot at the tips you described tomorrow.
It is new to me that I do not need to have frost for using the reaflow data. Thanks for that hint. Is that workflow described a little more in depth somewhere? This whole thing here is pretty new to me, but I am impressed with the results so far.
And one little question: The atmospheric effect doesn’t like Vray lights, right? Tried a domelight this morning, but I could only render with spotlights.
Boris, thanks again for your help. I am currently rendering several hundred million particles without filling up the ram It takes some time I admit, but it works.
Also, the prt cloner has made that job much easier. Great support!
I come across this one in our last project. I know rendering 4k by 4k resolution is not the normal usecase
But I think this option should be off on default at the moment. And for it to be usable there should be a way to limit the number of threads.
I agree. In fact, the exact number of threads can already be specified in Krakatoa SR, Krakatoa MY and Krakatoa C4D.
We still need to get this working in Krakatoa MX. It is on the ToDo list, but has not made it to a public build yet.
It takes some time I admit, but it works.