I’m RnDing something and have a simple Pflow that has the particle transforms modified by a script operator in a cumulative way. I was hoping to be able to Prt this out, but because krakatoa doesn’t actually move the slider as it’s saving PRTs, it’s not taking the scripted addition to the transforms into account. Is there some way that I can get krakatoa to step through the frames as it’s saving prt files? Or another way to force it to take the script operator into account when saving?
I don’t understand why the Script Operator is not affecting the saved particles. Krakatoa evaluates PFlow on each frame for rendering, and saves the particles as the renderer would see them. A Script Operator should affect the rendered particles just like the viewport particles, but I am obviously missing something. Can you explain what your script is doing and why it requires the time slider to be moved?
That being said, you could write your own script that moves the time slider, and saves a frame at a time by calling the renderer.
There is also a FranticParticles function for saving particles of a specific object, but it was broken for PFlows in 2.6.2 and earlier. I am not sure if it was fixed in 2.6.3, but I know we fixed it internally for the upcoming Beta of the next release.
Here’s the max file. As you can see it started as your chunks scripted birth. Seems that it doesn’t even render on the farm with the scripted operator xforms either so I might just be doing things very wrong. It works in the viewport and renders locally though.
My mission is to have particles ‘linked’ to a point helper and then start being affected by forces some time later.
I’m on 2.6.1 in max 2014 (no sp as I’ve found all sorts of problems with Pflow in a couple of the service packs. Although I"m tempted to put SP6 on)
You have two problems in your setup.
The first problem is that Particle Flow operators are unaware of currenttime changes unless the time slider is moving. This is why the Birth Script has the line
t = pCont.getTimeStart() as float
You must use the same approach in the Script Operator to get the correct operator time, e.g.
currTime = (pCont.getTimeStart() as float) / ticksperframe
The second problem is that your recursive transforms get confused by the way Particle Flow actually updates its operators. I tested the following:
After fixing the currTime value, I baked a PRT sequence to disk and loaded in a PRT Loader - while the particles were moving, they were completely elsewhere than the live system!
I then moved the time slider to some frame, say 50, and rendered in Krakatoa with Force Additive mode on to see both the PFlow and the PRT Loader in the same image - not only did they not agree with each-other, the rendered PFlow did not agree with the viewport PFlow particles!
The obvious way to solve this was to add a Cache operator and bake the animation using Viewport/Render mode to ensure the operators are evaluated only once using what you see in the viewport, and then rendered from the cache. Once I did that, I resaved the PRTs and rendered again. The PFlow and PRT Loader completely agreed with each-other and with the viewport particles!
Just a weirdness of PFlow that only a Cache can solve, this is not the first time, and it is rather unrelated to Krakatoa.
