No cameras found in the USD file - Karma rendering

   8346   23   4
User Avatar
Member
141 posts
Joined: Dec. 2015
Offline
Hey guys,

I have a scene, I have camera, the viewport render is done using the camera. However, when I try to render to Disk or to MPlay, I always get the error:
No cameras found in the USD file

I tried everything...I cannot submit the hiplc file, it's a huge simulation data, etc.
User Avatar
Staff
4438 posts
Joined: July 2005
Offline
I'm sure the amount of data isn't relevant, so maybe you could trim out the large data and submit a smaller file that demonstrates the problem? One way to remove data from a USD file is to use a Configure Stage LOP after your Sublayer LOP to isolate the parts of the scene you want to keep, then save it out with a USD ROP set to "flatten stage". It should be easy to validate that you've kept the parts you want using the scene graph tree. Then feed this new smaller USD file into your hip file and if it still demonstrates the same behavior submit it to support.
User Avatar
Member
171 posts
Joined: Nov. 2013
Offline
Make sure you're using a Render Product and that your Render Settings are pointing to it (and make sure both are pointing to the correct camera).
User Avatar
Member
141 posts
Joined: Dec. 2015
Offline
mtucker
I'm sure the amount of data isn't relevant, so maybe you could trim out the large data and submit a smaller file that demonstrates the problem? One way to remove data from a USD file is to use a Configure Stage LOP after your Sublayer LOP to isolate the parts of the scene you want to keep, then save it out with a USD ROP set to "flatten stage". It should be easy to validate that you've kept the parts you want using the scene graph tree. Then feed this new smaller USD file into your hip file and if it still demonstrates the same behavior submit it to support.

Thanks! I'm super rookie with Solaris, I just assemble scene for rendering, but I figured out what you said, and exported an USD ascii file. I checked it, and found the camera definition, so I really don't get, what's going on...Fun fact, it works in the viewport (renders using the camera) but if I want to Render to Disk or MPlay or Background, it fails...

I do appreciate all help guys, I need to finish this image in the weekend for my client.

Attachments:
Poseidon.usd_rop1.usda (456.9 KB)

User Avatar
Member
12467 posts
Joined: July 2005
Offline
I think some interactive workflows will just use the first camera found if there is no good camera specified, but offline tenders are more careful (strict).
Edited by jason_iversen - Nov. 15, 2021 12:52:24
Jason Iversen, Technology Supervisor & FX Pipeline/R+D Lead @ Weta FX
also, http://www.odforce.net [www.odforce.net]
User Avatar
Member
141 posts
Joined: Dec. 2015
Offline
But what qualifies as a good camera? I've set it up properly, in my other scenes it works, only this scene screws it up...
User Avatar
Member
647 posts
Joined: Aug. 2013
Offline
Hi. I am having odd issues rendering cameras in the latest builds. Although karma has the camera set, it keeps randomly switching to other cameras when rendering to disk. I'm not sure if you are having the same issue. I have submitted a bug. If I here anything I will let you know. Best.
User Avatar
Member
12467 posts
Joined: July 2005
Offline
szmatefy
But what qualifies as a good camera? I've set it up properly, in my other scenes it works, only this scene screws it up...
Perhaps in this scene the camera is deactivated or something?

> usdtree /usr/tmp/bar.usd --flatten --mask /cameras/camera1
/
 `--cameras [def Xform]
     `--camera1 [def Camera] (active = false)
