Is there a way to make an attribute modifier that houses render resolution dimensions which could be placed on a camera. Then depending on which camera is being used at render time it would adjust the render size accordingly?
yes, there is.
Then depending on which camera is being used at render time it would adjust the render size accordingly?
that can’t work. system calls all “prerender” callbacks (or run prerender scripts) when too late to change any render setting.
That is a bummer to hear. Because there are several cases where we render multiple shots out of one max file but depending on whether or not we need additional padding on the render the resolution can change and it becomes very annoying to have to select the camera and manage all the different sizes.
i think that will be easier to make extra macro UI button to call the render. and ask an user to use this button only.
this macro will check what the current render camera(view) is, set the right resolution, and call the render.
or make a popup dialog with a list of cameras, where double-clicking (for example) on any camera from the list will call the render with specific for this camera settings.
That is a very interesting concept worth looking into. That seems like an easy enough idea to implement.
Thank you Denis
actually it might be cool not just only set render setting but also hide/unhide specific layers. let’s say do render from draft or production camera.
One day I hope to show what I made… Slightly kick-ass Render Management system
hurry up! [i][b]The Render Management system's as[/b][/i]s[b][i] must be kicked! Folk needs the Hero![/i][/b]
You would like it very much Denis it even has a MaxScript part so if it doesn’t do something you need it to do you can add your own extra bit of MaxScript into the system to make it do it
Don’t get me started!!! :banghead: :banghead: :banghead:
what if using some ‘prerender’ event send ‘ESCAPE’ message? (i don’t know where… it’s just an idea). interrupt the current render, and run your own.
fn abortRender event: = ( format ">> % " event ) callbacks.removescripts id:#render_test callbacks.addscript #preRender "abortRender event:#preRender" id:#render_test callbacks.addscript #preRenderEval "abortRender event:#preRenderEval" id:#render_test
call render (press UI button) with ESC pressed and you will see that ‘prerender’ callbacks work before render cancel.
Interesting idea. In the SDK there is Interface::AbortRender() that could be used for this taks.
sounds like the idea can work. vfb will be probably opened any way…
I just checked and you’re correct on both accounts.
i think that AbortRender() can very useful as mxs extension. let’s say in the case when ‘potentially long rendering’ was run with ‘wrong’ settings.
#preImageViewerDisplay callback returns IVFB Interface as notification param. it means that VFB hwnd is already created at that moment. if we know the hwnd we can close the window before it will be opened. the question how to know it. any ideas?
i could find nothing about the VFBInterface (or IVFB) in max SDK.
I’ve been down this road already. There is no way to get the HWND from Maxscript or the SDK. If you find such a way I will literally bang my head against the wall and increment the counter that keeps track of how many beers I owe you.
Anyways, to get the VFB HWND you have to get it yourself by enumerating windows and checking the class of their first child.
The first child of any image viewer is a BitmapWindow control.
In order to determine if this is a regular image viewer or the main VFB you must check the first child of the BitmapWindow, which is the toolbar. You must then count it’s buttons. The main VFB will have at least 10 CustButton controls in the toolbar, while a regular image viewer will have at most 9.
If anyone is interested I can share the C++ code that does this.