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::VertexBuffer
type – a buffer to hold vertices – while luminance gives you a Tess
type that hides that kind
of complexity away for you.Frame
object 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 draw
command 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 Program
creation – 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).Frame
of 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 Uniform
, Uniformable
,
UniformInterface
, etc.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.