search

BigRoy / usd-qtpy

Python Qt components for building custom USD tools.
MIT License
57 stars 8 forks source link

Add usd view render and playblast functionality #1

Open BigRoy opened 7 months ago

BigRoy commented 7 months ago

Expose a way to easily render an image sequence output from GL or a supported Hydra renderer for the USD view viewer.

Similar features appear in:

I'd say this should be an easy entry point via the api/lib first and then expose it to the user via a GUI second.

BigRoy commented 7 months ago

Adding a reference, there's a tool called usdrecord which could be a reference for this feature, see example Python file here

Note how that uses pxr.UsdAppUtils.FrameRecorder to render the frames which could be the library we can use as well. I wonder if that's what @RichardFrangenberg is also using in his Prism editor.

As mentioned originally I believe USD View also has capabilities of rendering a sequence or capturing an image - but I might be mistaken.

Sasbom commented 7 months ago

playblastview01 00

snapshot

Had some issues but the rudimentary functionality is working. I kept getting errors but it turns out I forgot that garbage collection exists Now everything works as intended, which is fun It can already do sequences, and switch to different render engines that are available.

Auxilliary functions to populate UI with later on are all available too!

I'm not making a PR yet, but here's the fork I'm working on.

https://github.com/Sasbom/usd-qtpy/tree/enhancement/usdview_render_turntable

BigRoy commented 7 months ago

Good stuff! :) Looking forward to seeing more progress.

BigRoy commented 7 months ago

Adding other references:

Some visuals playblast/render UIs from Prism: prism_usd_render prism_usd_presets_turntable prism_usd_playblast

Sasbom commented 7 months ago

Adding other references: ...

Small note on this one in particular, all of what happens here is covered by the thumbnailer code too but more thorougly, with one fatal flaw (for the time being) that most of the information is stored in a RenderSettings primitive, which only Renderman appears to have compatibility for. Therefore, this approach shouldn't be implemented in full.

Quoting from the thead:

Update:

Spiff clarified for me that as of right now (USD 23.11) only the prman renderer supports render settings, 
so I would assume that means to set things such as a custom pixel resolution one would need to make 
their own renderer using the imagingGLEngine schema.
BigRoy commented 7 months ago

RenderSettings primitive,

Actually - I think all major renderers support it, at least Arnold, V-Ray and Redshift render from RenderSettings prims. I suspect it's just the GL renderers that not necessarily render using 'render settings'? Or at least, in e.g. Houdini the Render Settings prim is what defines how the renderer renders it.

Sasbom commented 7 months ago

Actually - I think all major renderers support it, at least Arnold, V-Ray and Redshift render from RenderSettings prims. I suspect it's just the GL renderers that not necessarily render using 'render settings'? Or at least, in e.g. Houdini the Render Settings prim is what defines how the renderer renders it.

While working this popped into my mind too, but I wondered if it was actually a USD or specifically a solaris thing, since I only really know it from working with Karma/Redshift in that context so I wasn't quite sure.

I don't know if this is the exact same thing, and it seems like it's not nessecarily the most surefire way of dealing with it, so I'd like to avoid RenderSettings primitives for now. A lot of information seems to be deduced from the camera, and the thumbnail generator tool seems to set it up very nicely.

BigRoy commented 7 months ago

While working this popped into my mind too, but I wondered if it was actually a USD or specifically a solaris thing, since I only really know it from working with Karma/Redshift in that context so I wasn't quite sure.

Should definitely be a USD thing - it's all in their api from RenderSettings, through RenderProduct to RenderVar.

I don't know if this is the exact same thing, and it seems like it's not nessecarily the most surefire way of dealing with it, so I'd like to avoid RenderSettings primitives for now. A lot of information seems to be deduced from the camera, and the thumbnail generator tool seems to set it up very nicely.

The more we can simplify the better - and I feel for GL captures since they don't support render settings we'll need to go that route anyway. Thanks!