<div dir="ltr"><div dir="ltr">For the same .blend file, the USD-A export was 2 orders of magnitude greater in file size than x3d and x3dv.  I ran out of disk space and got stuck at 99% in the Blender export and had to kill the Blender process.<div><br></div><div>So if you actually want to edit your file after export, X3D remains a big win for its smaller file size.  glTF is gobbledegook for hand editing, AFAICT, it's designed for performance. Tools like VS Code do not even let you jump to an indexed array element in glTF, AFAIK. USD is not designed for real-time.  I don't recommend going from glTF to X3D unless you have to.</div><div><br></div><div>So I think the approach should be X3D to glTF for performance and disk space.  I believe Vince has a handy program for this, at least for some use cases.</div><div><br></div><div>At this time, X3DJSONLD supports JSON to DOM, so X3D JSON is not really a performance win over XML.  I'm open to people who are willing to push X3D JSON forward for native support without DOM.  In particular, I could use help with X3D JSON conversion directly to a scenegraph, with X3DJSAIL, X3DPSAIL (any encoding would be great), and browsers being candidates. I don't plan on inventing my own scenegraph.  These conversions would be maintained by someone else, not me.  I will continue supporting X3DJSONLD as I can, but there are versions of X3DJSONLD for X3DJSAIL, X3DOM and X_ITE (Sunrize) which either are maintained or could be maintained by those parties.  So someone stepping up to tell me about how DOM works with Pascal would be cool, or someone who wants to integrate X3DJSONLD.cpp in their browser, speak up and participate.  For example: <a href="https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/cplusplus/src/X3DJSONLD.cpp">https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/cplusplus/src/X3DJSONLD.cpp</a> has been languishing in a backwater. I don't really want to go down either the C++ or Pascal rabbit hole and I'm nowhere close to being trained in advanced C++ or Pascal. So a trade-off:  I do work on Blender import/export for X3D, and you guys support X3D JSON better.</div><div><br></div><div>The secret to getting a USD ASCII file out of Blender is to ensure you've got .usda as the file extension.  Do your own comparisons.</div><div><br></div><div>From what I saw of the USD-A, it has a lot of cruft, commas, parentheses, brackets, colons, etc.  So perhaps for debugging purposes, one would want to go from X3D to USD.  If you want an archival format that doesn't take a ton of disk space, choose X3D.  It did look like there were indexes next to coordinates, but what about coordinate reuse?</div><div><br></div><div>I couldn't even find "knee" in the USD-A output, so USD-A is not really an understandable HAnim target.  I realize that MSF has other avatar formats, but I think they're refocusing on .glb. HAnim and X3D are designed to work together.</div><div><br></div><div>Let me know if there's a middle ground where there's less verbose USD encoding that's still readable.</div><div><br></div><div>Of course, industry wants you to buy multi-terabyte disks!  Who doesn't want a 100 TB disk for all their movies?</div><div><br></div><div>I'm hoping we can provide better Blender skeleton importers than FBX and USD!  AFAIK, their animations are OK in Blender.  We already have experience converting HAnim to python.</div><div><br></div><div>Go X3D!</div><div><br></div><div>John</div></div></div>