luminance is an effort to make graphics rendering simple and elegant.
The aims of
- Making the unsafe and stateful OpenGL API safe and stateless.
- Providing a simple and easy interface; that is, exposing core concepts without anything extra – just the bare stuff.
- Easy to read with a good documentation and set of tutorials, so that new comers don’t have to learn a lot of new concepts to get their feet wet.
- Need-driven: every piece of code added in the project must come from a real use case. If you feel something is missing, feel free to open an issue or even contribute!
luminance is a rendering framework, not a 3D engine nor a video game framework. As so, it
doesn’t include specifics like lights, materials, asset management nor scene description. It
only provides a rendering library you can plug in whatever you want to.
There are several so-called 3D-engines out there on crates.io. Feel free to have a look around.
- Buffers: buffers are way to communicate with the GPU; they represent regions of memory you can write to and read from. There’re several kinds of buffers you can create, among vertex and index buffers, shader buffers, uniform buffers, and so on and so forth….
- Framebuffers: framebuffers are used to hold renders. Each time you want to perform a render, you need to perform it into a framebuffer. Framebuffers can then be combined with each other to produce effects.
luminancesupports five kinds of shader stages:
- Tessellation control shaders.
- Tessellation evaluation shaders.
- Vertex shaders.
- Geometry shaders.
- Fragment shaders.
- Vertices, indices, primitives and tessellations: those are used to define a shape you can render into a framebuffer.
- Textures: textures represent information packed into arrays on the GPU, and can be used to customize a visual aspect or pass information around in shaders.
- Blending: blending is the process of taking two colors from two framebuffers and mixing them between each other.
- And a lot of other cool things like GPU commands, pipelines, uniform interfaces and so on…
luminance is written to be fairly simple. The documentation is very transparent about what the
library does and several articles will appear as the development goes on. Keep tuned! The
online documentation is also a good link to have around.
Currently, luminance is powered by OpenGL 3.3. It might change, but it’ll always be in favor on supporting more devices and technologies – a shift to Vulkan is planned, for instance.
luminance does not provide a way to create windows because it’s important that it not depend
on windowing libraries – so that end-users can use whatever they like. Furthermore, such
libraries typically implement windowing and events features, which have nothing to do with our
If you just plan to use
luminance, just read the User-guide section.
If you plan to contribute to
luminance (by writing a windowing crate or hacking on
directly), feel free to read the Contributor-guide section after having read the User-guid
section as well.
In order to get started, you need to create an object which type implements
luminance ships with the trait but no implementor. You need to head over
crates.io and search for luminance crates to find a
windowing backend first.
Such a backend should expose a type which implements
GraphicsContext. You can create one per
thread. This limitation enables
luminance not to perform plenty of runtime branching,
minimizing the runtime overhead.
If you really want several contexts, you will need several OS threads.
GraphicsContext is the entry-point of everything
luminance provides. Feel free to dig in its
documentation for further information on how to use
luminance. Most objects you can create
will need a mutable reference to such a context object.
You want to hack around
luminance or provide a windowing crate? Everything you have to know is
described in this section.
In order to implement
GraphicsContext, you need to know several points:
- You can get a
GraphicsState::newfunction. You have to match the return value. Depending on whether your implementation is the first asking a
GraphicsStateon the current thread, you might get (or not) an
Ok(state). If not, a descriptive error is returned.
- You’re advised to
GraphicsState::newreturned value to implement your own
newfunction for your backend type because of the restriction of having only one context per thread in
That module exports blending-related types and functions.
Static GPU typed arrays.
Depth test related features.
Face culling is the operation of removing triangles if they’re facing the screen in a specific direction with a specific mode.
Framebuffers and utility types and functions.
Generalized free tuples.
Aliases types used to make it easier using long linear algebra types.
Dynamic rendering pipelines.
Pixel formats types and function manipulation.
GPU render state.
This module provides texture features.
Vertex formats, associated types and functions.
Generalized free tuple macro.
Create a new