flares.science the continuation of my bachelor thesis After finishing my thesis, I was left with a state-of-the-art ghost rendering engine missing one very important thing: the central flare.

Taking a break from computer graphics for two months to work on embedded electronics and specifically my split corded keyboard and receiving interest from the games’ industry gave me enough motivation to continue working on the giant codebase that is now Flares Science.

I started with removing all parts that were only necessary for research, clearing a few thousand lines from the workspace.

With the cleaned up workspace I could get to work on implementing the central flare.

As always, implementing start with research. Half of that was already done, because I looked at central flares briefly for the thesis. So I knew which papers to look at.

Getting started, I decided to get to implement Quad-Based Fourier Transform for Efficient Diffraction Synthesis. Starting with the aperture generator, everything went surprisingly smoothly using the Rust crates image and simdnoise.
The actual partial fft just didn‘t work. The quadtree worked after a bunch of debugging, and each individual quads fourier transform looked reasonable. A debugging session with a mathematician didn‘t result in any working fourier transforms with this technique either, but the switch to a „normal“ fft with 2d functionality was very quick and resulted in very acceptable performance. Especially with [rust-fft] and their simd optimizations.

With the working diffraction implementation, it was time to integrate the library into an application. For that I chose to use wasm and publish a demo and the full version on the flares.science website. As both versions share most of their code, I made a Rust „feature“. This means compiling the full version instead of the demo is as easy as adding a feature flag to the cargo build command.

The hosting for flares.science initially used nginx with a password-protected folder for the full version, but this didn‘t offer the required flexibility to add or remove users and only allows for one level of permissions. So I used rocket.rs to develop a small web server with user authentication and therefore the flexibility required. rocket.rs was refreshingly easy to use and deploy, not to mention the performance of >60k requests per second including a sql query on my desktop.

To deploy flares.science and docs.flares.science I developed my own very simple system based on webhook and my private instance of gitea. It works by calling a webhook on the server running NixOS, which then executes a script, that starts with a Nix shebang that pulls in its own dependencies, such as rustup and nodejs. This script then builds flares.science including the wasm files, the static website and the server. Then it copies a systemd user service from the repository, and starts that user service, which runs the rocket.rs server.