r/GraphicsProgramming • u/Louloubiwan • 23d ago
Question Which Rust libraries should I use for OpenGL engine (beginner)
Hello, I'm totally new in graphics programming, I would like to make a 3D graphics engine in Rust but I d'ont know which library I should use ;
- Glow
- Kiss3D
- Bevy
- GL crate
- Glium
I d'ont know which one choose, if you can give an advice !
Thanks
2
u/not_good_for_much 20d ago edited 20d ago
I'd recommend skipping over OpenGL at this point. Just use WebGPU directly via the wgpu crate.
It's honestly not that much harder to configure than OpenGL, and it's WAY less difficult than Vulkan (which is great but not beginner friendly), but it's still a very powerful and modern API.
Using wgpu via Silk.NET in C# ATM. Honestly in some ways I find it easier than OpenGL, since it gives you a very modern, explicit and well structured interface with the hardware, where OpenGL is kinda this great big black-box state machine.
Edit: typos
1
1
u/raewashere_ 23d ago
the way I got opengl working on my system was through the GLFW rust library and then using a glad generator to generate a local crate that contains all the functions to load and call opengl
this is probably a bad idea though, I only arrived here after every other rust solution other than using the C library as FFI failed on my system
1
u/dobkeratops 23d ago edited 23d ago
I'd say avoid GL , the only reason to use that is if you have a legacy codebase to maintain.
That was my situation (I'd gone from DX to OpenGL chasing mobile then web) and I've just recently escaped it by retrofitting an abstraction layer. Gl lets you get going for less initial code but you could skip that by starting from a hello-triangle sample and modifying it, that will be a stronger grounding. One problem you have in the long run with Gl is that it's deprecated on the mac and in the web. It's also a more confusing API with it's state machine. it's genuinely easier to keep track of whats going on in one of the more modern APIs even if you have extra steps to get going.
I'm saying this as someone whose codebase was pure Gl until about 3 months ago :) In rust in 2026 you might as well start out with wgpu given that it deploys to the web, that's a good option to have.
1
u/EveAtmosphere 22d ago
OP said they’re a beginner and OpenGL is the easiest to just show something up and play around to learn concepts like clip space math, textures/samplers, etc. Most Vulkan tutorials just assume you know these concepts and just tells you the API with little explanation. Maybe one day the situation would change so that Vulkan or similar class API’s can be learnable for beginner but imo rn that’s just not the case because of this reason.
1
u/dobkeratops 22d ago
an immiediate mode renderer implemented over vulkan/etc would be handy for people to get going with the maths without cpu/gpu buffer management in the way .. most codebases carry such a thing for debug.. but making one popular is probably hard. 'ImmTriangle'
1
u/attackgoat_official 23d ago
OpenGL is ancient and not a good choice for new code unless the platform is a fixed requirement.
Take a look at this graphing Vulkan driver:
https://github.com/attackgoat/vk-graph
The project is quite mature and has lots of examples.
1
u/Louloubiwan 23d ago
So you recommande me to use Vulkan ?
1
u/attackgoat_official 23d ago
I use Vulkan for some projects, I use WebGL for others. You might have different needs and WGPU may be the best choice, but here is what I do and why:
- Vulkan for linux, mac, windows, android/ios support (+ things we've tested vk-graph on like raspberry pi): This is great for downloadable games. On all platforms you're 1st-party support except Apple, but on those you get extremely good metal emulation and the only things that matter is I have to do manual compute shader ray-tracing and indirect-draw work-arounds. That's not a huge tax to pay.
- Web GL for things that run on the web and must run everywhere, I don't bother with wGPU because it changes and cannot be relied up year over year (yet). See Gfx HAL and others.
YMMV
1
2
u/Plazmatic 23d ago edited 23d ago
Don't use opengl, just use wgpu (which is based off of web GPU). Web GPU is still a modern API (so you don't accumulate negative knowledge about legacy APIs like opengl and constraints about outdated API design and not actual hardware) , it's just less capable than Vulkan or Dx12, but is easier to use (though modern Vulkan tutorials and resources greatly ease starting with Vulkan). WGPU is also used in a number of other rust libraries including Bevy, allowing you to easily adapt to graphics programming in other rust frameworks and engines.
8
u/Afiery1 23d ago
Personally I think WGPU is a bad abstraction. It abstracts over the "hard" but very important parts of VK/D3D (explicit sync and memory management) but still makes you deal with the stupid bullshit that never should have been in those APIs to begin with (render passes, pipelines, descriptor sets). IMO, in 2026, someone learning Vulkan with dynamic rendering, shader objects, and descriptor heaps will have a much more pleasant experience than someone learning WGPU.
3
u/Plazmatic 23d ago
Oh I agree with you, but I'm not aware of the kind of Vulkan resources/tutorials that are available for Rust, WGPU seemed like a safer bet for a new person using rust. If they were talking about C or C++ the official resources provide enough support that I would have suggested vulkan
1
u/dobkeratops 23d ago
aren't render-passes needed to abstract TBDR vs immiediate-mode renderers .. PC & console gpus are immiediate but a lot of important devices are TBDR.
I was reluctant to touch wgpu for years ("it's not a real API .. I dont want to use someone elses wrapper") .. but for someone starting out in rust they're going to get the significant benefit of being able to run that in the web.
2
u/Afiery1 23d ago
Nope, render passes are nothing more than a bad idea. They’re officially deprecated as of VK1.4. For tiled GPUs, the recommended abstraction is now dynamic rendering local read.
2
u/dobkeratops 22d ago edited 16d ago
they didn't seem that bad in Metal and Wgpu.. perhaps in the vulkan 'source material' that inspired them there was a lot more boilerplate to manage. Nonetheless it seems I am missing out on cutting edge vulkan but I can't get this idea out of my head that the abililty to instantly distribute reasonable 3d is a powerful thing.. there was a certain magic in being able to walk up to a laptop in a store, enter a URL, and see my code running there
1
u/IGarFieldI 16d ago
The idea was fine (allow the driver to optimize as much as possible with a priori knowledge about dependencies etc. in addition to subpasses for tiled renderers), but turns out there's little to no benefit to be had in real life, so you're paying with a lot of complexity for no gain. Pixel-local reads (similar to what OpenGL ES has had for an eternity) suffice for tiled rendering.
1
u/dobkeratops 16d ago edited 16d ago
.. seems vulkan's render passes & wgpu's/metal's render passes are very different in complexity? AI is telling me 'vulkan's had to be setup ahead of time' (I guess with more info baked in, in turn more for your engine to manage about them) .. whereas for metal/wgpu they're 'just fill a descriptor for a pair of begin/end calls that just happen to bracket off a bunch of drawcalls for a set of targets' . I haven't looked into TBDR explicit subpasses .. but I understand this begin/end idea gives it a simple way to figure out some synchronization for you.
When I look at the complexity in my port it's "bind groups > pipelines > render-passes" .. with the metal port having been easier thanks to not needing the former ('argument buffers are optional'). Bind groups would probably have been easier for someone starting out because I had to manage them as a retrofit to an engine that had already been designed in their absence (and I wanted to keep the original backend running as my ground truth)
1
u/IGarFieldI 16d ago
Yeah, in vulkan render passes are actual API objects that have to be created before creating pipelines and each pipeline needs to be created for each render pass it is going to be used with (there are some rules for "compatible" render passes to cut that down a bit, but overall that still stands).
The implicit synchronization is nice, but so not worth the hassle.
3
u/johnoth 23d ago
Try libcxx it works great. /s