Y-axis flipped on rendering (was "Filament materials mismatch with backend engine")

[lee-deraud]

Checklist

• I have searched for similar issues.
• For Python issues, I have tested with the latest development wheel.
• I have checked the release documentation and the latest documentation (for main branch).

Steps to reproduce the issue

I'm escalating this to a bug/build issue due to lack of feedback on #7441. My apologies if this is a breach of protocol.

Built from source, NO modifications of downloaded CMakeLists.txt.

git clone https://github.com/isl-org/Open3D.git
cd Open3D
mkdir build
cd build
cmake -G "Visul Studio 18 2026"  -A x64 -DCMAKE_INSTALL_PREFIX="..\out"  ..

Then built projects 'ALL_BUILD' and 'INSTALL', 'Release' configuration, inside VS2026 IDE. (Note: also built from command line and on another computer and with VS2022, same symptoms.)

Ran the 'Open3D.exe' example application.

Error message

(p312) E:\Repos\Open3D\out\bin\Open3D>.\Open3D
[Open3D INFO] Checking for resources in E:\Repos\Open3D\out\bin\Open3D/./resources
FEngine (64 bits) created at 000001CEAC71F670 (threading is enabled)
FEngine resolved backend: Vulkan
Vulkan device driver: NVIDIA 591.74
Selected physical device 'NVIDIA GeForce RTX 3060' from 1 physical devices. (vendor 0x10de, device 0x2504, driver 0x93d28000, api 1.4)
Backend feature level: 3
FEngine feature level: 1
The stereoscopic type in the compiled material 'Filament Default Material' is 1, which is not compatiable with the engine's setting 0.
The stereoscopic type in the compiled material 'defaultLit' is 1, which is not compatiable with the engine's setting 0.
The stereoscopic type in the compiled material 'defaultLit' is 1, which is not compatiable with the engine's setting 0.
The stereoscopic type in the compiled material 'defaultLitTransparency' is 1, which is not compatiable with the engine's setting 0.
The stereoscopic type in the compiled material 'defaultLitSSR' is 1, which is not compatiable with the engine's setting 0.
The stereoscopic type in the compiled material 'defaultUnlit' is 1, which is not compatiable with the engine's setting 0.
The stereoscopic type in the compiled material 'defaultUnlitTransparency' is 1, which is not compatiable with the engine's setting 0.
The stereoscopic type in the compiled material 'depth' is 1, which is not compatiable with the engine's setting 0.
The stereoscopic type in the compiled material 'unlitGradient' is 1, which is not compatiable with the engine's setting 0.
The stereoscopic type in the compiled material 'depth' is 1, which is not compatiable with the engine's setting 0.
The stereoscopic type in the compiled material 'normals' is 1, which is not compatiable with the engine's setting 0.
The stereoscopic type in the compiled material 'normals' is 1, which is not compatiable with the engine's setting 0.
The stereoscopic type in the compiled material 'colorMap' is 1, which is not compatiable with the engine's setting 0.
The stereoscopic type in the compiled material 'unlitSolidColor' is 1, which is not compatiable with the engine's setting 0.
The stereoscopic type in the compiled material 'unlitBackground' is 1, which is not compatiable with the engine's setting 0.
The stereoscopic type in the compiled material 'infiniteGroundPlane' is 1, which is not compatiable with the engine's setting 0.
The stereoscopic type in the compiled material 'unlitLine' is 1, which is not compatiable with the engine's setting 0.
The stereoscopic type in the compiled material 'unlitPolygonOffset' is 1, which is not compatiable with the engine's setting 0.
The stereoscopic type in the compiled material 'uiBlit' is 1, which is not compatiable with the engine's setting 0.
The stereoscopic type in the compiled material 'imageBlit' is 1, which is not compatiable with the engine's setting 0.
The stereoscopic type in the compiled material 'Skybox' is 1, which is not compatiable with the engine's setting 0.
vkCreateSwapchain: 1280x960, 44, 0, swapchain-size=3, identity-transform=true, depth=126

(p312) E:\Repos\Open3D\out\bin\Open3D>

The errors do not actually stop the program, but the window is solid black: no menu bar, no displayed data, so it might as well be a hard crash.

Open3D, Python and System information

- Operating system: Windows 11 64-bit
- Python version: N/A
- Open3D version: output from python: `print(open3d.__version__)`
- System architecture: x86
- Is this a remote workstation?: no
- How did you install Open3D?: build from source
- Compiler version (if built from source): Visual Studio 18 2026 (same behavior using VS2022)

Additional information

Note that I get the same error messages when running a GUI Python script using the wheel generated from this build, the example app is just easier to test. In any case, symptoms are identical across two machines, two versions of Visual Studio, Python, and compiled C++. Also identical runtime symptoms on third computer with Intel integrated GPU only. Windows 11 and 3rd-party device drivers (Intel/Nvidia) are all up to date.

The prebuilt version 0.19.0 from github does not appear to use Vulkan as a backend, only OpenGL.

[ssheorey]

@lee-deraud sometimes filament picks a Direct3D emulated Vulkan GPU device and that may cause issues such as this. The latest main (after PR #7444 ) contains a workaround that uses OpenGL backend by default on Windows and should avoid this issue. Can you test that please? PS: This is unrelated to the "steroscopic type" warnings - those are harmless.

[lee-deraud]

Ah, thanks. We crossed in the mail: this afternoon's build worked. Only the tenth or so time I've done this in the last couple of days. I would have sworn the repo I was using yesterday was recent enough to include #7444, but apparently not. All good now.

Are the material warnings something that will go away eventually?

[UPDATE] Spoke too soon, as usual. I'm seeing several anomalies, or at least visual differences between running the same script on "stock" 0.19.0 and the newly-built version. One is cosmetic (colors are off, like 20% desaturated), the other is that the Y-axis seems to have flipped, but I can't tell as yet whether it's just a rendering thing or something is misbehaving internally. Too tired/hungry to deal with it now, will update further tomorrow. Screen dump attached: left is 0.19.0, right is my build.

[lee-deraud]

Ok, NOT just cosmetic: flipping the display screws up point-picking by breaking the mapping between mouse coordinates and world coordinates. You can use the example script 'mounse_and_point_coord.py' to verify.

[lee-deraud]

I have a workaround for my own script, but it ain't pretty. I have to flip the camera's definition of "up" (in SceneWidget.look_at()) and then compute the mouse Y offset from the bottom of the widget instead of the top when doing the unproject from the depth map. Of course, that breaks when running the script with the 'real' 0.19.0, so there's also code to detect which version the script is running under. It's the kind of thing that gives kludges a bad name.

I'm a bit unclear of the accepted protocol at this point. Am I supposed to create a new issue to report this behavior or just leave it as part of this one? (Fixing it at the C++ level is way beyond my skill-set...)

[ssheorey]

Yes, I noticed the direction error as well. I would appreciate it if you can create a bugfix PR and I'll try to get it merged asap.

[lee-deraud]

PR as is 'problem report' or 'pull request'? (I am VERY new to all things Github.)
The way you phrased that sounded like you expect me to fix it...I'm good, but I'm not THAT good.