Hello,
Seems like frost is still trying to build mesh on frames that are not rendered nor simulated.
Trying to render seq from 1001 sends error:
BuildMesh (Frost LongArm): particle_file_istream_factory: The input file “x:\i2\e090\030\i2_e090_030_fx_slices_mn_v034\Stoke-LongArm_prt\Stoke_943189_449609\Stoke-LongArm_0000.prt” does not exist.
Is it possible to fix it in the next version or maybe the Limit to Custom Range checked by default?
Cheers,
Martin
Hi guys,
Writing again on this very annoying to us bug! It is very frustrating when you have set a scene with many prt loaders, PRT FFX and Frosts to get errors on the last minute from the farm when you have to render something important!
Frost is trying to build a mesh at frame 0000 and asking the PRT loaders to have set range or Prt FFX to have cache at frame 0000??!??! All our scenes start from frame 1001 and on every scene this is set by script.
So I don’t understand the reason why frost has to build meshes 1000 frames before the active timeline and why it stops all the renders throwing errors because of that?
Can you fix this, please?
Cheers,
Martin
Hi Martin,
3ds Max evaluates the scene on frame 0 when loading a MAX file before the actual scene time is changed to the actual range.
Frost cannot know that the requested frame is not one you don’t want to use, it just follows the 3ds Max notifications.
This is why both Frost, the PRT Loader, and the XMesh Loader feature a “Limit to Custom Range” checkbox with a “Blank” before range behavior option - if your scenes start at frame 1001, checking the checkbox and pressing the “Range” button to set the range to only the available frame range, then specifying “Blank” as the behavior will produce an empty stream and Frost won’t mesh anything on 0000, but won’t complain either. If set to “Hold”, the first valid frame of the range will be found on frame 0000 and the error will be avoided.
We have no good ideas about how to otherwise prevent the unwanted refresh on frame 0, and you can bet Autodesk is not gonna change it (plus I suspect there is some technical reason why the scene evaluates frame 0 under the hood). So we can only suggest you start setting your custom ranges - you can even write a MAXScript or a Deadline Sanity Check that looks at the scene before submission and sets the Ranges of all loaders if necessary.
Hi Bobo,
I understand that 3ds max has to evaluate frame 0000 before loading the frame, but I thought maybe you guys could have set a way to ignore that frame if it is not in the render range? If max hasn’t loaded yet to the point to check what is the time-range I have written down a suggestion way to go around.
Maybe there should be a way to just skip Frost if the missing frame is 0000, since all the problems are coming from frame 0000 and throwing warning instead of ERROR therefore not stooping the rendering on the farm. That way if you are working on range 0-100 then you will get warning saying you don’t have cache on that frame but will still render it (obviously with no meshing as there wont be particle cache for this frame) but for all other cases it will work and just throw warning! Why force the render-er to stop? Or at the very least, that could be made as checkbox so users can decide whether they want it or not.
Also I am setting the Limit to Custom Range properly to all the prt loaders, but this time it actually was looking for fumeFX .fxd cache on frame 0000 as I was Frosting a PRT FFX! So I had to copy a random fume cache frame, and rename it to name.0000 in order to send the scene to render. And sometimes that could be tedious especially when you have to figure out these issues in the late hours, hoping that the next morning you will be able to see you renders 
Cheers,
Martin
We are having a discussion about this once again.
When Max loads on frame 0, it evaluates the scene objects in viewport mode, even if running in Network Render mode that has no viewports!
So for XMesh Loader, we added an option to ignore viewport mesh requests when Max is not in workstation mode with actual viewports. However, some plugins like the XMesh Saver could legitimately request a viewport mode mesh while in Network mode (when saving a Proxy mesh for example), so it had to be an option and not a built-in logic.
We could probably do the same for Frost - add a checkbox that says “No Viewport Mesh In Network Mode”, but the same rule would apply - if you need to cache Frost to XMesh on Deadline with viewport proxies, the option would need to be turned off manually to allow that.
For PRT FFX, according to our logs, a fix was added to Krakatoa MX 2.3.1 and higher to return an empty stream with the correct channels list on any frames outside of the valid FFX sequence range. In the past, Magma or Frost connected to a PRT FFX would throw an error because the channel list would be incorrect. However, it is possible that the fix did not solve your specific case. Can you confirm the version of Krakatoa you are using, and tell us more about the structure of the scene and how the PRT FFX is used by other scene objects?
Hi Bobo,
Krakaota MX version is 2.4.0.58782
Stoke is 2.0.17.57846
Frost is 1.4.2.57152
It is a scene where Fumefx sim is used to drive stoke and PRT FFXs and then loaded (the stoke caches are loaded on PRT loaders) to frost for meshing.
So we will go ahead and add a sanity check for all frost objects in the scene to set the range. I guess that would be the easiest way…
One question on that side. We can do a sanity check only for Frost objects in the scene, right? PRT loaders doesn’t stop renders anyway so only frost objects should work?
Cheers,
Maritn
If you are meshing PRT Loaders using Frost (as opposed to loading the PRTs in the Frost directly), it is the PRT Loaders that need to be set to Custom Range. The error would come because the PRT Loader cannot load anything on frame 0.
In Krakatoa itself, when rendering particles, there is a special switch to suppress PRT Loaders complaining about missing files.
It used to be our company’s policy (at Frantic Films VFX) that a missing files should fail renders instead of silently producing bad frames, but in some cases the LnR department wanted to test with incomplete PRT sequences, so they begged for a switch to make partially generated PRT sequences render.
However, that switch is only in the Krakatoa renderer itself, not in the PRT Loaders.
So if rendering Frost from PRTs in another renderer, the PRT Loaders need to be set to load the valid range, and either load nothing or keep the first/last frame outside of the range.
Thanks