When saving the “Current Frame” from the PRT Saver, it saves ONLY the particles that are currently on screen, not the particles that should be generated if the animation plays from the start.
For example:
Open the attached scene (XParticles)
Don’t Press PLAY
Just go to frame 90 (No particles should be visible)
Select PRT Saver and press “Save”
The PRT Saver will save no particles.
There should be a way to tell the Saver to calculate all the particles up to that frame, otherwise we have to manually play, and it’s very slow. PRT saver test 01a.c4d.zip (66.8 KB)
Well I guess this the correct way for the Saver to work. Current frame cannot possibly now what happened before, as that would involve any (heavy) precalculation.
So it would take the exact same amount of time to save the current frame or the animation from frame 0 up to that desired frame, which makes no sense/difference, right?
The PRT Saving implementation is about to change drastically in the coming builds.
We are moving away from the PRT Saver object and integrating the saving into the Render Settings UI just like in KMX.
The reason for this decision was that apparently there is no SDK call to switch C4D to “render mode” from a scene object without actially triggering a rendering. So the only way to produce the render-time particles and save to PRT would be to actually call the renderer.
In other words, PRT saving will be a form of “Render To Disk” just like it is in 3ds Max.
You will have to hit the “Render” icon in C4D to perform the saving in order to trigger the internal changes needed for some systems to “know” they are about to render. Thus, systems like the old Emitter that have separate “Viewport” and “Render” counts will actually generate and save to PRT the render-time particles and not what is in the viewport.
We will have to see how this affects all the other particle sources and possible pre-rolls. 3ds Max always forces a pre-roll if Krakatoa requests frame 100 and no particle data exists for that frame. It is quite annoying, but useful. C4D might just work differently though…
Technically it’s the same, but practically it’s not.
Rather than pressing Play, waiting for the PreCalc to finish and then Saving the frame, I’d rather press save and go make a coffee. Huge difference. Also, what if I have my quality settings in the display to show only a fraction of my particles?
There are so many things to consider and I think the new approach (via render) will solve most, if not all.
Just as a request, can the “Render to file” (Or shall I say Save to file) respect the frame range? For example “Current Frame”.
I would make it work exactly like Vray “Don’t render final image” method for saving the GI only.
Also, don’t forget the “Frame Step” in the “Frame Range” settings.
I suspect it will respect the frame range. PRT Saving even in Beta 3 is implemented by Krakatoa SR itself. We call the renderer and tell it to save instead of making an image. And if the “Compute Lighting Channel” is checked, it will even perform the Lighting Pass and store the resulting illumination/shadows in the Emission channel, allowing you to load and render pre-lit particles by just checking Use Emission and Ignore Lights. Even the PRT Saver object called the renderer, but C4D did not know that and did not switch to render mode internally… That’s what we are after now.
Frame Step was specifically removed from the PRT Saver in Beta 3 because it makes no sense in Krakatoa. The PRT Loader cannot interpolate missing frames (yet), and when we add all the retiming and cubic interpolations, finding the closest frame to the current time becomes an issue if the frame is missing. We have solved this in Stoke and might port that to Krakatoa in the future, but until then, saving every frame is quite important.
Of course, once we switch PRT Saving to the Renderer, anything the renderer does will go to PRTs, so if you set a Step, it will probably be respected…
Still would take the same amount of time, so no difference actually…
Display a fraction of particles doesn’t affect the state of saved particles, as they are still computed internally. You would rather need to reduce the particles to a fraction in the Source tab, but that would still require the precalculation, as this reduction happens afterwards…
In the general output settings, the selected frame range for rendering is respected, but obviously for X-Particles, you would still need to calculate any preframes to get correct results… so all working as it should I assume.