Hello, is there a plan to enable USDC_USE_ASSET by default for future releases? Currently this environment variable has to be set manually in order to use in-memory .usdc assets
Hi @chaitanya , that env var should not need to be set to true in order to read usdc files whose contents are in-memory, if your resolver provides a properly configured ArAsset for it.
Forcing that env var to true disables the very awesome “zero copy arrays” feature of usdc, and after work completed earlier this year to provide the behavior I described above, we left the env var in there primarily for testing purposes.
If you are seeing scenarios in 24.08+ where it seems to be required, please file an Issue?
I’m responding to the thread from Chaitanya, because we’re hitting an issue with this.
We’re trying to store a USDC layer in memory as an ArInMemoryAsset. We’d like to use the asset stream _AssetStream instead of the file mapper _MmapStream in crateFile.cpp because we’re not saving anything to disk. Memory mapping assumes that a file is saved on disk and we get a crash. The useMmap boolean is the thing that drives this and it only considers the USDC_USE_ASSET and USDC_USE_PREAD environment variables when it should check if a file pointer exists.
Our workaround is to set SDF_LAYER_INCLUDE_DETACHED to our layer id.
Can you tell us what goal you’re trying to achieve, @Fanny ? If it is that you want to keep a copy of the crate file in-memory to protect against the data changing out from under you due to another process modifying it, then “detached layers” is the suggested solution.
But if you’re trying to create an in-memory crate file with no connection to the filesystem, we’d ask why. It provides no performance benefit over the default usda-backed anonymous layers you get from Sdf, and is no-more directly Save’able to disk; in both cases, calling Export(“file.usd”) on the anonymous layer would export a usdc asset for you.
Cheers,
spiff
Hi Spiff, thank you for the quick answer. We were under the impression that writing to disk was much slower, but we’ll have to test this again if you’re saying there’s no performance downside.
Best
Fanny
Sorry, there might be some confusion… writing to disk is much slower, but creating an “ordinary”, usda-backed Anonymous layer (SdfLayer::CreateAnonymous()) will never perform any filesystem operations, unless you explicitly Export() it.