SEUS PTGI E9 Dev News (Patreon)
Content
Hey, all! Here's what's going on with the development of SEUS PTGI E9.
Something I've talked about for a long time is the issue of ray/path tracing against blocks that aren't shaped like a full cube. Lots of other issues have taken importance before this, but now it's finally time to address it!
I've been worried about implementing this since the beginning. Since ray tracing is an iterative process (checking each block along a ray to see what it is, then treating it accordingly), you need to be careful about how much work you do for each iteration step, or things can slow down quickly.
For blocks that aren't a full cube (fences, slabs, stairs, etc.), the situation arises where you need to not only determine whether the current block is air or solid, but you need to actually figure out how the ray travels through that block, and whether it hits a solid surface and should stop (like hitting a slab from the top or bottom), or whether the ray misses the solid surface (like passing horizontally above a slab) and should continue searching for a collision. This work needs to happen on every iteration, which is why I've been spooked every time I thought about implementing it.
I've done a lot of thinking for a while about the most simple/efficient way to do this, and as you can see, I've come up with something that works. Note that screen-space tracing is OFF in the above screenshot, those nice shadows from the fences are all properly ray traced against the fence geometry!
This system works by assigning an ID to any occupied block that contains special geometry (each unique geometric case has its own ID). Then based on that ID, hard-coded geometry represented by bounding boxes (nice that Minecraft is made of boxes for this!) is collided against within that block area. Information is gathered about where the ray hit, and if it hits a solid surface, we've found our collision point and we can stop iterating. With an ID system like this, we can skip doing extra work on full-cube blocks just by checking its ID and seeing that it doesn't contain any special geometry.
With this method, not only are all lighting artifacts fixed on things like slabs and stairs, but their geometry casts correct shadows and lighting without needing to do screen-space tracing.
The drawback of this approach is that block geometry cannot be dynamically determined, which means it needs to be hard-coded for known cases (for example, we know that slabs are a half-height box, so we can hard-code that in). Because of this, I want to expose this part of the code to anyone who might be willing to dive in and create their own hard-coded geometry (for resource packs that have custom block models). This code will be contained in its own separate file, with extensive documentation written inside to ease the learning curve. I will permit the modification and distribution of this one file in SEUS PTGI's license, that way people can share this file with their own model definitions. Then, to install this "mod", all you'll have to do is replace this file with the modified one.
Now, as more models are added, things will slow down. This is because GPUs are not perfect at determining what code to run or skip based on dynamic conditions. For now I've got all variants of slabs, stairs, and fences in (stairs and fences are probably the most complex blocks in the game, since they have a lot of potential states), and it's sitting at around a 12% overall reduction in performance. This is likely to get worse as I add more models (trap doors, doors, pressure plates, carpets, etc.). However, this is a first implementation of the system, and it may be optimized as I continue to work on it. Either way, I will provide an option for the user to enable or disable this feature according to their preference. Whether it's on or off by default will depend on how big of a performance impact it has.
So, this is the main focus of E9, and I wanted to share my progress with you. However difficult this feature is to optimize or finish will determine how many other new features will make it into E9.
Oh, and one more thing, the developer of OptiFine has made a change to how geometry shaders work, enabling compatibility on AMD graphics cards!!!!! I'll be ordering an AMD graphics card soon so I can get PTGI fully working. I have no idea how much work this will take, I'll keep you guys updated on this process!
Also, thank you for the positivity and kindness! It really helps me stay motivated and encouraged. You guys are the best!