BUG or feature? IPR button disconnect with ROP

   4296   7   1
User Avatar
Member
7024 posts
Joined: July 2005
Offline
Hi,
Don't know when it happened, but the button for turning on/off IPR above the IPR viewport doesn't connect to the ROP. This is highly, highly confusing. Is there a reason or is this a bug?

Cheers,

Peter B
User Avatar
Member
7709 posts
Joined: July 2005
Offline
A search for IPR on the Journal page reveals:
Tuesday, November 1, 2005
Houdini 8.0.409: The IPR enable toggle in the IPR pane is now an independent control from the ROP IPR enable toggle. When rendering within the IPR pane, the IPR enable toggle will override the one on the ROP node being rendered. The default is enabled, and this toggle is saved within the desktop preference rather than the .hip file.

In my opinion, this newer behaviour is much more *less* confusing than the old behaviour. Why should a toggle in the IPR Pane change an actual parameter? No one without prior knowledge expects that.
User Avatar
Member
7024 posts
Joined: July 2005
Offline
As always, I think we'll need to agree to disagree about what is intuitive.

Here's the scenario In the IPR viewport, I turn on IPR. Since ROPs don't automatically specify objects to raytrace (and how often do people render without raytracing these days?) I have to click the button that pops up the ROP dialog.

WTF? The ROP says IPR is off, but I just turned it on. What's going on? So, now I have to click IPR on the ROP so I can specify which objects to cache, which objects to raytrace etc. Now I have turned on IPR twice.

To further complicate things, what happens if I turn off IPR in the IPR viewport? IPR is still on in the ROP. Does that mean the IPR viewport is not using IPR even though the ROP has it on? I don't know, it's unintuitve!

Cheers,

Peter B
User Avatar
Member
7709 posts
Joined: July 2005
Offline
Are you saying that it's not natural to see whether IPR is enabled in the IPR pane from the IPR toggle in the in the IPR pane? Doesn't that seem like the obvious behaviour? Hitting the render button from the ROP parameters pane uses the IPR toggle in the ROP parameters pane. It still sounds to me that you're only confused because you learned and expected the previous behaviour.
User Avatar
Staff
5156 posts
Joined: July 2005
Offline
I think what Peter's saying is that there are two toggles in two different spots for the same thing. Because they aren't linked together, the behaviour is difficult to determine, and there's no real way to make it intuitive. Is IPR enabled if only both are on? Or either is on? Or is the IPR pane button an override for the ROP IPR parm? Since all seem equally plausible, the actual behaviour must be documented (and thus it is no longer intuitive).

If it is an override, then the IPR pane toggle should actually be a menu: Force IPR on, Force IPR off, Use ROP IPR Setting - at least then the user knows it is a different setting. And in this case, the ROP shouldn't be disabling its IPR parms when its IPR toggle is off.
User Avatar
Member
7709 posts
Joined: July 2005
Offline
I contend that those options you list there are _not_ equally plausible because the other options are not useful.

Having them linked is bad because it's easy for someone to load a hip file, use the IPR pane, and then save their hip file with IPR enabled in the ROP (because they didn't even realize that there exists an IPR parameter in the ROP). What happens when it gets sent to the render farm? We don't want it generating IPR caches per frame. When they were linked before, the IPR toggle is off by default because that made sense for the ROP. But having IPR turned off in the IPR pane by default is silly. There's little reason to use the IPR pane otherwise. Personally, I see little value in having an IPR toggle in the ROP parameters in the first place.
User Avatar
Staff
5156 posts
Joined: July 2005
Offline
A user can work out that the other options aren't plausible, but they have to go through a little mental exercise to figure that out (does A and B make sense? does A or B make sense? okay, it must be A overrides B… right?). That's not good design.

If it's not useful to have IPR on in the ROP, and it doesn't make sense to have IPR off in the IPR pane, then why have any IPR toggles at all? So I suspect that there are cases for both the ROP and the IPR pane to have IPR in the “other” state. I just think that the IPR pane should have the option clearly marked as an override, and in the ‘Force IPR on’ state by default.
User Avatar
Member
1002 posts
Joined: July 2005
Offline
As far as I know, it could be necessary to turn IPR on or off either in the ROP or the IPR viewer. Since generating IPR cache files can slow down the render and use up disk space, it is necessary to allow IPR to be turned off in the IPR viewer. Since is is possible that a ROP is explicitly set up to generate a cache file for later use (without needing to render in the IPR viewer), it is necessary to allow the IPR to be enabled on the ROP.

I think what Peter has found confusing is that to edit the IPR options on the ROP it is necessary to enable the IPR setting on the ROP (we disable the IPR parameters if the ROP IPR enable toggle is off). Maybe these parameters should be always editable. And I agree, maybe we should be more explicit about the override nature of the IPR pane toggle.

Note: the original motivation for this change was to reduce the complexity of starting an IPR render. Before, the IPR toggle could not be changed until a ROP was selected (leading to awkward workflow where it is necessary to switch context to the ROP, turn it on, then switch back).

Andrew
  • Quick Links