Reducing distribution size of the plugin resource folder

[andrewkaufman]

Description of Issue

In the ASWF wg-usd meeting, we discussed the required runtime distro size of USD (e.g. relative to a game runtime).

It was brought up that the size of dynamic libraries will come down significantly in v24.11+ due to removal of boost. After this, I suspect the size of the plugin resources will be a significant factor on the remaining distro.

I wonder if we can find ways to reduce this, in terms of file count, total file size, and speed to load at runtime.

For example, some ideas discussed in the meeting:

• Are both the generatedSchema.usda and schema.usda required for a runtime?
  • If not, can they be removed (perhaps via a build flag)?
  • If so, could they be somehow embedded into the dynamic library or otherwise combined into a single file?
• Can the description text be removed or reduced?
  • It was mentioned that some of it is useful for e.g. DCC (or Game Engine Editor) tooltips, while others are better suited to the online docs. Can we strip out the later while keeping the former?
• Can the resource usda layers become usdc?
• Can all the "default" resource layers be combined into a single usd?
  • Or at least fewer than 82 directories, 120 files?

[lbiasco-sie]

Are the generatedSchema.usda required for a runtime? If not, can they be removed via a build flag?

They are required for runtime, at least the schemas need to get registered somehow. Besides some framework libraries, I believe the ones under base, the majority of "core" USD libraries are actually plugins.

Can the description text be removed or reduced?

I'm curious, how much is this a problem if generatedSchema.usda is saved as a USDC? A lot of the descriptions are duplicated because they come with inherited properties, so if crate deduplicates strings (that's where I'm unclear if it does or not) then this could become less of an issue.

[andrewkaufman]

Are the generatedSchema.usda required for a runtime

Appologies, I didn't write exactly what I meant the first time around. I've updated the description (though it may still be a no-go).

How much is this a problem if generatedSchema.usda is saved as a USDC

Just experimenting with usdGeom USDC does seem to help:

$ du -h usdGeomOrig/
132K    usdGeomOrig/resources/usdGeom
392K    usdGeomOrig/resources
396K    usdGeomOrig/

$ du -h usdGeomCrate/
68K usdGeomCrate/resources/usdGeom
148K    usdGeomCrate/resources
152K    usdGeomCrate/

Removing the resources/usdGeom/schema.usda and stripping the doc strings from generatedSchema.usda helps more:

$ du -h usdGeomGenOnlyNoDocs
40K usdGeomGenOnlyNoDocs/resources
44K usdGeomGenOnlyNoDocs

And then crating that just a bit more

$ du -h usdGeomGenOnlyNoDocsCrate
28K usdGeomGenOnlyNoDocsCrate/resources
32K usdGeomGenOnlyNoDocsCrate

[jesschimein]

Filed as internal issue #USD-10294

[spiffmon]

We experimented with usdc for generatedSchemas awhile back, and while they are smaller, it degraded UsdSchemaRegistry initialization time, which we consider a top priority.

However, we are pursuing getting the developer documentation strings out of the generatedSchemas, ultimately to be replaced with just briefUserDoc strings, and we do expect this to help alot. Long form user-doc will still likely install with OpenUSD, but not be greedily read.