Karma rendering VFB (Visual Frame Buffer)

   802   6   3
User Avatar
Member
253 posts
Joined: July 2013
Offline
..to continue the conversation about a VFB that started in another thread: https://www.sidefx.com/forum/topic/94120/#post-411195 [www.sidefx.com]

What I'm really missing is a proper VFB for Karma, currently there is the "viewport preview" and "render to MPlay", both have their uses but it leaves quite a gap in features and UX. (To SideFX: UX means User eXperience, it's a strange concept but bare with me here.. )

Obviously I can't speak for everyone's workflow but I think in general creating a render consists of 3 modes:

1) General lookdev, basically tweaking materials, lights etc.
2) Optimizing, trying to keep the same look but in a fraction of the initial rendering time.
3) Solving tech issues. Getting things into the right AOVs or finding ways to avoid steps in comp. Hunting for workarounds and glitches and so on. Basically all non-artistical related things.


For step 1: The viewport is alright, gives instant feedback and gets the jobs done, it's actually quite nice.

For step 2: the viewport doesn't help, hard to tell rending times and hard to compare different setups. In theory MPlay could do this but in reality it just doesn't work for this, or for anything actually tbh. Feedback is minimal and usually there is no clue anything is going on until images pop in there. For this you need al the info possible, from sampling coverage to how it's spending cpu/gpu on each step from scene to pixel to file on disk

For step 3: Quickly toggle features/override shaders etc to find the source/trigger of any issues that might arise. This could involve both bugs in the engine and things like insane light values, 1.0 albedo's etc.

I'm mostly just using the the Karma rop and staying out of the USD stage for now, I'm a one man band and I've really tried, and appreciate what USD is on a technical level, but I'm having a hard time justifying the overhead for what it brings to me. So it could be that the whole experience in the USD stage is much better, so the following is all purely from a /obj level view.

The Karma rop has 3 relevant buttons.. 'Karma Viewport', 'render to disk' and 'Render to MPlay'.

"Karma Viewport": The viewport that pops up and it does the jobs, it feels a bit disjointed and I can't find a way to use the current viewport as a KarmaViewer or set one up manually docked in main ui? Looking at the code behind the buttons I could probably script something but for now it does the job.

Render to disk.. does what it does

"Render to MPlay": Does nothing when pressed or so it seams.. it does quietly start rendering and when it's done it pops up and I don't think it actually renders again until je dump the frame from MPlay or scrub to another frame. Anyways, not useful for doing iterative renders need during step 2 and 3. It's hard to tell rendering progress and it's just pops in when it's finished.. might as well just save it to disk then. Also it's using the 'frame range/current frame' settings. What we need here is a 'production render' vs 'iterative render' workflow, again easy to setup with a few nodes but it's such a basic workflow feature that it should be in there.

And I'd like to see the image evolve/buckets during render, I don't have to wait till the end to judge if something is alright or not. Also simply drawing a rectangle in the render to just render that part or click to focus rendering power on specific area, compare with previous versions, view various stats etc. Also some photometric camera properties could be set by clicking/sampling the viewport. focus distance, white balance, exposure etc. I could write a really long list here but have a good look at VRay and RedShift VFBs they are a very big part of the whole rendering workflow.

I think a good starting point and a big improving would be to have just a simple panel that's like the KarmaSceneViewer but just showing the rendering/rendered rasterized bitmap. By default it should only update with the 'render' button is pressed so it's content isn't as volatile as the viewport preview. Also just render the current frame by default, ignoring any rop settings for this unless told to do so. Then add some non-lookdev features to accommodate step 2 and 3 and take it from there.
More code, less clicks.
User Avatar
Member
7770 posts
Joined: Sept. 2011
Offline
have you tried the render gallery?
User Avatar
Member
1621 posts
Joined: March 2009
Offline
I have always been a rather vocal apologist of the "framebuffer" workflow a la mplay.

Since H20's render gallery, I switched my workflow over to it, it's really working quite well.
Martin Winkler
money man at Alarmstart Germany
User Avatar
Member
253 posts
Joined: July 2013
Offline
jsmack
have you tried the render gallery?

It looks like it's not really designed to work from /obj level, things like 'revert network to this state' etc do nothing. And besides that, I guess it's more a lookdev tool as it doesn't exactly represents what is going to be saved to disk in the end because it's based on snapshots from the viewport, capturing handles and all.

Having a 1-to-1 representation of what actually will be saved during a production render, in a panel somewhat similar to the gallery, is quite a necessity imho.
More code, less clicks.
User Avatar
Member
273 posts
Joined: Nov. 2013
Offline
Jonathan de Blok
It looks like it's not really designed to work from /obj leve
By placing down your own sceneimport lop followed by a karmarendersettings lop in /stage, you might be able to utilize the render gallery while working primarily in /obj. The default karma rop is using a sceneimport internally, so getting the same result should be doable. Using the "Background" button instead of the "Snap" button should launch a render that matches what would be written to disk. It seems to be necessary to have a /stage scene view open looking through the correct camera as well (I'm not sure why the camera specified in the karmarendersettings isn't enough)
Edited by antc - Jan. 28, 2024 13:58:24
User Avatar
Staff
451 posts
Joined: June 2020
Offline
Thanks Jonathan for the original post, this is great feedback!

I appreciate your desire to avoid drowning in the USD ocean, but I'll echo what's been said above and suggest at least getting your toes wet with the proposed two-node SceneImport+KarmaRenderSettings (or possibly three-node - adding a UsdRender) setup in /stage.

A lot (not everything) of what you've described is available through a combination of the Render Gallery and the Cloning introduced in Houdini 20.0.

If you haven't yet seen it, have a glance at https://www.youtube.com/watch?v=R4SLw5EdzQ8 [www.youtube.com] (I think from minute 9-19 would be the most relevant section).

One thing you mentioned was "Also simply drawing a rectangle in the render to just render that part or click to focus rendering power on specific area" ... and this you *can* already do in the Karma viewport. See attached video.
Edited by robp_sidefx - Jan. 29, 2024 06:04:43

Attachments:
region-(2).mp4 (14.0 MB)

User Avatar
Member
253 posts
Joined: July 2013
Offline
robp_sidefx
Thanks Jonathan for the original post, this is great feedback!

I appreciate your desire to avoid drowning in the USD ocean, but I'll echo what's been said above and suggest at least getting your toes wet with the proposed two-node SceneImport+KarmaRenderSettings (or possibly three-node - adding a UsdRender) setup in /stage.

A lot (not everything) of what you've described is available through a combination of the Render Gallery and the Cloning introduced in Houdini 20.0.

If you haven't yet seen it, have a glance at https://www.youtube.com/watch?v=R4SLw5EdzQ8 [www.youtube.com] (I think from minute 9-19 would be the most relevant section).

One thing you mentioned was "Also simply drawing a rectangle in the render to just render that part or click to focus rendering power on specific area" ... and this you *can* already do in the Karma viewport. See attached video.

Ok wow,, maybe it's more a discoverability issue then a missing features issue then I totally missed those region tools and the bit about cloning render instances and such. It looks brilliant for a lot of things I do and maybe I was also a bit stuck in the 'this is what I'm used to' mindset.

That minimal USD setup that was mentioned, or just using the contents of the Karma rop reworked to do it's thing directly on the USD stage should be manageable. And I do a lot Houdini/Unreal back and forth so maybe I should look at levering USD in Unreal as well since that's also working with a native USD stage.
More code, less clicks.
  • Quick Links