Hello there! Wait... it's been how long?? Well, here's what's been going on in my world.
I have continued to work on SEUS, game development, and ReShade shaders, but development has definitely been slowed by mental health issues. Recently things have gotten better with a medication change, but I'm a little hesitant to celebrate too much; those of you who have struggled with mental health know it's never a linear journey. Also, if you've ever looked at my code, I'm sure some of you can tell I very much have ADHD. It can be a superpower at times, but lately it's mostly been a very frustrating obstacle, and I can't take stimulant ADHD medication. If any of you guys out there have ADHD tips, I'd love to hear them.
So, specifically about SEUS, I'd like to share a bit more about what I've been working on, although I should say that I'm still really unsure if this new tech will meet my goals in terms of performance, so I can't promise this will pan out!
I've been working on a custom software ray tracing solution that is able to dynamically and arbitrarily store geometry within the scene into a sparse data structure that is then traversed on a per-quad basis. This means a few really awesome things.
Firstly, the area in which ray tracing data is stored has been increased significantly. With the latest version of SEUS PTGI, the area is 335x335x335 centered on the player, which is about 10 chunks. So, anything further away than 10 chunks isn't captured and cannot be traced against. With this new sparse data structure, the volume encompasses the entire world height with a maximum distance of 32 chunks from the player! So basically, as long as your render distance is 32 chunks or less (which is probably more than most people should play at for performance reasons), the entire scene can be traced against! This has some performance problems with complex worlds or very high render distances. I'm thinking about implementing some LOD system that simplifies far away blocks/geometry to compensate for this. Past a certain distance, do we really need to store and trace against every single quad?
Secondly, yep, since ray tracing data is stored on a per-quad basis, all geometry is dynamically captured and can be traced against. This even includes entities! If this new tech pans out, PTGI will no longer rely on hard-coded block types and shapes. Any block, any custom model from a resource pack or a mod, and all entities can be traced.
There a few caveats. Since there is no single atlas holding the texture of all entities, entity textures cannot currently be displayed correctly in ray tracing. I have tried a few attempts at building an atlas at runtime but I haven't found an efficient enough way to do this yet. Also, there is a global limit to the amount of geometry data that can be stored, and there's a limit to the number of quads that can be traced against within a single block. That means that resource packs with lots of complex models with a lot of elements or extremely complex worlds will fill up this data and cause visual errors. I'm not sure if anything can be done about this. Also, for performance reasons, only quads that are rectangles (all corners are right angles) can be represented properly. This covers nearly all types of geometry encountered in Minecraft with one exception being the side of a flowing liquid. Storing geometry on a per-triangle basis essentially doubles the storage requirement of the geometry and halves the speed of ray traversing said geometry. Since this new ray tracing solution is already going to be slower than what is currently in PTGI, I feel that the rectangle-quads-only approach is best.
Arbitrary per-pixel emission is also working. Any object can have emissive pixels that will give off ray traced lighting. So, light sources simply work by putting emissive pixels on the object itself.
The exact speed difference between this new tech and the existing tech can vary quite a bit, but it is generally slower. Tracing one ray per pixel is probably going to be too expensive, especially when there is a lot of geometry present in an area. So I need to find a way to make tracing fewer rays still look acceptable. Per-pixel emission makes this problem worse, since light sources can be much smaller, and the smaller the light source, the rarer it is that any ray is going to hit that light (resulting in extremely poorly resolved lighting from these sources of light). So, we need a way to trace fewer rays and get better resolved lighting than PTGI has been capable of so far. The best option for this is ReSTIR, which is basically a fancy temporal and spatial ray sharing algorithm. My implementation is mostly done but not quite there yet.
The ReShade shaders are in a state where I'm not terribly happy with them, but I'm going to release them anyway as a very alpha version. I may just be creatively frustrated with them, if you guys end up liking them I'll definitely try to polish them up!
Once again, thank you so so much for your continued support!!! These past few years have been really rough for everyone. Your understanding of my challenges and acceptance of my unusual creative process is absolutely invaluable to me.