It’s been a while since I’ve been wanting to do this. Either on IRC, Reddit, GitHub Issues, IRL or other any other way of communicating, there are more and more people asking me to compare luminance to other, well known and famous, rendering-like frameworks.
I’ve made a listing with pros and cons. in the README file of luminance. I’ll just copy that section and report it below so that you’re not even a click away from the listing!
A lot of folks have asked me on IRC / Reddit / gitter / etc. how luminance compares to other famous frameworks. Here are a few comparisons:
glium has been around for a while – way longer than luminance.
According to crates.io, glium is no longer actively developed by its original author.
impl, which is neat – however, this tends to be less and less true as luminance has been getting new macros lately.
glium::VertexBuffertype – a buffer to hold vertices – while luminance gives you a
Tesstype that hides that kind of complexity away for you.
Frameobject in glium and passing the whole pipeline at once. The pipeline then must be completely resolved prior to render. See this. luminance is more flexible on that side since it enables you to provide the rendering pipeline in a dynamic way, allowing for tricky structure traversal without cloning nor borrowing, for instance. glium requires a tuple of
(vertices, indices, program, uniforms, render_state)while luminance works by building the AST node by node, level by level.
uniform!macro when invoking the
drawcommand on your
Frame. This has the effect to lookup the uniform in the shader for every call – modulo caching – and requires you to explicitly pass the uniforms to use. luminance uses a contravariant approach here: you give the type of the uniform interface you want to use and you will be, later, handed back a reference to an object of that type so that you can alter it. All of this is done at the type level; you have nothing to do when passing values to the shader in the pipeline. Opposite approaches, then. Also, notice that luminance looks up the uniform names exactly once – at
Programcreation – and provides several hints about uniform utilization (inactive, type mismatch, etc.). glium seems to have runtime type checking as well, though.
[[f32; 4] 4]in both crates).
Frameof glium above.
gfx is a high-performance, bindless graphics API for the Rust programming language. It aims to be the default API for Rust graphics: for one-off applications, or higher level libraries or engines.
The current listing concerns gfx in its’ pre- low level situation. Recent gfx APIs are different.
gfx_defines!macro to easily introduce the types and make named bindings (to map to vertex attributes in shaders). A lot of boilerplate is generated thanks to that macro, which is neat. luminance has a similar scheme even though the macro support in luminance is less advanced. On a general note: luminance is less macro-driven.
gfx_defines!macro. They’re declared in very similar ways as in luminance. However, gfx uses the same syntax as with vertex definition, while luminance has an ad hoc approach – it’s typical Rust code with annotations. That doesn’t make a huge difference per-se. gfx calls uniforms
constant, which is nice because it can abstract over the concept, while luminance doesn’t and uses the terms
gfx_defines!macro invokations. This is seriously cool and luminance suffers a bit from not having that – defining pipeline in luminance is a bit boring because of lambda / closures boilerplate.
create_vertex_buffer_with_slice, for instance. This is nice as it enables coping with multi-threading safety, which is something luminance doesn’t support yet (it’s planned, though).
gfx_app::Application, defined in the gfx_app crate.
On a general note, luminance and gfx pre-ll are way too different to be compared to each other. If you want to target several backends, do not hesitate and go to gfx. If you target only one system and want simplicity, go to luminance.
ggez is a Rust library to create a Good Game Easily.
As ggez is primarily focused on 2D projects, it doesn’t compare directly to luminance, as it’s about graphics, sound, input, etc. Also, ggez is using gfx.
vulkano is a wrapper around the Vulkan graphics API.
The scope is not really the same as vulkano only targets Vulkan and – as for today – luminance is about OpenGL.
amethyst is a fast, data-oriented, and data-driven game engine suitable for rapid prototyping and iteration.
As stated in the current document, luminance is not a game engine. So if you’re looking for a tool that already has everything needed to build a game, amethyst should be your toy. Also, it’s using gfx.
piston is a modular game engine written in Rust.
As for other game engines, nothing to compare here since luminance is not a game engine!
spectra is a demoscene framework / engine mainly written for demoscene purposes, even though it can now be used to some other extents (animation / video game).
spectra uses luminance as primary graphics backend, but it provides way more features than just graphics. You’ll find audio, animation, editing, resource system, custom shading language, etc.