[x3d-public] Win goes to X3D. USD-A file 2 orders of magnitude larger than X3D/X3DV

[John Carlson]

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.

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.

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.

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:
https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/cplusplus/src/X3DJSONLD.cpp
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.

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.

>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?

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.

Let me know if there's a middle ground where there's less verbose USD
encoding that's still readable.

Of course, industry wants you to buy multi-terabyte disks!  Who doesn't
want a 100 TB disk for all their movies?

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.

Go X3D!

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20231204/1c1beaa2/attachment.html>