OpenSceneGraph VS bgfx

I started in 2001 with OpenSceneGraph which made extensive use of intrusive pointers. This was 10 years before C++11 note. That codebase continues to be relevant and as performing as ever.

browse github and try to contribute. I started with OpenSceneGraph

I have been using OpenSceneGraph for over 20 years. It is used in the military a lot and I myself have seen it used to simulate war scenarios with realtime data aboard of a command-and-control center of a battleship.

Does http://www.openscenegraph.org/ fit?

Speed Dreams: It is a fork of TORCS, and was born as the need to include many more functions to the latter. In Speed Dreams the menus would be completely redesigned, adding many more options and making them much more intuitive; the game acquired dynamic time, improvements in reflections, career mode, a new simulation mode and multi threading. Over time many more options were implemented, such as local multiplayer mode, Force Feedback, and of course more and better cars and tracks, a new and more powerfull graphic engine (OpenSceneGraph) among other things, making it a much more complete game than its predecessor. They recently they have presented version 2.2.3. You can also install it in AppImage and Flatpak format.

Here is an example: https://github.com/openscenegraph/OpenSceneGraph/blob/master/examples/osgsimplegl3/osgsimplegl3.cpp

openscenegraph (mainly focuses on graphics, used by openmw for example)

Is not little, is very complex open source racing simulator. There are a lot of cars, categories, tracks. The physics has a lot of work . About the graphics, the devs are working on change the graphic engine to OpenSceneGraph, that actually works, but needs much more polishing. You can see his quality on this video: https://youtu.be/4daTgcxEWRg

I love Godot for a complete game engine. For just the renderer you could consider http://www.openscenegraph.org

I previously integrated bgfx [1], which allows you to write graphics code and shaders once and supports consoles, with SDL2 stack and Swift [2]. It was quite a nice experience, especially for someone who had never worked with any of these tools before. I'm excited for SDL3 as it introduces console abstractions, eliminating the need for additional dependencies for the GPU API, especially for someone who casually experiments with graphics. Moreover, Godot officially supports the Steam Deck, and hopefully, more consoles will be supported in the future. On a related note, Miguel de Icaza is advocating for Swift adoption in Godot, and he is working on porting the editor to SwiftUI on iPad, which is quite interesting to see the progress [3].

[1] https://bkaradzic.github.io/bgfx/overview.html

[2] https://github.com/bgbernovici/myndsmith

[3] https://blog.la-terminal.net/xogot-code-editing/

I'm curious why webgpu is receiving so much attention. There have been many low-level cross-platform graphics abstractions over the years. The bgfx [1] project had its first commit ~12 years ago and it's still going! It's much more mature than webgpu. I'm guessing being W3C backed is what's propelling it?

[1] https://github.com/bkaradzic/bgfx

I don't use orthodox C++, but the author of this is also the author of bgfx, which is a very popular graphics api abstraction. It runs on (and has commercial products on) Android, ios, Playstation, Xbox, PC, Mac, Linux, and wasm. While the coding style might be unpopular, it has successful projects.

https://github.com/bkaradzic/bgfx

Sort of, I'd recommend a modern higher level API. I'm not sure what the current recommended ones are (probably bgfx), but assuming the wrapper is "low level enough", then the concepts you learn are still going to apply.

https://github.com/bkaradzic/bgfx for just that FOSS intermediate rendering library (includes Minecraft)

BGFX: Pretty mature and easy to use with many backends.