[Closed] Grab Viewport with Multipass Effect?
To activate the multipass effect in viewport I can use :
maxOps.displayActiveCameraViewWithMultiPassEffect()
But if I then use
gw.getViewportDIB()
The multipass effect doesn’t show up.
When I run the following line directly after activating the multipass effect, I get the desired result. But if I use it as part of a script, it gives me back all 4 viewports without the multipass effect.
viewport.getViewportDIB()
Can anyone shed any light on this for me?
Cheers,
Cg.
Those Multipass effects aren’t supported in nitrous
Only the MR Depth of field effect is working in a nitrous viewport
I may be wrong, but he said he was able to get it via another scripted method, so I assume he isn’t using nitrous.
The tool I’m working on works with both nitrous and d3d. If there’s a way to do it in d3d I’ll only make that option available when possible.
Cg.
A more over-the-top (brute force, actually) method would be to go fully above 3dsMax, directly capturing the screen with .Net. Navigating 3dsMax handles, you could get every viewport Window and their coordinates in screen space, and then capturing this specific region.
Here’s two perfect references, WindowShopper by Rotem Shiffman, brilliant stuff :
http://www.monotoneminimal.com/free-tools
This will help you visualize the flow and navigate the software hierarchy, plus its code is non-encrypted, so you can get back every method he used.
You’ll get something pretty much like this, that’s for the coordinates part :
Then, for the screenshot itself, I’ll let you check this Stack Overflow’s thread :
http://stackoverflow.com/questions/3306600/c-how-to-take-a-screenshot-of-a-portion-of-screen
I’m aware this looks like an overkill (and might be), but this just popped up in my head so here it is. Good luck
works for me with both gw & viewport (2010)… though if I set the camera effect to motion blur it crashes max
my method is…
enable multipass effect on the camera
for every frame call maxOps.displayActiveCameraViewWithMultiPassEffect()
grab the viewport
on a side issue not unrelated does anyone know how to turn off the viewport menu text ?
thats an easy one
ViewportButtonMgr.EnableButtons : bool : Read|Write
(not sure this already exists in Max 2010, which you seem to be using )
EDIT:
just tested in Max 2010 and yes it works, requires a viewport refresh though …
requires a viewport refresh though …
anyone have anything better than…
max tool maximize
max tool maximize
i didn’t remember want i use… have looked in my code…
max tool maximize
max tool maximize
that looks silly i know but it’s OK because all screen-grab operations i do with disabled window redraw anyway.
If you want to enforce a full refresh/redraw of the whole viewpanel you can send a windows resize message to the viewpanel handle. I use something like that in PowerPreview ( C# code )
public int RedrawWindow( int hWnd )
{
Size sz=GetWindowSize( hWnd );
return(SendMessage( hWnd , WM_SIZE, 0, (sz.Height<<16) | sz.Width ));"
}
This even forces the viewpanel handle and the empedded viewports to get “in sync” again after i positioned/resized the viewport inside independingly…
it shouldn’t work. this message itself doesn’t do anything with window size and can’t cause repaint.
Oh … it does work see the prove in the attached image. Before i sent the message to the viewpanel handle, the layout was a perfect quad layout ( equal viewport sizes )
After i sent the message the viewpanel adopts the requested size and does’nt fit in Max’s reserved space any longer as the image shows…
As i understand it, WM_SIZE gets sent to windows AFTER the window was resized by whatever means , the perfect place to simulate a “fake” resize event to make the windows function trigger it’s client area redraw routines. That was my initial idea which seemed to do the trick after i implemented it …
But i was wrong with the viewpanel handle for the refresh stuff, you gotta send the message to the max main window handle and it refreshes all of it’s client area, including the viewport menu. That’s what i do in Powerpreview too
BTW: The menu still being operational without it being displayed seems to be a design decision -> have it still work but not be visible in previews etc…
yes, it does. but it’s not the right way to resize the window. resize process sends many other messages to the window to make it complete. functions MoveWindow and SetWindowPos do it.
but both of them don’t help to ‘reset’ view after the buttons turned OFF
no. it’s just a bug as many others. if it’s a design feature why does it go away after view resized anyhow?
It does not go away when i manualy resize the view. Turning off the viewport menu and resizing the viewports/maxmimizing/minimizing resizing the max main window
-> result viewport menu keeps being operational
And regarding the other thing about the WM_SIZE message
I did’t want to use it for an actual windows resize but to trigger Max’s viewport re-layouting mechanism in my case, or the viewport menu redraw in the other case
The method works for both scenarios here, so i’m satisfied
Maybe it would better to sent the WM_NCCALCSIZE message but you have to send some NCCALCSIZE_PARAMS structure with it
it’s not just repaint issue.
as you can see after you set ViewportButtonMgr.EnableButtons to OFF, buttons not just stay shown but also they stay functional.