XenonofArcticus

I recently realized that while I knew we had invented something new in the 90s, and kept it close to our chest, it was actually probably a VERY long time before anyone else ever reinvented screen-space reflections.

LONG article, with source code and graphics references.

Disclosure: Yes, I did use AI tools to help me write this, especially to author the diagrams and to explain some things and find references that frankly, it did a better job than I could on. The content is mine and human, just like the original algorithms. This article is the product of several weeks of research, digging and writing work on and off, so it's not a one-shot "slop" product.

In 2015, Elite: Dangerous used a tester video on their launcher menu screen that appeared to show a "dark wheel" space station in an unknown star system. The Dark Wheel is one of two Shangri-La places in the game lore. Known to exist, but never discovered, and it is claimed it is the gateway to the second secret location, Raxxla. The video shows a starfield AND a slice of the game's Milky Way galaxy disk, which is actually rendered by the game engine to reflect real stars and galactic material.

In 2019, I speculated on using Machine Learning to capture images from around the game galaxy and train a Deep Learning image model to predict galactic location, but I didn't pursue the endeavor because of other distractions that hit my life and the world around me not long after.

I revisited this in 2026 and figured out I didn't need machine learning to draw some conclusions and then hit on a realization that led to a breakthrough. I successfully localized the position AND pose of the in-game screenshot video to a specific star system, 11 years later, using conventional computer vision and celestial vision navigation methodologies.

This is a long post. Get your caffeine or Leestian Evil Juice ready.

Chris "Xenon" Hanson here.

Take a seat over there.

And then go read my reply above about how AI was and was not used to write the article.

I'm looking forward to your competing article that does it better without using AI.

Go look at the actual git history.

Slughorn is coded by hard-working humans. Sure, we use LLM tools for some investigation and development, but this is not an AI slop project. It's been in the works steadily since not long after Eric announced the patent release, grinding through improvements with every hour of the day we can dedicate to it.

Every important line of code here was written, tested and is understood by Cubicool, the lead programmer (there are some LLM-generated ancillary parts of the codebase, and I think git shows those).

Article author here (not the lead programmer on the Slughorn project tho).

Yes, LLMs were used to help write this article and there are tells. I can smell them too.

However, as several have picked out, it's not a one-shot LLM Leeeeroy-Jenkins writing process. I am a domain expert in these sorts of things, and the source of much of the information, concept and organization of the article.

I wrote a bunch of notes and material. I then used an LLM trained on my own styleguide from my writing to organize, expand and fill in places where it was mostly gathering info from other sources. Then I went through THAT and rewrote a bunch because it doesn't always follow directions and color within the lines. It took several days of iteration to put this together even with an LLM assisting.

So, there are parts that are entirely human. There are parts that I felt were less important for me to write personally that I let the LLM writing stand, with some edits.

It is a HUGE piece of work, and writing it all by hand would have taken more time than I could dedicate to it because I have to make a living too.

I should go back and de-LLM it some more, but legit our time is spent working on Slughorn to make it better. I welcome all suggestions for edits and errata on the article (or on Slughorn itself). Our goal isn't to trash other rendering methods. It's not a competition. The post is intending just to fairly compare all of them so people can decide what technique is best for their use, because Slug/Slughorn ISN'T the right choice always, and there's so many techniques with different tradeoffs that it can be hard to grasp where your own use-case falls and how to decide.

Also, Cubicool, the primary developer of the Slughorn code will probably chime in below to address some of the more code- and feature-centric responses.

(Finally, cheers to Eric L. for releasing the Slughorn patent that made this all possible.)

Hey all, we announced the first public exposure of our "Slughorn" open source (MIT) implementation of Eric Lengyel's formerly-patented Slug graphics algorithm.

It isn't specific to any GPU backend (OpenGL/Vulkan/Metal/DX/whatever), but supplies API-agnostic data and shader support so you can connect it to any GPU API, render engine, game engine, scenegraph, toolkit, whatever.

A demo using OpenGL is included in the core repository to show how it's done.

A sister project, osgSlug, integrates Sulghorn support into OpenSceneGraph.

Further support for Vulkan, DX, Metal, VulkanSceneGraph, Unity, Unreal, WebGPU (Webasm) etc are all possible, but we wanted to get something out there where it stands now and see what people want to make of/with it.

Everything so far has been self-funded, pro-bono by my company, AlphaPixel software development, and given away, without restrictions or holdbacks, under the MIT license.