Hi all,
I’ve been looking into how the USDC file-format handles reads/writes and found that the USDC_USE_ASSET environment variable, which would make the USDC format work nicely with the AR 2 system, is disabled by default. There are some commit comments:
The new testUsdFileFormats_asset test exposed a pre-existing issue with saving .usdc files when
using the ArAsset-based codepath and an ArFilesystemAsset to read .usdc files on Windows. This
codepath isn't typically used; it's meant to handle non-file backed .usdc assets so we hadn't seen
it until now. The test is disabled for now while we look into a fix.
Doe anyone have any further info or experience on how safe it is to use this environment variable on Windows or an alternative approach to making USDC work with AR2?
Hi @alasdairhitchen , AFAICT, we dropped the ball here and did not follow through with the investigation. Could I ask you to file a GitHub Issue that we’ll use to schedule the work? We definitely want to get Ar 2 enabled for crate files…
During the initial development of our Ar 2.0 implementation in Omniverse we experimented with USDC_USE_ASSET briefly. It seemed unstable at the time and since it was considered an experimental feature we kept it as it’s default value. At the moment, we need to download the entire asset to a file on disk which can then be memory mapped for USDC.
But there has been growing interest to read directly from ArAsset in our Ar 2.0 implementation. This would help enable streaming reads on the client and could reduce time spent downloading the entire asset