Is anyone experienced slowdown with rendering particleflow particles in RC3? It renders first frame fine, and then when it goes to second frame, pflow calculation is done but krakatoa is stuck to “Retreiving particles” status. It loads 1 or 3 green squares (loading squares) and stuck and after few mins loading goes few squares more and stuck. and it renders next frame after 5 to 6 mins.
Problem I was having with the file is working absolutely fine with Version Krakatoa 1.4.9.36823 . After I downgrade to that version. It’s rendering whole sequence fine.
If this is the case with particular file I have, I will email this file to Bobo. Very strange in RC3 it stuck to very next frame whereas in 1.4.9, rendering is going very fast and without problems.
It would be good to know what is in the PFlow - are you using any Krakatoa operators, or just pure PFlow? Any Box #2 or #3 operators?
Simple test:
Created a Standard Flow in Max 2010 64 bit.
Increased particle count to 2M
Added Omni Light
Opened Krakatoa 37179
Rendered a sequence of 100 frames
RESULT: No problems.
This is the simplest test with PFlow, but I am sure your setup is a lot more complex. I have seen PFlow going into cyclic updates when two systems depend on each other via Box #3 Proxy operators, and this is the way TP does updates when partitioning, but rendering a sequence should normally go smooth. Krakatoa just tells the PFlow to update and whatever it does should be PFlow’s responsibility, unless you are using Krakatoa operators in which case there could be something we are introducing into the mix that goes wrong…
To test this, I replaced the Birth and Position operators with PRT Birth and PRT Update and loaded a sequence from a PRT Loader. It still rendered ok without any slow downs.
Well it’s animation of bus emitting sands. So I am not using any box tools.
but I have set birth amount at birth rate and it seems if I use more than 5million of particles as birth rate. It seems to create problem on very second frame if I Set it to 100000, it creates after 2 or 3 frames.
I will send you file tomorrow. As one rendering is already going on with 1.4.9 beta version.
Thanks!
Got it and could repro in Max 2010.
So far it looks like the problem is in the Material Evaluation (which has indeed been updated between Beta 9 and the final).
If you disable temporarily the Material Dynamic operator, the problem disappears.
I can see two of my eight CPUs fully loaded when it happens, will pass it to Darcy to find out what is going on.
After looking closer, it appears that the cause for the problem is the animated Noise map.
The fun part is that no other procedural map in Max (not even BlurNoise or even the Noise option in the Checker map) causes this problem, only the Noise map does. If ANY parameter of the Noise is animated, it somehow causes multi-threaded evaluation to slow down significantly (with two CPUs loaded at 100%). We could repro this with a simple teapot and PRT Volume made of it, using a Standard material with an animated Noise map in Diffuse or Opacity.
While we are trying to figure it out, try to work around this by not using an animated Noise map on your particles (see if any of the free extended Noise plugins from Blur, MorphoGraphic etc. out there can do the job).