I have submitted a job to deadline, but it couldnt start rendering because of a missing particle, there is no setting in deadline to @ignore missing particles@ like in krakatoa,
maybe frost (or deadline) should include this option
i autokeyframed a graph and then it worked
Where was that missing particle?
The loading options of Frost provide the same controls as in PRT Loader to hold first/last frame or output empty.
But if there is a frame missing in the middle of a sequence, you are out of luck.
The “Ignore Missing Particles” option is a flag in Krakatoa itself. We cannot put something like that into Deadline, but I guess we could have it in Frost to just output an empty mesh of it fails to load a PRT file…
The general consensus back in the day was that if a file is missing, that is an error and no serious production should be allowed to output imagery out of invalid data (imagine noticing a day before delivery that you have flickering meshes because Frost never told you there were errors int he input)… That’s why the checkbutton is red in Krakatoa - it is quite dangerous. An option that makes it your responsibility to turn on would be ok I guess.
jea i was getting lots of erros and it couldnt render on farm,
the particles werent even missing, buti saved out a particle sequence frame 460 to 570, the praticles only start appearing at frame 491, but i saved out the complete sequence so when another company deals with it the particlesequence is it for the complete shot and they dont have to realign to a certain frame number,
anyways, the particles only emit at frame 491 so frame 460 to 490 are @empty@, which shouldnt be a problem for frost, (its not in the viewport) but for the farm it is a problem so jea, i think the ignore missing paticles, or ignore frost error is definatly the way to go
I’d like to make sure I understand correctly:
You saved particle files for frames 460…570. Particle files exist for all frames in the range 460…570. However there are zero particles in the files 460…490. Then Frost works fine in the viewport, but fails on render nodes?
I will look in to this.
Yes I had similar issues when I tested Frost on a certain project. Lets say a realflow scene of 100 frames with two emitters. One emitter starts from 0 to 100 but the other one is activated only from frame 50.
So circle01 is 0-100, circle02 is 50-100. Both bin seq files are loaded into a single Frost but since circle02 is missing 50 frames at the beginning it refuses to mesh anything between 0 to 50 and outputs an error. Would be better if it could just ignore the missing frames and create a mesh of all circle01 0 to 100 and continue to add circle02’s particles once they’re available.
Tried it with a prt loader and it behaves just the same. 0 to 50 is ignored.
Easiest workaround I found was to make sure realflow still output bin files at the whole range, even if the particles are still not created. (using animated speed instead of animated activation). Another solution but a less ideal one is to Frost each bin files separately and then make a new frost object that uses both frost meshes as a source. 
I think you could handle that using two Krakatoa PRT Loaders, one for each source. Enable “Limit to Custom Range” on both, set the Range appropriately, and maybe change Hold First and Hold Last to Blank. Then add both PRT Loaders to a single Frost object.
But yes, I agree this should be improved.
Each one of these cases starts to make the idea of a “Frost Preprocessor” object sound more and more appealing.
This type of behaviour plagues the Krakatoa PRT FumeFX as well, for instance you want to export smoke but you haven’t created any until a later frame, Krakatoa and Frost will both complain. Currently being totally committed to working with ranges is a bummer.
Empty channels are, what I would say in lesser words, a pain in the ass. I have suggested this before ages ago with Krakatoa and still have seen nothing about it, sticking a nul value in the channel until it is populated with a valid value (unless I missed something and this is possible already, which is entirely possible). This will at least keep a prt save or render from breaking. Hell even if it is zeros would work for most cases. As it is The plugins tell you instead of you telling them what to do.
The FumeFX thing happened to somebody in the Prime Focus office two days ago - I remembered Darcy’s advice to set the Playback range of the FumeFX object to the valid range and then it saved correctly all frames even outside the valid range. So there is a way, it is just not in the PRT FumeFX but in the FumeFX itself.
I believe the reason we get these errors is something the Frantic Films RnD dept. used as a guideline: If you don’t have the right data, don’t assume stuff but throw an error to avoid surprises down the production pipeline. For example, if Krakatoa would not complain about a missing channel and the channel is REALLY missing, you wouldn’t know it until it might be too late (e.g. a flickering frame in the middle of a sim due to a corrupted Fume file or something). So we prefer to throw an error instead of silently going on with potentially wrong data. With the PRT Loader, you are allowed to specify validity ranges and even enable >Ignore Missing Particles and render bad frames at your own risk, but these are options you have to enable.
Frost shares a lot of particle loading code with Krakatoa and some of these error handling policies have affected it. I think if we expose clear rules about when to fail and when to assume empty data, thus passing the responsibility to the user, it would make life much easier for everybody…
I completely understand the logic behind the way it is, it is genuinely the smart thing to do, especially dealing with the large scale production shots you guys have been doing.
You guys have done your jobs too well 
we just need a couple of hacks to bypass some the protections, sometimes you just need a real quick and dirty.
I am good with that, for sure