this is my first topic in this community so please let me thank you in advance for your support.
I am experiencing serious troubles exporting models as *.glb (with “Import-Export glTF 2.0 Format” add-on) as everytime I export an object with an image texture map connected to its shader it look dull and with washed out colors when I open the file on some AR viewers online.
I think I am doing everything right but apparetly this is not the case, here is a breakdown of my approch:
I make sure the texture is either a *.png or *.jpg file (but I’ve also tried *.tiff) with “sRGB IEC61966-2.1” ICC Profile embedded (I tried both 8bit and 16bit versions);
I import the texture in Blender with an “Image Texture Node” (color space: sRGB) and I connect it to the base color socket of the Principled BSDF (I tried with roughness setting of 0 all the way to 1).
Nothing else is connected to the shader;
In the render setting (even if I am pretty sure it has no influence on the exported *.glb file), I set:
Display Device: sRGB
View Transform: Standard
Look: None
Exposure: 0
Gamma: 1
Sequencer: sRGB
I export the object with the following settings:
Format: glTF Binary (.glb)
Include: Selected Object
Transform: +Y Up
Mesh: Apply Modifiers | UVs | Normals | Vertex Colors → Checked
Material: Materials → Export | Images → Automatic
Lighting: Lighing Mode → Standard
Compression: Unchecked
After having exported the object in *.glb format I tried to open it in a series of different AR Viewers: AR Model Viewer for Wordpress and Model Viewer.
The texture always looks washed out if seen as a model on screen in the web browser (I tested it on Firefox and Chrome) BUT it looks with the correct colors in the case of actually using the AR Model Viewer to place the object in the scene through the device camera.
I have really tried every possible thing that came to my mind to solve this issue but I couldn’t make it work.
If anyone has any advice I would truly appreciate!
My whole point is all about the colors.
I work on monitors calibrated with spectrophotometers and for me the difference between the two images looks huge, maybe it’s different on other monitors.
I understand that there might be a difference based on the interpolation of the engine but I don’t understand how the lighting should affect the image. From my understanding of the *.glb file only the object is included and no lighting (as it is derived from the scene once the object is placed through the devide camera “in the real world”) but maybe I am wrong.
What bothers me the most is that the colors are wrong only when viewing the *.glb file on “the screen” but are then correct one the object is seen through the device camera in AR mode.
Just image a red latern… or whatever lighing setup some viewer/app has…
…if there are no lightsources… yes…
Maybe the AR viewers use any other color model/ profile than sRGB because of the different hardware than usual desktop screen ?? ( I’m not sure if you menat hardware devices or viewer apps to simulale this… but it’s the same question: sRGB or whatever?)…
Yes, clearly if in the AR view some extra lighting setup has been added that would change the overall illumination but if you check on https://modelviewer.dev/ you also have the possibility to set a neutral HDR environment and also in that case the colors look faded.
I guess it is more a problem of color interpretation through ICC Profiles or some other sort of thing becase, even with different illumation (again, it is possible to test on that website), colors are always so much wrong that it cannot possibly be due to illumination.
What I mean by hardware device is that, once the model is done and converted in *.glb format, I use it on a web page (which, in turns, uses a wordpress plugin to visualize the *.glb file).
Now, if you open the web page on a pc, laptop, or any other devices that doesn’t let you have a true AR experience, you would simply see the 3D object on the page and you could rotate it around its axis.
If, instead, for i.e. you have a phone (iOS or Android), this plugins enable you to click on the 3d model, the camera of the phone will automatically open, and you could see the object placed in the scene that you frame with the phone camera. Just like this: https://velocitize.com/wp-content/uploads/2018/08/Houzz2.jpg
I think what you’re seeing is the tone mapping, or “view transform” in Blender’s terminology. You’ve got “View Transform: Standard” in Blender, but the viewer in your screenshot uses ACES Filmic. It’s a complicated topic — see https://modelviewer.dev/examples/color.html — the “washed out” result is valid for a lit material.
Do you actually want the material to be affected by light, or would an unshaded material be OK? I believe Model Viewer only applies tone mapping to lit materials.
It would help if you were able to use the same lighting … you can adjust it closer if you change the light properties in Model Viewer and bring down the intensity of the white light…
Hello, thank you very much for your answer and sorry for my late reply but I’ve been very busy with my work.
I’ll check the link you shared.
In the meantime, I am sure it’s my fault somehow, but in Render Properties / Color Management / View Transform I cannto select ACES (it’s not there) I only have Standard, Filmic, Filmic Log, Raw and False Color. None of these replicates what I see in Model Viewer.
I need to create a frame with a picture so, as long as the picture has the correct colors, I don’t mind if it is properly lit or not.
What confuses me is that when I use the object with texture in augmented reality mode, throught the camera, it has the correct colors. When I preview the 3D object simply on screen, in the browser, it has wrong, washed out colors. Shouldn’t it always look the same, being the file the same?
Thank you very much for your reply.
Unfortunately lower the light will make the object darker (therefore correctly increasing the saturation) but the colors will remain wrong the same.
It may work for a single color object but I need to create a frame with a picture inside and the picture will still be wrong.
The Filmic tone mapping that Model Viewer uses, and the Filmic tone mapping that Blender uses, are not the same. They’re close-ish, but no way to guarantee the same colors.
Shouldn’t it always look the same, being the file the same?
Unfortunately, no — these renderers have to make a lot choices about lighting and tone mapping, and those choices don’t get encoded into a 3D file.
If you connect an image texture directly to the Material Output “Surface” socket, it becomes an unlit material when exported to glTF. Model Viewer’s tone mapping shouldn’t affect it then, so it should look much closer to what you see in Blender’s “Standard” view transform.
Thank you very much for your hint of using an unlit material!
It actually worked perfectly for viewing the model directly in the browser.
On the other side, when I now try to see the model from the camera, the image disappears entirely.
Here is a screenshot of what I see through the camera.
I guess there was a sort of “exporting issue” so I tried to export different version changing the setting in various way but I couldn’t find the solution.
I also tried this approach to create an unlit material (as for Blender Manual 3.4) that, instead of connencting the texture directly to the surface, suggest to create this node tree:
I think the export to glTF will be the same with or without the light path option, it’s simply an unlit or shadeless material.
What device and OS are you doing the Augmented Reality (AR) tests with? Android lets ModelViewer render the glTF (and other formats) model directly to AR with the WebXR API, and the unlit material should work fine.
iOS severely restricts access to the AR context… Model Viewer has to convert the model to a different format (USDZ) and then hand the model off to an entirely different renderer (iOS Quick Look). The addition of a second format and a third renderer make this all far more complicated. Scanning through the known limitations of iOS Quick Look, a few stand out:
No support for double-sided geometry
Incorrect face-culling for inverted geometry
Basically, make sure your mesh isn’t inverted, enable backface culling, and (if you need to show both sides) duplicate the mesh instead of disabling backface culling.
These are just guesses though… it may be necessary to file a bug on ModelViewer if the model appears correctly in the browser but incorrectly in AR.
Hello, thank you for this idea.
I’ve tried it but actually I couldn’t make it work.
If I connect the texture not only to the base color input in the principled BSDF but also in the emitter socket it changes the colors completely…
Maybe I am missing something?
Thank you for your reply.
So far I had only had the chance to test everything on iOS but yesterday night I tried on Android with a friend’s phone.
Test results:
The version with the texture connected to the base color of the Principled BSDF looks washed out in the browser in both OS and looks correct once viewed in AR through the camera.
The version with the unlit material looks correct on both OS in the browser and: in Android looks perfect also in AR through the camera, in iOS the texture disappears once the model is viewed in AR.
At this point I guess it might be a bug in AR Model Viewer for Wordpress.
Do you know any other wordpress plugin I might experiment with?
My polite guess, not being a programmer, is that the extension (KHR_materials_unlit) is not properly recognized when in iOS ambient.
Let me know your point of view!
Thank you very much!
See above, and the limitations of iOS Quick Look. If you enable backface culling in Blender, does the texture disappear in Blender? If so I’d make adjustments in Blender to reverse it. Otherwise this must be reported as a bug to model-viewer, which is responsible for converting the (working) glTF model to a (not working) USDZ model for iOS Quick Look.
Alternatively there may be some tools for converting the glTF file to a USDZ file offline yourself, and providing that to model-viewer instead of letting it auto-convert. I’d test that you can successfully convert it yourself first, I’m not sure how to do that.
Do you know any other wordpress plugin I might experiment with?
My polite guess, not being a programmer, is that the extension (KHR_materials_unlit ) is not properly recognized when in iOS ambient.
iOS Quick Look has no concept of an unlit material, and many other limitations. Model Viewer is doing its best to ‘adapt’ the scene to those limitations but it’s lossy. That’s the core of the problem, Model Viewer cannot use its own renderer in iOS Quick Look, it just has to convert to this format and hope for the best. If you can convert to USDZ yourself first, then make adjustments to the USDZ as needed, that should work.
…
Scanning through the 
