I’m getting some errors with this setup. Stoke creates particles. Use the plus to convert it to a prt loader. Prt loader has a specific range checked 210-368.
Now I’m using a emptyflow, prt birth and prt update to read that loader. I get the following error on scene file open. I’m trying to render this through vray instancer using shapes but I can’t get it to click through all the errors on deadline. Any tips?
KrakatoaPFGeometryLookup::Proceed() Error
scripted_object_ref::get_param_info() - could not find parameter: “fileList”. Check that all the correct events (on create/load/clone) are implemented in the scripted plugin.
It sounds like the PFlow is trying to update its particles before the PRT Loader’s Scripted UI has been fully initialized.
The fileList property is where the file sequences are stored, and the base plugin (the real C++ PRT Loader) has to connect to the scripted UI.
For some reason, the order of loading and evaluation of the objects causes an update of PFlow before the rest of the system is ready, it seems. But I could be wrong.
I will try to reproduce this here with a similar setup, but if you have a very basic scene that demonstrates the issue, it would be even more helpful.
Also you forgot to mention the versions of Krakatoa, Stoke and 3ds Max you are running…
Thanks for explaining that. We are running mango (carlos’ pipeline tool) here at encore so i wonder if that has anything to do with it. I’ve never had this problem before.
I can’t get any files out of the work environment, its all locked up so unfortunately I can’t provide a scene atm.
max 2014 sp5
Krakatoa version : 2.4.3.59385
stoke version: 2.1.1.59446
I started by checking the scripted plugin’s definition, as the error seems to be coming from the scripted plugin itself.All three events (create, load and clone) are defined in the PRT Loader’s scripted plugin. So that’s as it should be.
However, the way our scripted plugins are used is a bit … unorthodox. In regular scripted plugins, a paramblock can be created to store parameters, and it calls on the delegate to set its properties as needed. In the Krakatoa PRT Loader though, the PRT Loader’s C++ plugin is looking “up” at the paramblocks of the scripted plugin and getting whatever it needs from them. It makes the scripted plugin much more streamlined, but it is possible that somehow within your pipeline this system might be going out of sync.
At this point I am going to assume that the problem is actually somewhere in the Particle Flow trying to evaluate the Proceed() function of the KrakatoaPFGeometryLookup operator too early in the loading process. I will have to pass this on to the current developers of Krakatoa to look at the code and think of why this might be happening, and a possible way to prevent it…