On the top of many peoples wishlist is a region render for hydra. Technically you can kindof do it when switching to image view instead of perspective, but that view is not really functional as far as I can tell.

However, while playing around with the camera pan & scan I noticed that shift+left mouse button will allow you to draw a region for rendering. Works well in karma, and sometimes even in redshift. Buggy, a bit dangerous to use, and not super user friendly, but it is there. Does this mean that there is hope in the near future to get a region render for the viewport? That some wonderful sidefx dev is testing the waters here? (please say yes)

You're right, I don't see it in the What's New [www.sidefx.com] nor in the Solaris Scene Viewer [www.sidefx.com] pages, but it's there in the Journal/Changelog:

Houdini 19.0.373 Added render region support for render delegates in the LOPs 3D viewport, by Shift+LMB dragging while in the 2D mode of the View state. This only affects delegates that use the AOV interface.

It's must have slipped through the documentation cracks...

It also does’nt say in the viewport HUD instructions either.

While I want to throw massive amounts of digital hugs at the developer doing this, I would strongly suggest not making it part of the 2D pan & scan. It is not user friendly or easy to keep having to jump between camera tumble and pan scan. It also doesnt respect the reset function.

A better way would be having its own icon so it can be used fast. Just an on/off toggle like the appriciated paus button just added. Under the magnifier/lupe icon in the left side toolbar would make sense to me.


Why it doesnt fully support redshift is also a problem. To me, render region is basically a temporary camera crop, so I find it hard to understand why the implementation would not work across all renderers.

Last thing, when using render region, it is important to be able to see the houdini GL viewport for anything outside of the render region. Gets very disorienting trying to find the region you want otherwise.

There is already a pretty good render region UI in /obj... I really don't understand what's wrong with it? Why not making /stage render region work like that? Just the exact same UI, except the dropdown menu doesn't choose from ROPs but delegates?

raincole
There is already a pretty good render region UI in /obj... I really don't understand what's wrong with it? Why not making /stage render region work like that? Just the exact same UI, except the dropdown menu doesn't choose from ROPs but delegates?

I'd be happy if they just added that icon from /obj for the render region they've just built. No need for the /obj toolbar or options. Seems like the fastest solution.

I would tend to agree, although I will say that once you know about it, it becomes quite useful to have it in the 2d nav mode because you can move around the image (pan&zoom) in a way that you can't do in 3d nav mode. Having the ability to zoom into a 2d render can be incredibly useful when fine-tuning aspects of your render (e.g. particle sizes in debris clouds) - something I would do in the Render View a lot.

The convenience issue did come up in beta, however, and now that the functionality is there perhaps it would be possible to make a shortcut to get to it (or a 3d nav variation of it) right on the viewport.

I see what you mean, but I’m thinking there’s nothing stopping you from going into pan&scan anyways if the region render was outside of it.

Think the biggest two issues is that it requires multiple secret clicks to get there, so not very intuitive. The second is that it doesn't reset with the usual reset button. Frankly I ended up screwing up my viewport multiple times trying it out, with only a restart to fix it. Also you cant see the geo outside the region. Even clarisse solved that with a wire screengrab.

Somehow I missed this gem during beta. But I'd say this feature is more in alpha state as is.
I love houdini, but dear lord is there some halfbaked stuff going on with these things.

The image view (nr 5), for viewing your image, is still a mess and not usable for anything. The rendergallery is a completely different way of viewing and rendering the image. And the viewport is another.

And the red handles around the image when selecting the camera still doesnt do anything (would have been great as a region render...hint hint..). And lastly the mess that is trying to get functional overscan with the data window settings and expand/crop settings being weird a.f.

Why not remove these things until they are actually usable. Cause once (if) they become functional in like H28 most people wont notice, its not like its a headline feature hehe.
I'd be happy with a release with zero big features and just some much needed polish on things.

AndreasWeidman
I'd be happy with a release with zero big features and just some much needed polish on things.

Yeah people say this for every single software, even Blender (or should I say, especially Blender). But the dev has to keep churning out new features because other people require them. There is no win-win.

I absolutely hope Solaris will be polished soon.

AndreasWeidman
I see what you mean, but I’m thinking there’s nothing stopping you from going into pan&scan anyways if the region render was outside of it.

How would you see a pan&scan working in 3D? It's conceivable create a 2D zoom effect in 3D with windows and offsets, etc - but that would cause a re-render to occur so a region zoomed in this way would still render every pixel and not just be a 2d scaling on the resultant render. 2D scale of renders is useful to prevent you squinting at your screen when working at your target resolution and I don't see how you can formulate a consistent UX to make that happen in the 3D nav mode.

PS. You can emulate that behaviour in the Obj viewport when you ctrl-drag a zoom region, not sure if this is possible on the LOP camera right now as I don't see the necessary attributes on the Camera LOP. The other non-working standard camera handle components also rely on attributes that not in the standard UsdCamera schema too, and yeah ideally they should be disabled/unavailable until they work.

