auto generated USDZ much darker

[maciekglowka]

Hi,

does anyone else has this problem that on-the-fly USDZ files are waay darker in Quick Look?
I always before had them slightly darker but it seems that now it got even more. (they are not really usable for product display:/)
It is not only the light estimation thing, as they appear dark on the non AR (model only) view in Quick Look.

I have found this thread about fixing this with adding a black metallic map (but might be obsolete)
https://developer.apple.com/forums/thread/116534

Has anyone tried that?

I have initially thought that it is not a model-viewer issue, but again I think the manually added usdzs through ios-src param seemed to have less problem with that.
I don't have an access to the ios device at the moment to do proper A/B testing with different usdz methods, but maybe somebody has some insights on that as well?

edit:
one more thought, I am often using vertex colors (AO baked to them) which now I read is not supported by Quick Look - might that be the issue?

[elalish]

one more thought, I am often using vertex colors (AO baked to them) which now I read is not supported by Quick Look - might that be the issue?

Very likely yes. The restrictions of Quick Look mean you have to be a bit careful about how you generate your models. In general, avoid anything fancy like multiple UV channels. Three.js is doing its best to support as much of the format as possible, but their's still work to be done. Any specific models you can upload with render comparisons will help us out!

[maciekglowka]

Thanks for the reply. I managed to do some cross - mode comparisons.
First of all - I was wrong about auto-generating. It made no difference whether I have specified ios-src with converted file or let it make usdz on the fly. It is just not as obvious on every model.

I have tried also with the black metallic texture - also no diff.

I didn't include WebXR screenshots as they would be similar to web embed.

Where there is no data in vertex colour it actually means that they are not set but exporeted (so default all white I guess). I forgot yet to try with vertex colour omitted during export completely. (I am using Blender GLTF exporter).

Of course there will always be differences, at least because of the light estimation. But the wooden textures seem really problematic for me.
But again, it is probably not model-viewer issue in the end. Maybe somebody would have some tips how to cope with that :)

[elalish]

Agreed this is an important issue. Right now Khronos is focused on getting different renderers to render glTF consistently, which is hard enough! USDZ has not standardized PBR rendering, so that's a taller order, as is the conversion between the formats. Also difficult because Quick Look uses different (and unknown) lighting, which is probably the biggest factor here. Please bug Apple about openness and consistency so that we have a chance to solve these things.

[maciekglowka]

Hi, I am bumping the topic, as I am getting a bit desperate. I do not think we will ever get clear responses from Apple (there are unanswered topics on their developer forums on the subject).
So, maybe somebody has some tips / workarounds? I am getting a bit of complaints from furniture manufacturers about it :)
Maybe I should prepare my GLTFs differently?
I've read somewhere online that adding slight emission could help, but then it should happen right before the USDZ conversion...

I would actually think that there would be more complaints here about this issue, so maybe the problem is not that common and indeed has more to do with my files?

Thanks in advance for any help

[elalish]

You said before you were using white vertex colors; have you removed that yet? That's very non-standard, will increase your file size and generally lead to not-well-tested behavior. I would take a close look at the glTFs you're exporting and make sure they are as simple as possible. If you're using the specular-glossiness extension for instance, there's very little hope of achieving consistency.

Still, the primary difference is the lighting, and the simple fact is that Quick Look uses it's own lighting that is not the same as Scene Viewer or model-viewer. And in AR, the lighting is dependent on the room you're in, so it's not possible (or desirable) for the render to look identical. Still, you seem to have some large differences in some of these shots, so it may be partially an export issue.

[david-rhodes]

@maciekglowka three things I recommend:

1. Ensure that Quick Look's standard 3D viewer represents what you're seeing in AR, as well. Sometimes the lighting approximation can cause AR-specific discrepancies.
2. If the 3D viewer on iOS and AR look incorrect, double check that you don't have any occlusion maps with an occlusion multiplier. We saw this issue with a few GLTFs we were using, and I don't believe USDZ has an occlusion multiplier (in this case, your models don't look like they have AO). As for vertex colors, AFAIK USDZ does not support these yet.
3. I doubt this is the case, but double check the color space on your input textures?

[maciekglowka]

Thanks for the quick reply. I did some test on models without vertex colors and it was not the issue.
However I have found an interesting thread on three.js github and there might be a solution. I do not have access to an iOS device at the moment, but will test tomorrow and come back with conclusions :)

Briefly it seems indeed to be a problem with Blender + three.js combination. When there is a roughness map and no metallic map the metallic color is set to white. So there are quirky reflections which can darken the texture.

[maciekglowka]

Thanks David for the tips,
I think we have been writing at the same moment. I will also check those things you mention!

[maciekglowka]

Ok, so I did some tests today and the problem was the lack of metallic texture.
So in case anyone has the same problem: if you plug texture's green channel to roughness in Blender, then you have to plug the blue channel to the metallic input even if it is purely black :)