Exported glTF has incorrect materials and lights

When exporting the Astronaut sample asset to glTF, the resulting asset ends up with missing metallic surfaces (e.g. the helmet isn’t metallic anymore) and what seems like incorrect conversion from some PBR metallic-roughness surfaces (gloves become too shiny, metal parts on suit become not shiny enough, etc.)

Additionally, it seems that the Dome Light is exported as a Spot Light looking up, which feels weird – I think a directional light would be more appropriate (or not exporting dome lights at all):

Tested a bit more: looks like almost all metallic/rough parts are incorrect in one way or another (too shiny, not enough metallic, …)

The support for gITF is still in continuous development and we are working to improve the importing and exporting. The dome lights being exported in this way obviously needs some work. If you delete it and re-light it, it should look a lot better, but I will pass this along as a problem. As for the look for each individual texture and shader, support for this is still an ongoing effort to get as close as possible from Create to gITF.

Where are these issues documented / where can I follow along with the development?

I haven’t found anything regarding “don’t use glTF export yet, it’s broken” in the docs or changelog, that all is phrased rather like everything would work.

Please also see

and

for cases where the export doesn’t work either (in some cases completely not – the Astronaut scene at least exports something).

Yes thank you. This all falls under the same gITF issues that we are aware of

@herbst : Thank you for reporting these issues. In order to help prioritize import/export work it would help to share any additional information on what you are trying to accomplish. Are you blocked by any specific defect that we could help unblock? Thanks!

1 Like

Here’s a page with some asset conversion limitations listed:
https://docs.omniverse.nvidia.com/prod_extensions/prod_extensions/ext_asset-converter.html

1 Like

Thanks @agrant3d for the link. This page doesn’t contain any of the limitations/bugs I listed above as far as I can see; the only limitation related to glTF there is “It does not support recursive skeleton for glTF”.

Regarding needed features: I was testing the Omniverse glTF export in general to understand better how it would fit into overall production pipelines (including mobile realtime usecases, which are outside of Omniverse’s targets as far as I’m aware). So what I did was just open the various sample scenes and export them to glTF, with the assumption that probably developers would have done the same. This was a preparation step for testing our own models and other usecases - so far I’d say it’s not ready, and we’re probably better off exporting the USD and converting elsewhere (e.g. in Blender).

The base expectation would be that typical commerce and architecture models - so, just regular non-animated PBR models with metallic, roughness, color, normals - would roundtrip correctly. Basically the parts of UsdPreviewSurface that map to the glTF PBR model.

From testing the samples, this would be a rough order of priority:

  • maybe the biggest issue, some textures are downright not exported at all (e.g. my report from the Marbles samples scene, where almost no assets export with any textures)
  • PBR doesn’t quite work, lots of metallic/roughness pieces are incorrect
  • face orientation is sometimes flipped, which is a “catastrophic” defect in terms of pipeline as it changes the appearance of a model drastically

@herbst : This is really helpful - thank you for taking the time to share.

This was a preparation step for testing our own models …

When you say your own models, do you mean models which are under your control and have specific structure? I ask because addressing export issues of our sample assets may not be nearly as helpful as addressing specific needs for exporting your own assets. If they are all third-party then maybe this doesn’t matter so much.

I mean general models, it’s rare that asset pipelines are 100% under one’s control these days…

We are of course trying to always figure out the “safe subset” of specific software’s implementations, but with the current issues I’m not sure what the safe subset for Omniverse would be - would have to run way more tests to understand “this is the arcane way we have to prepare glTF or USD assets so that they import and export correctly in Omniverse”.

I’ll hold off from that for a while given the issues encountered so far, but very happy to try again in the future! As said if even PBR models don’t export correctly I’m not sure what the safe set to use would be right now.

Here’s some pointers for test assets, I’m sure you’re probably aware but can’t hurt:

I haven’t tested these exhaustively with Omniverse.

@herbst : Thank you.

The Marbles content, unfortunately, has material and other issues that need to be fixed on the content side. Perhaps the exporter can be improved so that those assets export textures+materials correctly - but they are not a very good representation of what you might see if you were to export assets from NVIDIA Assets browser - which are newer and well-formed.

In any case - I’ll be taking a hard look at the import/export workflows. All your feedback is valuable and appreciated!

-Andrew

1 Like

From my experience “well-formed” assets are the exception, not the norm, even under very controlled pipelines :) so testing these is a better indicator than testing that one well-prepared asset.

Thanks! Looking forward to updates on that end. @agrant3d Feel free to DM me; I’m also in the USD Slack and other places.

Totally! Some assets are just too far gone - these are using what I believe is a legacy MDL schema which might not be reasonably supported (i.e. should be deprecated instead).

1 Like