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 https://github.com/PixarAnimationStudios/OpenUSD/issues/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 https://github.com/PixarAnimationStudios/OpenUSD/issues/2556#issuecomment-1658843850, 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”

> — > Reply to this email directly, view it on GitHub , or unsubscribe . > 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”

> — > Reply to this email directly, view it on GitHub , or unsubscribe . > You are receiving this because you commented. >

[drwave]

So the PR I was thinking of was this:

https://github.com/PixarAnimationStudios/OpenUSD/pull/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”

> — > Reply to this email directly, view it on GitHub , or unsubscribe . > 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 https://github.com/PixarAnimationStudios/OpenUSD/issues/2556#issuecomment-1659152388, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAM2AORTRHI3Y2RTRU5W5VLXTAMBRANCNFSM6AAAAAA24QQPKE. You are receiving this because you were mentioned.