As the title states I tried to do a quick sequence and it seems that only the first frame would render. After a little examination it appears that there is still some caching going on via the exporter, yet the renderer seems to have started prematurely, it began rendering frames, apparently with incomplete data, before it had been written.
You guys would know best but it seems there need to be a flag at PRT frame complete to tell the renderer hey I am okay and have legit data.
Using single machine - max2017 + latest kvry feb.24
So frames have finished caching and upon Exporting again, with Overwrite Existing Off, everything seem to be working as expected, the sequence is now rendering properly.
In the current proof of concept, we export the complete vrscene (all frames of the animation), the Krakatoa settings, and the PRTs needed for the first frame. Then the external renderer is launched, and then the rest of the PRTs are exported. So if the first frame finishes rendering faster than the second frame can cache its PRTs, it would fail (this could happen on any frame).
I guess the Krakatoa plugin in the VRay.exe could just have an option to wait for missing PRTs. I will log it as a an issue.
It is! And it does look pretty incredible too, ease of use is quite good too.
totally makes sense and that is exactly what I ran into.
Obviously when using a loader your particles already exist, totally non-issue, I could see this as being a solid solution to any Krakatoa object that generates its own particles. Thanks.
Here is a fix for both the missing PRT files (it will now wait and potentially fail after a minute if the export was canceled), and the Viewport being exported (the export will not even start if the view is not a valid perspective, camera or light, since Ortho views generally do not work well in Krakatoa):
I also fixed a bug with animated meshes turned to particles, sped up the saving of unchanging particle objects (e.g. a static PRT Volume), and added code to delete PRT files whose hash does not match the current objects before the saving pass to avoid rendering a previously existing PRT which happens to be on disk with the same name, but with the wrong content.
