PDA

View Full Version : Image Viewer Display Notifications in Max 2009


ypuech
04-28-2008, 02:27 PM
I have some questions about this new feature in Max 2009.

How to enable/disable the default rollouts panel created at startup ? I've edited VFB_Methods.ms to fit my needs. Are there settings on that ?!
It seems we can only set one rollout panel per visibility (TopLeft, TopRight, Bottom). Ok for the TopLeft and TopRight but it would be very useful to be able to register several rollout panel for the Bottom visibilty for example (they would be docked).
So for example in mental ray rendering mode and without editing VFB_Methods.ms, we cannot add our rollout panel. And there's no way in all modes to disable the Topright and TopLeftpanels. Is this right or am I missing something important ?

The workarounds I found are:
- remove the scripts callback for the VFB_methods (enable or disable all rollouts panel)
- add a new enabled property in the struct for the rollout info in VFB_methods (using INI settings to enabled or disable rollout) so we can enable/disable a specific rollout panel.

Bobo
04-28-2008, 02:58 PM
I have some questions about this new feature in Max 2009.

How to enable/disable the default rollouts panel created at startup ? I've edited VFB_Methods.ms to fit my needs. Are there settings on that ?!
It seems we can only set one rollout panel per visibility (TopLeft, TopRight, Bottom). Ok for the TopLeft and TopRight but it would be very useful to be able to register several rollout panel for the Bottom visibilty for example (they would be docked).
So for example in mental ray rendering mode and without editing VFB_Methods.ms, we cannot add our rollout panel. And there's no way in all modes to disable the Topright and TopLeftpanels. Is this right or am I missing something important ?

The workarounds I found are:
- remove the scripts callback for the VFB_methods (enable or disable all rollouts panel)
- add a new enabled property in the struct for the rollout info in VFB_methods (using INI settings to enabled or disable rollout) so we can enable/disable a specific rollout panel.

What I did for Krakatoa 1.1.1 (coming soon) was just that - I implemented MY own structure, registered a PostRendererChange callback which would unregister the callbacks Autodesk shipped and register mine if Krakatoa is found as the renderer, and if it isn't, register back the original callbacks.
I am sure you can use a SubRollout inside the bottom panel to get multiple rollouts there.

ypuech
04-28-2008, 10:04 PM
Thanks for sharing your solutions Bobo!

About the bottom panel, SubRollout solution is a good idea.

EDIT: I just noticed the page "Rendered Frame Window and MAXScript"; there's a useful example.

ZeBoxx2
05-06-2008, 11:39 AM
To expand on this, first a bunch of questions...

1. Can you get the floaters 'attached' to a VFB?
I know you can get them for the default max rollouts as it nicely has those rollouts in a struct which has a .floater_ property that gets set. This is for when third parties add their rollouts (overriding the defaults)

2. Can you resize an 'attached' floater without having to re-initialize the floater window?
Assuming you can get the floater (see above), changing the .size of it has absolutely no effect. Nor does changing .width of the rollout that's within that floater.

3. What is the (apparently undocumented) #imageViewerUpdate callback event?

4. Can you get the bitmap for a given VFB?
getLastRenderedImage() for framebuffer VFB's aside - and that function doesn't quite return the bitmap in such a VFB per se.

1 & 2 are basically questions pertaining to the whole There Can Be Only One (of each area) thing when it comes to this new feature.
E.g. if somebody has an in-house tool in the bottom rollout floater and, well let's take your example, the Krakatoa rollout function then promptly goes ahead and replaces it with its own (presuming that your callback is later than any in-house tool callbacks that might actually override the Krakatoa rollouts again), that might not be entirely desirable behavior.
So ideally I'd want to check if there's already a bottom rolloutFloater and if A. there isn't
I'll make my own or B. there is and I'll add to that. Adding to the exsting floater means, quite likely, that the vertical height of the thing is going to have to expand - possibly the width as well.

Right now I'm already trying to play as nice as possible with the existing methods by injecting my own bottom rollout into the VFB_methods' VFB_RolloutInfo_Array, specifying our renderer as the required class for it to be displayed. This automagically makes the rest (renderer changes, open/close, etc.) happen via the VFB_methods struct and I get to keep the top two rollouts without having to add those back in myself, etc.
On the other hand, the very first utility that goes ahead and wipes the max default ones is going to happily ruin that (a #postRendererChange that re-instates the rollout fixes that, of course ).
Getting it to play nice with non-default stuff would be quite nice, but I'm not quite seeing methods for doing so. I can work around #2, but #1 is pretty much essential for it to work.

Bottom Button Bottom Button Bottom Button

Bobo
05-06-2008, 01:57 PM
Right now I'm already trying to play as nice as possible with the existing methods by injecting my own bottom rollout into the VFB_methods' VFB_RolloutInfo_Array, specifying our renderer as the required class for it to be displayed. This automagically makes the rest (renderer changes, open/close, etc.) happen via the VFB_methods struct and I get to keep the top two rollouts without having to add those back in myself, etc.
On the other hand, the very first utility that goes ahead and wipes the max default ones is going to happily ruin that (a #postRendererChange that re-instates the rollout fixes that, of course ).
Getting it to play nice with non-default stuff would be quite nice, but I'm not quite seeing methods for doing so. I can work around #2, but #1 is pretty much essential for it to work.

Bottom Button Bottom Button Bottom Button

Richard,

If you are modifying the content of the shipping struct by injecting your own definitions and leaving it to the original callbacks to deal with the management, then Krakatoa is probably not going to affect your code. All I do is disable the original callbacks without modifying the structs at all (as I don't use them) and installing temporatily mine. Then, when Krakatoa is not the renderer anymore, I just unregister mine and register the same callbacks that shipped with Max, but whithout reinitializing the whole struct.

I just don't want to mess with the shipping code and I really don't want any of the original rollouts which are, IMHO, vasting space. (of course, my version of the VFB requires a "Don't Panic" sign in large friendly letters, it is that overwhelming (http://www.scriptspot.com/bobo/krakatoa/Krakatoa_max2009_VFB_WIP_tk103.jpg).)

As for the other questions, I don't think you can do most of them. The undocumented callback appears to call a function whenever something changes in the VFB - I found it myself last week, but I am not using it for anything.

ypuech
05-06-2008, 02:16 PM
my version of the VFB requires a "Don't Panic" sign in large friendly letters, it is that overwhelming
We can recognize Bobo touch in these VFB panels :).

As for the other questions, I don't think you can do most of them. The undocumented callback appears to call a function whenever something changes in the VFB - I found it myself last week, but I am not using it for anything.
It's documented in the SDK Help but it's called too often and not very useful.

ZeBoxx2
05-06-2008, 02:47 PM
Thanks bobo!

not re-initializing the Struct - awesome :) *crosses fingers that nobody else does*

not being able to get the floaters - pewp. *hands that little pitfall over to the documentation dept a.k.a. the other hand*

'll see if I can do a little configuration panel thingy for which rollouts to show and, in case of pre-existing rolloutage in the bottom, allow the user to specify a variable that contains the floater (expert users only) so that I can add to that... with any luck.

few holes in the implementation there - ah well :D

Thanks again :)

CGTalk Moderation
05-06-2008, 02:47 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.