When rendering Pflow particles, If I calculate 25 megaparticles, I can keep tweaking lighting or density multipliers quickly because the particles are already cached in RAM.
When rendering PRT Loaders, I have to keep loading those 25 megaparticles over our network every time I hit render.
Would it be possible to have an option in the PRT Loader or in the render panel to keep those in RAM? The current flushing is very memory efficient and prevents me from crashing as often, but it really slows down my test renders. I could also see this speeding up network renders if the PRT Loaders are static (yay for the single frame option!) and only the camera or lights or matte objects are changing and the slaves don’t restart the render (and thus clear the cache) each frame.
It’s just that Krakatoa is sooooo fast, and my network is sooooo slow. Though we should have the Data Direct Network system in the office in a few weeks. Too bad we don’t have infiniband on the farm machines…
Believe it or not, we have a wish logged against this. Not only for PRT loaders, but for any sources. A sort of “dummy cache” - not a smart one, but a manual mode where you tell Krakatoa “store everything in RAM until I tell you to release” and it is up to user to decide when to turn it on or off.
Unfortunately, there are other features that require more attention at this point, so we don’t know whether this will make it into 1.0 or not…
Understood. It DOES render, and more reliably than running straight out of Pflow, which has it’s own bag of bugs. So press on!
But hey, let me add another wish for a post-1.0 world…
How about if I assign a material to a PRT Loader, you use the opacity of the material to blend between the stored colors and the material diffuse channel color? So I could “tint” a PRT Loader or screen map on some extra color. I just had someone say “perfect, but make it a bit more red on the left side”. So now I’m stuck redoing 60 PRT partitions, and even then, I won’t know if it’s enough red, or if that person can tell their left from right.
You might be able to get the blending you want with a material. When PRT files are loaded and coloured using a max material, the color from the file shows up in the vertex colour channel. This means you can likely make a blend material between your colour and a vertex colour map to get what you want.
I see how the color data in the PRT gets put into the vertex color of the PRT loader, but does the opacity end up anywhere? I want to modify it with a lookup.