Excuse my naivety, but has anybody attempted a JSON serialization of USD or has some insights in why it’s not attempted yet? From a distance its seems like a reasonable fit and would enable the consumption of USD data on a much wider variety of platforms.
That’s an interesting question! Since json can encode anything, more or less 
, it seems reasonable. Json lacks however many formal concepts like layering and so on, that you would encounter very quickly. Little by little, you would probably identify a restricted subset that fits well with json, and it would most likely be very similar to glTF, and you would face the same interesting challenges glTF does as they investigate aspects of layering for glTF.
To that end, the MSF has a USD-glTF interop working group working on those problems, so I would hazard an opinion that that group is actively working on the problem, if you follow my logic 
To add to what @nporcino said, yes the encoding of USD data would fit reasonably well in json, but the thing that makes USD so attractive and powerful for world-building are the rich behaviors that the data encodes (many of them fall under the “scene composition” rubric, layering, as Nick mentioned, being the most basic one). Those behaviors are quite involved, and would be quite difficult for someone to get right on their own, currently.
Rather than trying to come up with a really restricted subset that “should be easy enough” for anyone to implement, the AOUSD is working to come up with a full formal specification of USD, at which point it would be somewhat more tractable for someone to create an alternate implementation of OpenUSD. If there were energy around a json encoding, we would want to align on one and ensure that OpenUSD itself can read it, e.g. .usdj files, rather than any old .json file that can encode anything.
1 Like
Dear both, thanks for the insightful answers. I agree. I also see a clear separation between “serialization” and “behaviour”. I was specifically only talking about serialization, but you read my intentions well, the thing I’m actually most interested in is the behaviour.
I’m in the BIM sector and we struggle with collaborative and incremental exchanges for which USD indeed has a powerful solution. But at the same time, the construction industry is much more fragmented and neutrality of the spec is crucial, where USD as a platform is a bit difficult due to limited portability of a huge code base.
The work towards an ISO ratified publication of the spec already goes a long way in our sector (we deal a lot with governments). But for a longer term alignment between BIM and USD I would have some hope for (a) a more general serialization format of USD in JSON and maybe (b) the ability to specify implementation profiles so that some of the VFX-specific features such as time variability can be left out.
I plan to do a quick usda to json conversion and then see if I can do a very naive composition of a couple of these “.usdj” layers in a custom implementation. To get a sense of what this all means.
1 Like
If you really want this, I think the best way to go would be to implement a custom SdfFileFormat plugin. It should be relatively straightforward, once you figure out the particulars of building USD and how to implement USD plugins in general.
I think some people might be talking about how USD relates to IFC, as a specific topic to begin exploring, although I am guessing about that, a little. I was wondering if you are looking at the same domain as is covered by IFC?
usda to json conversion and file format plugins are some ways to explore the possibilities, but I definitely want to echo @nporcino and @spiff 's sentiments that the choice of how to represent the full complement of low-level USD metadata fields (i.e., its document model in SdfSchema) in json would need to go through review in AOUSD and MSF to avoid ending up with json that is readable in some USD clients but not others.
The AOUSD Core Spec draft currently does have sections specifying the USD document model agnostic of any serialization, as well as how it surfaces in USDA, USDC, and USDZ.
We do have AECO members in AOUSD, and are working on setting up an interest group to discuss topics such as BIM-- stay tuned.
Thanks all for pitching in. Yes it is IFC I’m interested in in particular. (As a maintainer an open source toolkit for IFC for over 12y I have a bit of a love-hate relationship with it).
I’ve made some progress along the lines I set out initially. I have a repo [0] with a transformation script and a JS reader (which doesn’t yet touch upon the interesting composition features somewhat ironically).
I agree, this is in no way an attempt at proposing a direction. This is a throwaway prototype for myself to answer the question: “what could USD as a ‘serialization’ mechanism for IFC in an implementation-neutral context look like?”.
[0] GitHub - aothms/ifc-usdj: .usda to json transformer and ThreeJS-based visualizer