usdrecord: empty output for files that are visible in usdview

[hybridherbst]

Description of Issue

According to the docs, usdrecord should have a similar output to usdview. However, the following files all result in empty renderings:

On the ASWF slack someone mentioned the possibility that extents are missing. However, that doesn't stop usdview from producing a reasonable image. And authoring the extent doesn't produce an image either; I've attached a file both with and without extent.

Steps to Reproduce

1. Download
   Avocado.glb.three.usdz.zip
2. Run usdrecord Avocado.glb.three.usdz Avocado-with-extent.png
3. Download
   Avocado.glb.three.usdz.no-extent.zip
4. Run usdrecord Avocado.glb.three.usdz Avocado-without-extent.png

Note both resulting images are empty.
Open the files in usdview to see that they are visible (albeit small - but both the same small).

This file also already renders empty and has extents authored (direct export from Blender):
sphere.usda.zip

System Information (OS, Hardware)

Both Windows 11 and M2 MacBook Pro

[carlynorama]

I don't know what's causing this but FrameRecorder seems to have its own code for setting up the scene that may be different than usdview's here

[jesschimein]

Filed as internal issue #USD-8544

[drwave]

I expect the issue is that the default clippingRange is probably cutting out this pretty small model. I added a camera that had a clippingRange of (0.01, 250) and it showed up fine. When I use usdrecord, I always make a point of having a specific camera that I do my recording from. That way I’m not beholden to any default magic that might be happening, and I know what composition I should be getting. So in my case, for a given asset, I generates a “cameras” file that puts in my own DomeLight (so I’m not beholden to the default one) and a camera that I can reference with the —camera flag, and, in my experience, it always works fine. Hope this helps. - wave

…

On Jul 29, 2023, at 6:46 AM, hybridherbst ***@***.***> wrote: Description of Issue According to the docs, usdrecord should have a similar output to usdview. However, the following files all result in empty renderings: On the ASWF slack someone mentioned the possibility that extents are missing. However, that doesn't stop usdview from producing a reasonable image. And authoring the extent doesn't produce an image either; I've attached a file both with and without extent. Steps to Reproduce Download Avocado.glb.three.usdz.zip <https://github.com/PixarAnimationStudios/OpenUSD/files/12207280/Avocado.glb.three.usdz.zip> Run usdrecord Avocado.glb.three.usdz Avocado-with-extent.png Download Avocado.glb.three.usdz.no-extent.zip <https://github.com/PixarAnimationStudios/OpenUSD/files/12207290/Avocado.glb.three.usdz.no-extent.zip> Run usdrecord Avocado.glb.three.usdz Avocado-without-extent.png Note both resulting images are empty. Open the files in usdview to see that they are visible (albeit small - but both the same small). This file also already renders empty and has extents authored (direct export from Blender): sphere.usda.zip <https://github.com/PixarAnimationStudios/OpenUSD/files/12207291/sphere.usda.zip> System Information (OS, Hardware) Both Windows 11 and M2 MacBook Pro — Reply to this email directly, view it on GitHub <#2556>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM2AOWAYZT4T2UANZKLSILXSUH3RANCNFSM6AAAAAA24QQPKE>. You are receiving this because you are subscribed to this thread.

[hybridherbst]

