When loading multiple PRT files into a loader, do all the partitions have to be loaded for the percent calculation?
Meaning…
If I have 10 partitions, all 1 million particles +/- 50,000, and I set the PRT loader to load in First N particles, 20%, does the PRT loader:
Pull in the first 2 partitions
Pull in all 10, total up the particle counts, then determine the 20%
Read some header in the files without loading the data, determine the number to load, and only then actually load the particles?
Or something behind door #4?
Also, how are missing partitions counted? If I have 300 frames of animation, and for whatever reason by frame 300, only 6 of the 10 partitions have saved out on this frame, does it load 20%*10/6 or just 20% of whatever method listed above is used?
The current implementation will first total the number of particles in all the designated partitions by inspecting their headers. Then, it will load the desired percentage of particles starting at the first partition in the list until the correct percentage has loaded.
Would it be more useful to have the N% evenly distributed over all the partitions?
No, what I’m running into is that I want to load 50% of the particles for render, but on frame 180, one of the farm machines got stuck, and we only have 9/10 of the partitions.
If the # of particles loaded is calculated from the 9/10 partitions, as opposed to 10/10 partitions, I’ll end up with a 10% fewer particles on frame 180. If the PRT loader said “Hmmm, one of the partitions is missing, how about I just assume it’s the size of the average of the found partitions, and we use that in the total?” that would be best for me. Throw a warning dialog up that gets logged in deadline, of course.
Since the partitions are made from position seed offsets, I don’t care which particles are loaded, and from what partition, I just need there to be the same density of particles frame to frame so I don’t get flickering.
So far (and this may be different for other people) none of my scenes care one bit about the particle index, so Nth particle doesn’t matter for me. I birth my particles on frame 0 and spawn or delete from there, yeilding completely random distribution.
At this point, our internal discussions led to the conclusion that a strict check for file validity is a must in a professional renderer, so Krakatoa will not render a frame if any part of the requested particles is missing. It will be up to you to resolve the problem by producing the missing data or removing from the PRT Loader the sequence that has dropped frames.
We plan to add some tools to either the PRT Loader itself or to the Particle Loaders rollout to inspect the files in all sequences and report any issues before rendering.
That sounds good. If Deadline throws up an error about a missing partition, we’ll at least know what happened, as opposed to wondering why it flickers.
Check out the 0.9.12 SP1 “Missing Frames In Scene” and “Missing Frames In Render” display options in the Particle Loaders Rollout. These are supposed to show any missing frames in PRT Loaders - the one relatively to the current scene segment, the other vs. the frames to be rendered.
This is intended to help debug missing frames before sending to render.
Ack. This is actually proving annoying as well. No chance of flickers, but I can’t do test renders while my partitions are still in the queue. Maybe the PRT loaders could have a “danger mode” checkbox or something?
I guess we could allow this in Workstation mode so when you are test-rendering interactively, you would only get a warning and it would render anyway, but would fail on deadline.
The other way would be to implement the warning as Yes/No where you have to answer several prompts “PRT Files Missing - Continue or Abort?” where if you press Yes it still renders, if you press NO it bails out…
You could have Deadline handle those popups and implement your own policy whether to continue or not.
