Open Asset Import Library (assimp) project has adopted TinyUSDZ

[tellypresence]

Open Asset Import Library (assimp) now using tinyusdz to load USD (.usd/.usda/.usdc/.usdz) model files.

Code can be viewed in (merged) PR 5628

Screenshots of loaded USD models can be viewed in issue 5547

Assimp can convert and export 3D models to a few different formats, so in theory it should be possible to load a USD model and convert and save a .gltf or .fbx format file.

Caveats

No support yet for

• USD model files using "Composition" (layered/hierarchical models) not supported yet
  • (this means many USD models encountered "in the wild" will fail to load)
• animation timings
• node-only (rigid) animations
• skinned (bones/skeletal) animations
• blend shapes

[syoyo]

Good!

[szellmann]

I'm hijacking the discussion, hope that's ok.

I also found out that ASSIMP only recently added support for USD files using TinyUSDZ; I was excited about that because I had hoped to be able to load this new asset in my ASSIMP-based app: https://github.com/Activision/caldera

Unfortunately this doesn't work out of the box; I debugged the ASSIMP loader a little, and saw that the CrateReader in TinyUSDZ only visits the uppermost transforms (when loading the hotel subset) when building the USDZ data structure. Here's the scene graph I finally see in my app, after it went through ASSIMP, but I think it already goes awry in CrateReader:

This is the scene graph hierarchy I see (underneath world); they're all Xform's. Adding a couple of prints:

in the CrateReader I see that those Xform's have properties, but no children, which is odd:

---geo <- name
---Xform <- typeName
---[] <- children
---["xformOp:translate", "xformOpOrder", "xformOp:rotateXYZ", "xformOp:scale"] <- properties

For example when looking at that file in Mac Preview, the hierarchy looks like this:

So the Xforms actually have content (children?) that I just don't see in TinyUSDZ

I wonder if that could be one of the "caveats" mentioned above. The only thing I can tell is that in the debugger the Crate reader doesn't traverse beyond the second-most top level.

I know all that's a little fuzzy; I'll poke around a little more, but thought I'd informally ask for an opinion here, as today's the first time I ever played with TinyUSDZ (and USD in general); so perhaps someone here here has an idea I might pursue to get me on track a little faster :-)

[syoyo]

This is a discussion forum for TinyUSDZ, not assimp.

You should first try tusdcat https://github.com/lighttransport/tinyusdz/tree/dev/examples/tusdcat and tydra_to_renderscene

https://github.com/lighttransport/tinyusdz/tree/dev/examples/tydra_to_renderscene

to dump the (parsed) USD scene that xform and other things are property handled in TinyUSDZ and Tydra

[szellmann]

Nice, that is helpful I'll give it a try. Sorry for starting a discussion on an external project, I only realized later that this might not be appropriate.

[syoyo]

Good! FYI If a scene contains timesampled xformOps, its not yet supported in Tydra(USD -> OpenGL/Vulkan friendly data structure converter).

tinyusdz/src/tydra/render-data.cc

Line 2308 in 7a6c9d9

nonstd::expected<Node, std::string> ConvertXform(const Stage &stage,

We'll need to supply timecode value to GetLocalMatrix API

tinyusdz/src/xform.hh

Line 192 in 7a6c9d9

nonstd::expected<value::matrix4d, std::string> GetLocalMatrix(double t = value::TimeCode::Default(), value::TimeSampleInterpolationType tinterp = value::TimeSampleInterpolationType::Linear, bool *resetTransformStack = nullptr) const {

to evaluate the xform value at the specified time. PR is much appreciated!

Further, you can use --dumpusd in tydra_to_renderscene example to dump Tydra-converted scene to USD. It can be read in Blender 4.1+. #148 (comment) This should help debugging!

[tellypresence]

@szellmann
Please feel free to raise an assimp issue with any questions or problems with the experimental USD support (although in this case, expect this is simply that the 3D model file in question is "layered" and not yet supported)