jason_iversen

AndreasWeidman
I see what you mean, but I’m thinking there’s nothing stopping you from going into pan&scan anyways if the region render was outside of it.

How would you see a pan&scan working in 3D? It's conceivable create a 2D zoom effect in 3D with windows and offsets, etc - but that would cause a re-render to occur so a region zoomed in this way would still render every pixel and not just be a 2d scaling on the resultant render. 2D scale of renders is useful to prevent you squinting at your screen when working at your target resolution and I don't see how you can formulate a consistent UX to make that happen in the 3D nav mode.

I'm thinking that a region render icon outside of pan&scan would behave the same as in pan&scan mode, but if you want to adjust the pan&scan, only then you switch to that mode. The region render would render whatever is on the screen, zoomed or not, like it always does. The only difference is that you don't have to jump through pan&and scan hoops for a quick region render.

Adding to this…

most of the time I'd prefer a newly draged render region not to clear viewport. That way we can focus on multiple parts of an image without loosing what's alrady been rendered.

Also something to think about… instead of a cleared viewport, maybe a single progressive pass could help to have the region in a better context. The viewports background color can be visaully distracting.

Just some thoughts.

Andy_23
Also something to think about… instead of a cleared viewport, maybe a single progressive pass could help to have the region in a better context. The viewports background color can be visaully distracting.

There is a school of thought that the MPlay "click to focus rendering" feature would almost entirely supplant the need for a fixed render-region, its just that many renderers don't implement a user-driven focus as nicely as Karma (and Mantra) does. The way the render region is currently implemented it will work for all renderers.

SideFX could make the Karma experience best-in-class if they do things like you suggest or implement click-to-focus, and maybe other renderers will follow suite if they see happy Karma users?

Yes Jason, you are absolutely right about 'click to focus rendering' it's something that kept us with Mantra all these years. I wish we could have it in Karma in the viewport somehow. Some modifier clicking perhaps, or even a tool in the left sidebar.

Let's hope.

While click to focus is great for the renderer when not in region render mode, (although that would be a hydra decision, not houdini specific I think), one big purpose of the region render is to have your ref in the viewer (or other render to compare), and work your lookdev/light identical to the ref by having the render-region in a specific spot. You wouldn't want it to move or expand.
The other use case is of course if its a heavy render and you just need to dial something small in.

Yeah, I'm not sure a one-size-fits-all really exists for the various use-cases (e.g. rough lighting, detail lighting, fx/procedural tweaking, all with A/B'ing, 2d zoom, etc) but I would say that the venerable Render View got quite close for me. The bucket vs. progressive button at the top, and the easy-to-manage rendering-in-place snapshots covered the major rendering modalities quite well for me. This has become a more complex UX now, with the 2d nav in 3d being more awkward, separate Render Gallery (needs more clicks, and more screen space) however I'm holding out hope that a usability and functionality pass at these at some point will narrow the gap.

Thank you for your words, I feel the same way about the old IPR Render View.

Not sure which render view you are referring to, Solaris Hydra render? Or the /obj render?
Perhaps we need to see to see hydra and rendergallery as two separate renderers, just like the old viewport-ipr and mantra renderview.

Rendergallery would be the place for a/b comparison and background rendering, and should ofc have a good region render and focus render. Sadly the rendergallery images is only saved per file, so versioning up in our pipe means loosing all previous images, making it not usable for anything for us.

The hydra renderview is great as is. Sure, would be nice with some extra toggles, but we have our own custom viewport rendersettings anyways. All we really need is the existing pan&scan region render there to work without needing to switch to panscan first, and that the rest of the viewport doesnt get cleared.

AndreasWeidman
Sadly the rendergallery images is only saved per file, so versioning up in our pipe means loosing all previous images, making it not usable for anything for us.

This should not be the case... The same set of render gallery images can be shared across many hip files as long as they all have the same parameter value pointing to the render gallery database. This is a parameter on the LOP Network node. The default value does have $HIPNAME as part of the database file path, but that value is supposed to get "baked" into a HIPNAME_independent value as soon as you add an image to the gallery. If this is not the behavior you're seeing, please submit a bug report. Thanks!

mtucker

AndreasWeidman
Sadly the rendergallery images is only saved per file, so versioning up in our pipe means loosing all previous images, making it not usable for anything for us.

This should not be the case... The same set of render gallery images can be shared across many hip files as long as they all have the same parameter value pointing to the render gallery database. This is a parameter on the LOP Network node. The default value does have $HIPNAME as part of the database file path, but that value is supposed to get "baked" into a HIPNAME_independent value as soon as you add an image to the gallery. If this is not the behavior you're seeing, please submit a bug report. Thanks!

Will do, that is not what we are experiencing. Thanks for pointing that out!

Honestly, the old RenderView for LOPs would be ideal. That's probably the number one request from lighting artists at our studio.