I have a number of objects that are completely static. Most of them were originally PRTVolumes. I have found that saving out the particles (partitioning when required, though not required much here, as the lcient LIKES the grainy look!) generally makes things faster, especially if you can bake the materials applied to the particles, and if you can use a frustrum object to do frustrum culling (scene has no lights, additive only).
But what else can be done to optimize clouds that do not change? I have the PRTLoader set to load a single frame. However, It looks like it is still reading the particles off the disk each frame?
Is there some way to RAM cache certain objects so they only have to be loaded at the first frame? I realize the render nodes will still have to load them at the first frame of each job (our net renderer uses 3dsmaxcmd.exe to hand out a few frames at a time).
For memory conservation reasons, this is currently not possible.
We could do several things, and these have been discussed over the years many times, but so far we felt that keeping the memory usage as low as possible is more important than loading performance.
The one option would be to give PRT Loaders their own render-time cache. They already have a viewport cache, so if you check Single Frame Only, the particles would not be reloaded unless it is needed when moving the time slider. But for rendering all particles are always reloaded. Having this case would mean the particle data would be loaded in memory twice - once in the PRT Loader, and once in the render stream.
The second option would be to tag particles somehow with a source ID. This means that the particle stream could be reordered by object in the beginning of the next frame and trimmed to remove and reload the particles that are dynamic while leaving the ones that are unchanged. Potentially, we could even update specific values in existing particles, so modifying the material color could update the particles without reloading all other channels. This idea has been around for a long time, but there are serious technical problems with it, so it might never happen.
We already have an option to lock ALL particles between frames. So if the camera or lights are moving but the particles are completely static, it does not require any reloading, even in network rendering mode. I wonder if we could make this a limited feature where we split the internal stream to a static cache and a dynamic part and allow the locking of only the static particles while updating the rest. Not sure how the concatenating of the two streams would work at render time since they should be in a single stream during sorting. Might cause a similar issue with duplicated memory…
Ah! The pCache should work nicely. Since I am additive I can easily split the static particle data out into a separate render and use the pCache on that.
But, yes, I was hoping for something like a per loader cache. It just seems very useful, especially when the user can set it manually.
The second option sounds really cool. Hopefully you guys can figure some cool cache technology out.
Regarding the PCache. If you are rendering on a network, there is a special switch that allows the PCache to be locked during network rendering. To prevent accidents, we disable the PCache in network mode, but there is a “Use Cache In Slave Mode” checkbox in the right-click context menu of the PCache button that allows it to stay on in that case. For local rendering, you just have to engage the cache and render a multi-frame animation and it should load just once, while updating the camera correctly.
This has an old production history. It is GREAT for certain things, and some of our inhouse artists at Frantic Films (in particular Chris Pember) insisted, and begged, and the core developers of the day said “No, this is going to screw customers outside of Frantic who don’t know what they are doing”.
The current behavior and the corresponding warning were the compromise we came up with to make everyone happy
The “>Ignore Missing PRTs” checkbutton had a similar history. But it was slightly less dangerous so we simply painted it red…
In the end it is really just like any of the other 1000 settings in any 3d app that, if wrong, will mess up your render.
Does that Use Cache In Slave Mode work if the pCache button itself is turned off? (Checkbox ON, button OFF)?? That would be dangerous in that a user could not see that it was on.
No, you have to check the PCache button AND have the checkbox on. If the checkbox is off and PCache button is on, when you submit the job to the network, the PCache option state will be ignored if Max is running in network (slave) mode without UI.
Normally, if you load a scene that was saved with PCache on on your workstation, it will keep the state, and the cache will be populated the first time you render, then you can rerender from memory. We were afraid that people could hit the SUBMIT button in Submit Max To Deadline and forget the PCache checked, then come asking on the forums why the particles are not moving. So we decided that network mode should ignore the cache by default, but allow power users to override that behavior at their own risk.
