[Closed] Does callbacks.addScript #preRender not work with backburner netrenders?
Does callbacks.addScript #preRender not work with backburner netrenders? I tried setting one up, and it works fine when doing a regular render, but fails when I do a netrender.
- Neil
Yeah I’ve never gotten any pre-render or post-render scripts to work through backburner.
That might be why they added the prerender/postrender fields in the render dialog.
HAve you tried to add the script to the render slave directly? Maybe saving it on max´s script folder so it´s opened when backburner starts it´s own MAX instance?
Well, the slave, manager and computer I’m submitting it from are all the same computer, so that’s a no go Sounds like it’s just a limitation of the system.
- Neil
Well that´s what I mean, when backburner starts rendering opens a new MAX instance and loads the file that was saved by the manager right? So even if you registered the callback on the computer you sent the render from it will not work on the distributed render since technically it´s a new DIFFERENT instance of 3D MAX, and therefore does not have the callback registered.
UNLESS, the callback is automatically loaded on startup…
Ah I see, but then if I placed the script in the appropriate folder to have to load on startup, wouldn’t that mean that that particular callback would be loaded for every single max I file I ever opened? That seems a little sketchy to me. Actualy, the way I figured it would work would be the callback would occur when I hit the render button, but before the render region dialog came up, so there would be no reason for the slave to need the callback, since the script would already have run, but I guess that’s not the way it works. Anyways, thanks for the idea.
- Neil
No prob, but bare in mind it´s just a theory I haven´t tested it yet.
And yes it would probably mean that it would load the file every time max starts…
If that´s a problem you could make ANOTHER script that with a #preRender event moves your script to the folder and removes it when the render ends. So this way your script will be loaded on startup ONLY when the “activator” script has been run.
Also you would win 2X points because of the two script combo :applause:
persistent:true
On your callbacks is what you need. I have often have the function being called as a library function which initializes at start up… In the plugin’s folder…
If the code is small, You can just put a string in there however…
ExStr = " setiniSetting (\"G:\\WhoRendered\\WRM_\"+ ( getfilenamefile maxfilename ) +\".ini\") \"Frame\" (CurrentTime as string) (sysinfo.computername) "
callbacks.addScript #postRenderFrame ExStr id:#WhoRenderedMe persistent:true
G: is a mapped network drive… I like to write code in a string var first so I can test it with execute before hacking it into a persistent callback…
Don’t forget Callbacks.Show() to ensure they get in there !
Well, persistent only works if the script is loaded on max startup, correct? Because just adding that to the callback that’s created in the current session still does not carry the callback through to the render.
- Neil
Hello! i´ve already used persistent callback through backburner and worked very well because it goes with the file, only diference is it was a postopen callback, but i don´t see why a pre render wouldn´t work. Also used the ones in the render dialog, like oatz sugested, and worked fine to.
sorry my bad english and if i misunderstood something, forgive me (i´m saying this because it´s weird to me to try to help Neil Blevins, so probably i misunderstood something in his question…).
Gustavo
Ya, not sure why it wouldn’t work, but it apparently doesn’t.
I may have to end up using this, I don’t want to because it will involve some ugly code workarounds, but it’s starting to look like I’ll have no choice.
Haha! I’m a very regular person who has lots of questions just like everyone else. There’s always new things to learn and hard things to figure out.
- Neil