Jason Iversen, Technology Supervisor & FX Pipeline/R+D Lead @ Weta FX
also, http://www.odforce.net [www.odforce.net]
User Avatar
Staff
4438 posts
Joined: July 2005
Offline
Attached is a hip file that loads your usda file, adds a cube (because the usda has co geometry so there's nothing to see), and lets you either output the combined usda file or render an image directly. Both approaches work fine without any complaints about the camera for me. Can you post a hip file to go along with your USD file to demonstrate the issue?

Attachments:
cube.hip (94.7 KB)

User Avatar
Member
141 posts
Joined: Dec. 2015
Offline
jason_iversen
szmatefy
But what qualifies as a good camera? I've set it up properly, in my other scenes it works, only this scene screws it up...
Perhaps in this scene the camera is deactivated or something?

> usdtree /usr/tmp/bar.usd --flatten --mask /cameras/camera1
/
 `--cameras [def Xform]
     `--camera1 [def Camera] (active = false)

Camera is active in the Scene graph...
User Avatar
Member
12467 posts
Joined: July 2005
Offline
szmatefy
Camera is active in the Scene graph...
Ok that was just a guess in absence of any real information... just follow what Mark suggest then
Jason Iversen, Technology Supervisor & FX Pipeline/R+D Lead @ Weta FX
also, http://www.odforce.net [www.odforce.net]
User Avatar
Member
141 posts
Joined: Dec. 2015
Offline
So, the fun begins.

I started to remove the objects one by one and started background rendering. So, the issue is, if I add the whitewater import, camera fails...Without it, it works.
User Avatar
Member
41 posts
Joined: March 2018
Offline
I've got exactly the same issue

19 and WW not friends yet?????
User Avatar
Member
12467 posts
Joined: July 2005
Offline
I very quickly tried this with the Beach Tank shelf tool and also got the same behaviour. It appears that the Karma ROP's LOP subnet is importing cameras to /camerabut the Karma LOP is trying to render with (pluralized) /cameras/*, which looks like a bug in the Karma ROP setup. I think the "fallback to the first camera in the file" is always kicking in. That's A problem, but not THE problem, though...

I didn't get to the bottom of why playing with the toggling the whitewater_importcauses husk to complain suddenly about the missing camera. When looking at the USD if I set the USD Output Directory and then usdview/usdtree -f the RENDER.usd, I see that it just doesn't contain all the prims it should. Perhaps the USD generation is silently failing on outputting the whitewater VDBs? This results in the camera just not being in there, so there is no camera for husk to fall back on. As well as the issue itself, it points maybe to a lack of catching an error during USD output?

Anyhow, an easy repro for SideFX, at least.
Edited by jason_iversen - Nov. 18, 2021 01:52:45
Jason Iversen, Technology Supervisor & FX Pipeline/R+D Lead @ Weta FX
also, http://www.odforce.net [www.odforce.net]
User Avatar
Staff
451 posts
Joined: June 2020
Offline
jason_iversen
I very quickly tried this with the Beach Tank shelf tool and also got the same behaviour.

Interesting. It looks like there's a conflict for the name "render". The whitewater_import node ends with a "render" SOP and ends up generating render.usd ... then the "main" USD ends up as "render2.usd". If you rename the SOP in the whitewater_import to "render_null" (or anything different) then "render.usd" will be used for the "main" USD again (with the camera).

I'll look into a better fix, but hopefully this keeps your project moving forward for the time being!

- Rob
User Avatar
Member
7770 posts
Joined: Sept. 2011
Offline
robp_sidefx
jason_iversen
I very quickly tried this with the Beach Tank shelf tool and also got the same behaviour.

Interesting. It looks like there's a conflict for the name "render". The whitewater_import node ends with a "render" SOP and ends up generating render.usd ... then the "main" USD ends up as "render2.usd". If you rename the SOP in the whitewater_import to "render_null" (or anything different) then "render.usd" will be used for the "main" USD again (with the camera).

I'll look into a better fix, but hopefully this keeps your project moving forward for the time being!

- Rob

why do the layers from the usdrender node endup in a flattened folder structure instead of in node paths, i.e. {usdroot}/obj/geo1/sopname.usd
this is how they write out of the usd rop.
User Avatar
Staff
451 posts
Joined: June 2020
Offline
jsmack
why do the layers from the usdrender node endup in a flattened folder structure instead of in node paths, i.e. {usdroot}/obj/geo1/sopname.usd
this is how they write out of the usd rop.

The USD Render ROP LOP internally uses the "savetodirectory" output processor so that all the files are self-contained within a given directory for rendering. You can reproduce the same behaviour in the USD ROP LOP by enabling the output processor there too.

Perhaps this processor shouldn't strip directory structure and instead be a "reparenting" operation (i.e., a file that would have been /path/to/asset.usd would go to /render/path/to/asset.usd instead of /render/asset.usd). I'll need to dig into the history and motivation for its current design a bit more.
User Avatar
Member
141 posts
Joined: Dec. 2015
Offline
Thanks you guys, I'll then report it to SideFX, maybe they can help!
User Avatar
Member
12467 posts
Joined: July 2005
Offline
szmatefy
Thanks you guys, I'll then report it to SideFX, maybe they can help!
Too late! robp_sidefx (above) is SideFX Staff
Jason Iversen, Technology Supervisor & FX Pipeline/R+D Lead @ Weta FX
also, http://www.odforce.net [www.odforce.net]
User Avatar
Member
141 posts
Joined: Dec. 2015
Offline
So, I found a solution.

The problem is, that Whitewater import has a null set on RENDER flag. I had to set the previous SOP node as DISPLAY node to prevent the error message. Now it renders fine!
  • Quick Links