In our company (alterface.com) we develop a lot of interactive shooting games. Our 3D artists rely a lot, in Max, on the “auto region selected” feature when rendering a shootable character. Especially if that character is small but moves a lot across the shooting screen: in “auto region selected” mode, Max will automatically set a rendering region around the selected object, and re-adjust that region before rendering each frame, following the object motion across the scene. Which leads to huge rendering time saving.
The problem is that the “auto region selected” mode only works for local rendering, but not in net render mode (backburner).
I tried to overcome that limitation by adding a “#filePostOpen” callback script to my scene, that sets the “auto region selected” mode if the scene is opened in net server mode:
if IsNetServer() then (
format “NetServer mode detected !\n”
format “Setting auto region selected...\n”
This *seems* to work, as the “auto region selected” toggle button is shown in the ‘pressed’ state in the rendered frame window, but in practice the rendering is done using the default region (whole output image except 20% borders on each side).
So I tried another approach, computing the region myself from the object’s bounding box (<node>.min and <node>.max) and using a #preRenderFrame callback script to adjust the region at each frame.
Computing the region from the object’s bounding box works well, but the frame-per-frame adjustment shows a one-frame delay: even if I adjust the region just before frame 1 is rendered, the new region is not taken into account for frame 1, but for frame 2.
It looks like Max, before executing the #preRenderFrame callback, takes a private copy of the rendering region pos and size, and uses it for the rendering. So the region adjustment performed by the callback will be taken into account when Max takes a new private copy of the region, before rendering the next frame.
For a multiple frames rendering, I can cheat and adjust the region so as to match “where the object will be at the next frame”. It works fine. But I still have an issue for the first frame in the batch (even if I use an additional #preRender callback in the hope that it will fix the region for the first frame). Given that, in practice, most backburner jobs are 1-frame jobs, it is almost no help at all.
So that’s where I stand… A bit clueless now, I’m afraid. Any fresh ideas? I’d be really grateful if you could help me complete that mission - I’ve grown quite frustrated after all these failures and “almost but not quite” successes… :)
Thanks in advance guys,
WinXP pro 2002 SP3
What if you set frame 1 using the #filepostopen callback, and then set the other ones using a #postRenderFrame callback? So after frame one you would get currentTime+1 (I think that should do it, not sure if the callback returns the frame that was completed or the next frame), calculate the bounding box, set the region. Now frame 2 should respect that during the render preparation for frame 2, etc. #preRenderEval may also work, but not sure on that.
One thing remains unclear: if I use a #filePostOpen callback to set the region for the first frame, how can I know its “current time”? If I submit a job to our render farm via backburner, the frames will be distributed amongst the various farm PCs, so each one will have a different “first frame to render”. Is the index of that first frame already known in the context of a “filePostOpen” callback? If so, any idea how I can get that information? I remember I tried to use the value of the “currentTime” global in a filePostOpen callback, but it was always 0, even if the net render job started at a higher frame number.
any news about the script selection to use auto region with backburner?
I could use this feature every day, but without net rendering it’s unusable.
i found a way to use a script with the net render, but unfortunately not with backburner. the answer is thinkbox`s deadline, their you can send max scripts to the network. you can download deadline for free and use it in free mode with 2 more slaves, so you can render at least on 3 nodes. in addition to that, you can assign “concurring tasks”, that every node starts multiple instances of max and expands the number of “render nodes”.
hope that infomation helps you :)