I’ve written a renderer plugin for max, but I’m having a bit of trouble with how it renders material previews.
Whenever a preview is being rendered (while Renderer::Render() is running), max becomes entirely unresponsive. It recovers when the render is complete, but the max window won’t respond at all while the render is in progress.
Is there some function I should be calling during rendering to allow the UI to run? For normal renders it seemed like RendProgressCallback::Progress() would do this, but it doesn’t have the same effect for material previews.
Have you seen any renderer in which this doesn’t cause 3dsmax to become unresponsive?
I haven’t looked at any third-party renderers, but with mental ray seems to work how I expect.
When i first drag a new material into the slate editor, it has a little teapot icon instead of the preview bitmap. It takes a second or two for the preview to render, but during that time the interface still responds.
This is particularly problematic for any materials that have a color component. Scrubbing around in the color picker is essentially impossible as max freezes for a second or two whenever a new color is chosen. I haven’t seen this happen with other renderers.
I have the same issue in Luxmax (Luxrender max render plugin).
It could be that in other renderers they thread it, so that the preview generation is done in a separate thread, and by doing that do not lock up the max main thread.
I have not seen any other way of doing it.
I’m currently at work – so I cannot check it, but at home I’ve used the source code for NOX as reference for a lot of things, so it might be good to check out that.
You find the source for that here:
http://www.evermotion.org/nox/downloads
I think (if I remember correctly) that they thread it in that one.
My renderer does actually run entirely in a separate thread. The problem I’m seeing is that I don’t know what to do with the thread that is executing Renderer::Render()
It essentially sits on a loop that just checks the render progress, then sleeps a bit.
I can’t return from this function until the render completes, but the max ui won’t respond until i do.
I’ll try to check out some other renderers and see if I can find any non mental ray renderers that behave how I want. If not I might have to accept that this is just autodesk magic.
EDIT: After checking our Corona render, I see that they manage to keep the window responsive while the material preview is going as well. I’ll check out Nox to see if that does as well. Having that available as a reference if it works right would be excellent.
EDIT2: Looks like Nox also hangs the ui while rendering. At least I know there is a way to do it now, will spend some time looking over the documentation.
Bumping for visibility as it has been a while.
I was unable to find anything in either the render progress callback or the functions available through GetCOREInterface() that would allow a UI redraw.
Just thinking out loud here, but can’t you just immediately return from the render method, and when your render finishes on a separate thread, update the Bitmap* you received in the original render call?
I hadn’t considered that.
I assumed that bitmap pointer wouldn’t be guaranteed to be valid after that function returned, but I the documentation doesn’t say that so it might not be. This is at least worth a try, but it will probably take me some fiddling to get it working.
I’ll post back here with results in the next day or two.
I don’t assume it to always be valid. Even if no magic happens backstage, it would probably be deleted if the user closed the material editor before your rendering finishes.
As long as you run the render as a different thread, can’t you set its priority less than 3dsMax’s? Or run it as a background task?
The foreground application would take the most cycles so make sure you don’t force the render in foreground mode.