Thanks for the feedback. My particular case here is visually verifying that USDZ files have the expected content (for e.g. https://asset-explorer.needle.tools/Avocado) - my hope was that the assumptions from "usdview has similar output to usdrecord" hold, and/or that there's a default logic to make sure files have ok clipping and so on.

That being said, happy to try your suggestion – do you happen to have an example file with such a DomeLight setup at hand? My understanding would be that I can have a "wrapper.usda" that has DomeLight + camera and then loads the "Converted.usdz" into it. Is that correct?

[drwave]

On Jul 31, 2023, at 10:30 AM, hybridherbst ***@***.***> wrote: Thanks for the feedback. My particular case here is visually verifying that USDZ files have the expected content (for e.g. https://asset-explorer.needle.tools/Avocado) - my hope was that the assumptions from "usdview has similar output to usdrecord" hold, and/or that there's a default logic to make sure files have ok clipping and so on. That being said, happy to try your suggestion – do you happen to have an example file with such a DomeLight setup at hand? My understanding would be that I can have a "wrapper.usda" that has DomeLight + camera and then loads the "Converted.usdz" into it. Is that correct?

Sure. Given the existence of a model “Foo.usd” and the following “Foo_Cameras.usda” file, call usdrecord thusly: # make thumbnail: usdrecord --frames 0:0 --camera TiltedDown --imageWidth 2048 --renderer Metal Foo_Cameras.usda “renders/Foo.#.png” 

…

— Reply to this email directly, view it on GitHub <#2556 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM2AOXS2XDRF6TANCETKZDXS7TRZANCNFSM6AAAAAA24QQPKE>. You are receiving this because you commented.

[drwave]

And I believe the PR got merged that has:

…

--domeLightCameraVisibility Show the dome light background in the rendered output. If this option is not included and there is a dome light in the stage, the IBL from it will be used but the background will be transparent.

On Jul 31, 2023, at 10:40 AM, Michael B. Johnson ***@***.***> wrote: > On Jul 31, 2023, at 10:30 AM, hybridherbst ***@***.***> wrote: > > > Thanks for the feedback. My particular case here is visually verifying that USDZ files have the expected content (for e.g. https://asset-explorer.needle.tools/Avocado) - my hope was that the assumptions from "usdview has similar output to usdrecord" hold, and/or that there's a default logic to make sure files have ok clipping and so on. > > That being said, happy to try your suggestion – do you happen to have an example file with such a DomeLight setup at hand? My understanding would be that I can have a "wrapper.usda" that has DomeLight + camera and then loads the "Converted.usdz" into it. Is that correct? > Sure. Given the existence of a model “Foo.usd” and the following “Foo_Cameras.usda” file, call usdrecord thusly: # make thumbnail: usdrecord --frames 0:0 --camera TiltedDown --imageWidth 2048 --renderer Metal Foo_Cameras.usda “renders/Foo.#.png” <Foo_Cameras.usda> > — > Reply to this email directly, view it on GitHub <#2556 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM2AOXS2XDRF6TANCETKZDXS7TRZANCNFSM6AAAAAA24QQPKE>. > You are receiving this because you commented. >

[drwave]

Actually, I don’t think that’s been merged. Sorry about that. I will try and dig it up...

…

On Jul 31, 2023, at 10:41 AM, Michael B. Johnson ***@***.***> wrote: And I believe the PR got merged that has: --domeLightCameraVisibility Show the dome light background in the rendered output. If this option is not included and there is a dome light in the stage, the IBL from it will be used but the background will be transparent. > On Jul 31, 2023, at 10:40 AM, Michael B. Johnson ***@***.***> wrote: > > > >> On Jul 31, 2023, at 10:30 AM, hybridherbst ***@***.***> wrote: >> >> >> Thanks for the feedback. My particular case here is visually verifying that USDZ files have the expected content (for e.g. https://asset-explorer.needle.tools/Avocado) - my hope was that the assumptions from "usdview has similar output to usdrecord" hold, and/or that there's a default logic to make sure files have ok clipping and so on. >> >> That being said, happy to try your suggestion – do you happen to have an example file with such a DomeLight setup at hand? My understanding would be that I can have a "wrapper.usda" that has DomeLight + camera and then loads the "Converted.usdz" into it. Is that correct? >> > > Sure. > > Given the existence of a model “Foo.usd” and the following “Foo_Cameras.usda” file, call usdrecord thusly: > > # make thumbnail: > usdrecord --frames 0:0 --camera TiltedDown --imageWidth 2048 --renderer Metal Foo_Cameras.usda “renders/Foo.#.png” > > <Foo_Cameras.usda> > >> — >> Reply to this email directly, view it on GitHub <#2556 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM2AOXS2XDRF6TANCETKZDXS7TRZANCNFSM6AAAAAA24QQPKE>. >> You are receiving this because you commented. >> >

[drwave]

So the PR I was thinking of was this: #2123 Which is the necessary plumbing to expose toggling the display of the HDRI sky dome on/off, and that was pulled in a while ago. Unfortunately, it doesn’t contain the code to plumb it down to usdrecord. I will look around and see if we can get that submitted. Sorry for the confusion.

…

On Jul 31, 2023, at 10:42 AM, Michael B. Johnson ***@***.***> wrote: Actually, I don’t think that’s been merged. Sorry about that. I will try and dig it up... > On Jul 31, 2023, at 10:41 AM, Michael B. Johnson ***@***.***> wrote: > > And I believe the PR got merged that has: > > --domeLightCameraVisibility > Show the dome light background in the rendered output. > If this option is not included and there is a dome > light in the stage, the IBL from it will be used but > the background will be transparent. > > >> On Jul 31, 2023, at 10:40 AM, Michael B. Johnson ***@***.***> wrote: >> >> >> >>> On Jul 31, 2023, at 10:30 AM, hybridherbst ***@***.***> wrote: >>> >>> >>> Thanks for the feedback. My particular case here is visually verifying that USDZ files have the expected content (for e.g. https://asset-explorer.needle.tools/Avocado) - my hope was that the assumptions from "usdview has similar output to usdrecord" hold, and/or that there's a default logic to make sure files have ok clipping and so on. >>> >>> That being said, happy to try your suggestion – do you happen to have an example file with such a DomeLight setup at hand? My understanding would be that I can have a "wrapper.usda" that has DomeLight + camera and then loads the "Converted.usdz" into it. Is that correct? >>> >> >> Sure. >> >> Given the existence of a model “Foo.usd” and the following “Foo_Cameras.usda” file, call usdrecord thusly: >> >> # make thumbnail: >> usdrecord --frames 0:0 --camera TiltedDown --imageWidth 2048 --renderer Metal Foo_Cameras.usda “renders/Foo.#.png” >> >> <Foo_Cameras.usda> >> >>> — >>> Reply to this email directly, view it on GitHub <#2556 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM2AOXS2XDRF6TANCETKZDXS7TRZANCNFSM6AAAAAA24QQPKE>. >>> You are receiving this because you commented. >>> >> >

[spiffmon]

Thanks, @drwave ! I do feel like usdrecord should minimally ensure the near clip it picks is free of the extent of the root bbox, even if it cannot optimize depth-buffer use. For @hybridherbst 's and others' use case for any asset out there, I don't think any preconfigured camera can work equally for both yup and zup assets or large/small assets?

[drwave]

On Jul 31, 2023, at 1:59 PM, F. Sebastian (spiff) Grassia ***@***.***> wrote: Thanks, @drwave <https://github.com/drwave> ! I do feel like usdrecord should minimally ensure the near clip it picks is free of the extent of the root bbox, even if it cannot optimize depth-buffer use. For @hybridherbst <https://github.com/hybridherbst> 's and others' use case for any asset out there, I don't think any preconfigured camera can work equally for both yup and zup assets or large/small assets?

Agreed. I was just giving an example of how it works in my pipeline to generate thumbnail/cards/turntable via usdrecord - we have a script that picks whatever lens/position combo you want and author a specific camera that embodies that and pass that in. And yes, I do sincerely wish usdrecord always picked a reasonable default to give you an unclipped image.

…

— Reply to this email directly, view it on GitHub <#2556 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM2AORTRHI3Y2RTRU5W5VLXTAMBRANCNFSM6AAAAAA24QQPKE>. You are receiving this because you were mentioned.