Hi everyone,
I’m curious if there’s a method for consolidating a USD file along with its textures into a single file, perhaps using a 2D array format for the textures.
Best regards
Hi @GiangNguyen
So this is what a USDZ file is meant for. It packages up everything inside a single uncompressed zip file while still being able to be used by USD
But I want to store it as text for future data transformation purposes. As an illustration, I am currently developing a USD viewer in JavaScript and obtaining USD data from an external source, such as a REST API. To achieve this, I require the texture data in textual format.
I don’t understand - why does the fact that you’re implementing a REST API mean you require your textures to be text encoded? Binary image data, like jpgs or pngs, are sent over http + REST apis all the time. Why does your use case require everything to be text?
1 Like
Because receiving binary image data will require additional storage and data management process.
I’ll just add that developing a system that requires USD data to be encoded in its text form runs counter to the spirit and practical reasons why people use USD, and will lead to scaling problems in the long run. Are you aware of the USD/WASM work that some members of this community have been working on?
@GiangNguyen I’m not sure your assertion that it needs to be text encoded is correct.
Would you be able to go into more detail as to why you need it to be text?
Certainly, it is not a requirement for web and REST systems. JavaScript etc are also quite capable of receiving binary encoded files.
Generally no image decoder will render a text encoding of an image without having it be transmuted to binary data first. In which case it would make more sense to transfer it as binary first.
I acknowledge that relying on textual encoding for USD data may not be the most efficient approach. However, my need for a software solution that can both visualize USD scenes in a web browser, akin to usd-viewer, and dynamically manipulate USD data during runtime, akin to Omniverse, has led me to explore various options. Unfortunately, I have yet to find a stable library that fulfills all these requirements. Therefore, I’ve opted to develop a basic implementation at a low level until more suitable solutions become available, ideally including a JavaScript USD reader library similar to those found in Python.
will lead to scaling problems in the long run.
Regarding concerns about scalability, I fully acknowledge the potential for challenges in the long term. My current focus, however, is on short-term functionality to meet my immediate needs. If you’re aware of any resources or developments that could assist me in this endeavor, I would greatly appreciate your insights.
I appreciate your response. It’s possible my initial question didn’t fully convey my intentions. I’m in the process of creating a web-based tool aimed at visualizing and editing USD scenes Multiverse-View. This tool will eventually integrate with other software I’m developing, necessitating a REST API for getting and receiving scene. As mentioned above, I’ve encountered difficulties finding suitable existing software to meet my needs. Consequently, I’ve chosen to develop a basic solution at a low level, focusing on handling flattened USD files, until a more optimal solution emerges.
I would like to ask again: Why is mesh data in USD stored explicitly as points, normals, and faces, without needing to be linked to an external file like OBJ or STL, while texture data must be linked to an image file like PNG or JPG? Is it possible to store texture data directly in USD, similar to how mesh data is handled?
Images tend to have a wide range of compression schemes that map to different use cases.
There’s no single encoding that would make sense for inclusion inside a USD document. It also would not make sense for USD to duplicate the work of well established formats.
If you really wanted to , you could create a uchar and just store the bytes of an image in there, but that’s effectively the same as just putting it in a usdz.
I am still unsure why you can’t use a USDZ file or just have the external reference to an image file. Both are well established patterns for web use , independently of USD. I feel like you may be making things harder for yourself by going against the existing patterns.
Thank you for your response. I understand that if this is the way to handle USDZ, I will give it a try. My concern with zipping USDZ files is that I have to manually gather all textures and USD files into a folder before zipping. My environments are tightly integrated with many other files—such as 100 meshes and 1000 textures, with each mesh linked to specific textures. If I want to zip a mesh, I have to filter out the related textures; otherwise, zipping everything would result in a file that’s too large and redundant. Could you share some useful tips for managing USDZ files more efficiently?
The usdzip command is non-recursive by default and wants an explicit list of input files. So it should be straightforward to zip only a subset of the files in your existing directory structure.
Per USD Toolset — Universal Scene Description 24.08 documentation, using the “-a ASSET” argument, where ASSET is the root layer of the usd you want to package, the program will itself discover and package all and only the (recursive through composition arcs) asset’s dependencies into the zip file.
1 Like