QRhi + Qt3D & / QtQuick3D is pretty much the exact same goal than pygfx with a different implementation: https://github.com/qt/qtbase/tree/dev/src/gui/rhi http

QRhi + Qt3D & / QtQuick3D is pretty much the exact same goal than pygfx with a different implementation: https://github.com/qt/qtbase/tree/dev/src/gui/rhi https://github.com/qt/qtbase/tree/dev/src/gui/rhi ; https://doc.qt.io/qt-6/qt3d-index.html https://doc.qt.io/qt-6/qt3d-index.html ; https://doc.qt.io/qt-6/qtquick3d-index.html https://doc.qt.io/qt-6/qtquick3d-index.html ; QRhi itself pretty much sits at the "wgpu" abstraction layer. I've been using it for 4-ish years now in https://ossia.io https://ossia.io (just the RHI part) Pros: - Integrates with Qt (of course). - Really really easy API compared to the average C++ API. - Works absolutely everywhere. - Many provided examples: https://github.com/qt/qtbase/tree/dev/tests/manual/rhi https://github.com/qt/qtbase/tree/dev/tests/manual/rhi - Shader language is SPIRV-compatible GLSL 4.x thus it makes it fairly trivial to import existing GL shaders (one of my requirements was support for https://editor.isf.video https://editor.isf.video shaders). Cons: - Was developed before Vulkan Dynamic Rendering was introduced so the whole API is centered around the messy renderpass thing which while powerful is sometimes a bit more tedious than necessary when your focus is desktop app development. However, Qt also has a huge focus on embedded so it makes sense to keep the API this way. - Most likely there are some unnecessary buffer copies here and there compared to doing things raw. - Does not abstract many texture formats. For instance still no support for YUV textures e.g. VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and friends :'(