Home

Awesome

Granite

Granite is my personal Vulkan renderer project.

Why release this?

The most interesting part of this project compared to the other open-source Vulkan renderers so far is probably the render graph implementation.

The project is on GitHub in the hope it might be useful as-is for learning purposes or generating implementation ideas.

Disclaimer

Do not expect any support or help. Pull requests will likely be ignored or dismissed.

License

The code is licensed under MIT. Feel free to use it for whatever purpose.

High-level documentation

See OVERVIEW.md.

Low-level rendering backend

The rendering backend focuses entirely on Vulkan, so it reuses Vulkan enums and data structures where appropriate. However, the API greatly simplifies the more painful points of writing straight Vulkan. It's not designed to be the fastest renderer ever made, it's likely a happy middle ground between "perfect" Vulkan and OpenGL/D3D11 w.r.t. CPU overhead.

Missing bits:

Implementation is found in vulkan/.

High-level rendering backend

A basic scene graph, component system and other higher-level scaffolding lives in renderer/. This is probably the most unoptimized and naive part.

PBR renderer

Pretty barebones, half-assed PBR renderer. Very simplified IBL support. Fancy rendering is not the real motivation behind this project.

Post-AA

Fairly straight forward FXAA, SMAA and TAA (no true velocity buffer though).

Automatic shader recompile and texture reload (Linux/Android only)

Immediately when shaders are modified or textures are changed, the resources are automatically reloaded. The implementation uses inotify to do this, so it's exclusive to Linux unless a backend is implemented on Windows (no).

Network VFS

For Linux host and Android device, assets and shaders can be pulled over TCP (via ADB port-forwarding) with network/netfs_server.cpp. Quite convenient.

Validation

In debug build, LunarG validation layers are enabled. Granite is squeaky clean.

Render graph

renderer/render_graph.hpp and renderer/render_graph.cpp contains a fairly complete render graph. It supports:

I have written up a longer blog post about its implementation here.

The default application scene renderer in application/application.cpp sets up a render graph which does:

Scene format

glTF 2.0 with PBR materials is mostly supported. A custom JSON format is also added in order to plug multiple glTF files together for rapid prototyping of test scenes.

Texture formats

ASTC, ETC2 and BCn/DXTn compressed formats are supported.

gltf-repacker

There's a tool to repack glTF models. Textures can be compressed to ASTC or BC using ISPC Texture Compressor. zeux's meshoptimizer library can also optimize meshes. The glTF emitted uses some Granite specific extras to be more optimal, so it's mostly for internal use.

Compilers

Tested on GCC, Clang, and MSVC 2017.

Platforms

Vulkan implementations tested

Build

Plain CMake. Remember to check out submodules with git submodule update --init.

mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release -G Ninja
ninja -j16 # YMMV :3

For MSVC, it should work to use the appropriate -G flag. There aren't any real samples yet, so not much to do unless you use Granite as a submodule.

viewer/gltf-viewer is a basic glTF viewer used as my sandbox for more complex testing. Try some models from glTF-Sample-Models.

Android

Something ala:

cd viewer
gradle build

Assets used in the default gltf-viewer target are pulled from viewer/assets.

Third party software

These are pulled in as submodules.