Minecraft Leaks
[Download] SEUS PTGI HRR Test
Submitted by Database973, 08-08-2020, 09:22 AM, Thread ID: 178220
Thread Closed
08-08-2020, 09:22 AM
#1 This post was last modified: 20-12-2020, 10:49 AM by Database973
(This is on yiff.party)
So, as I talked about in the last dev news post, I've been working on this "Half Resolution Rendering" concept for quite some time. It aims to achieve higher frame rates by rendering the image at a lower internal resolution (half, per axis) and upscaling to full resolution.
This has been the most difficult shader project I've worked on so far. I know it seems ridiculous that it's taken so long to get to even a test version, but trust me, it's been very difficult. Unfortunately, there are a few things keeping me from saying that it was a success.
Firstly, due to the limitations in the programmability of rendering with shaders in OptiFine, it's impossible to do this half-resolution rendering and full-resolution reconstruction without paying an overhead cost that essentially doesn't go towards rendering the final image whatsoever. So, the frame rate gains are limited by this, unfortunately. I'm pretty surprised at how high this cost is. Don't expect this test version at 4k to run as well as E12 at 1080p does, even though they're rendering at the same internal resolution. This is a huge bummer, and it's worse than I had anticipated. If this weren't the case, the ideal nearly 3x frame rate increase would be possible as my initial testing indicated, but I've barely been able to achieve 1.5-2x. I know 2x sounds like a lot, but a 2x frame rate increase for an image that only has one fourth of the real information is, in my opinion, not a worthy trade.
Secondly, because a significant amount of frame time is dedicated to this reconstruction/upscaling filter, if you think about the rendering in terms of a ratio between the amount of rays per pixel and the frame rate (sadly I only recently started thinking this way), this version actually loses out. Because the image is being rendered at half resolution per-axis, the effective ray per pixel count is reduced by 1/4th, but the frame rate is not quadrupled. Far from it, especially with the issue I mentioned above. Rays are precious in real-time ray tracing. Rays are real information. The more rays per pixel, the better your image looks. When we're drastically sacrificing ray count for a vastly disproportionate frame rate increase (especially because of the above issue), the trade off just isn't worth it.
Yes, this version running at the same resolution as E12 will run at a higher frame rate, and when there isn't too much motion, it looks about the same. However, with a more dynamic scene where there are lots of disocclusions (newly revealed areas of the world that haven't been rendered in previous frames), you'll really see the reduced image quality. Not to mention that diffuse lighting takes longer to fade (to compensate for lower ray count), and reflections look noisier.
I really didn't want to give up on this, which is why I beat my head against it for so long. I just cannot find a way around these issues. I've learned a lesson with this experiment. I saw the red flags long ago, but the promise of the ideal outcome: 3x frame rate for little visual quality drop was too alluring, I just had to keep trying. The ideal implementation cannot be made because I lack the flexibility with OptiFine. At least I can say that I really have thoroughly tried everything within my ability to make this a success.
I really don't want to leave you all empty-handed for even longer. Though I am not happy with it, those who are curious and/or desperate for better frame rate can try it out for themselves. This version is essentially E12 with some minor fixes and HRR (Half-Resolution Rendering) implemented. I've seen anywhere from 1.3x to 2x frame rate increase vs E12, and this depends on your hardware and render resolution (crank up your resolution to see the biggest benefit). I haven't bothered specifically addressing AMD graphics cards, because I consider this a failure. Unless I receive overwhelmingly positive feedback, or OptiFine becomes a little more flexible, I'm giving up on the idea and going back to working on resource pack based voxelization and other core improvements.
If you're curious, I've added an option (Post-Processing>Anti-Aliasing>Skip All Anti-Aliasing) to disable all anti-aliasing and reconstruction so you can see the raw internal rendered image without any processing. I think purely visually speaking, it's a cool demonstration of how much information the upscaling filter is able to reconstruct. But again, I don't think it's worth the disproportionate bump in frame rate.
I'm sorry for the bad news, hope you understand.
PLEASE READ THE FOLLOWING REQUIREMENTS FOR USING THIS SHADER PACK!
Since different GPUs can compile shaders differently than others, you may experience compile errors (causes "[Shaders] Error: Invalid program..." messages to appear in the in-game chat).
If you experience compile errors and you're using an NVIDIA GPU, you can help me fix them by following the steps onthis page, in the "How to Report a Compile Error" drop-down section and sending me the log!
Compatibility with AMD GPUs is being actively worked on. You will still experience some minor visual bugs, and you may experience random crashing.[i]If you experience crashing while trying to load the game or enable SEUS PTGI, try doing so first in windowed mode, with a small window.[/i]
Compatibility with Intel GPUs is not guaranteed or planned at all!
Attachments (1)
SEUS PTGI HRR Test.zip (4.2MiB)
So, as I talked about in the last dev news post, I've been working on this "Half Resolution Rendering" concept for quite some time. It aims to achieve higher frame rates by rendering the image at a lower internal resolution (half, per axis) and upscaling to full resolution.
This has been the most difficult shader project I've worked on so far. I know it seems ridiculous that it's taken so long to get to even a test version, but trust me, it's been very difficult. Unfortunately, there are a few things keeping me from saying that it was a success.
Firstly, due to the limitations in the programmability of rendering with shaders in OptiFine, it's impossible to do this half-resolution rendering and full-resolution reconstruction without paying an overhead cost that essentially doesn't go towards rendering the final image whatsoever. So, the frame rate gains are limited by this, unfortunately. I'm pretty surprised at how high this cost is. Don't expect this test version at 4k to run as well as E12 at 1080p does, even though they're rendering at the same internal resolution. This is a huge bummer, and it's worse than I had anticipated. If this weren't the case, the ideal nearly 3x frame rate increase would be possible as my initial testing indicated, but I've barely been able to achieve 1.5-2x. I know 2x sounds like a lot, but a 2x frame rate increase for an image that only has one fourth of the real information is, in my opinion, not a worthy trade.
Secondly, because a significant amount of frame time is dedicated to this reconstruction/upscaling filter, if you think about the rendering in terms of a ratio between the amount of rays per pixel and the frame rate (sadly I only recently started thinking this way), this version actually loses out. Because the image is being rendered at half resolution per-axis, the effective ray per pixel count is reduced by 1/4th, but the frame rate is not quadrupled. Far from it, especially with the issue I mentioned above. Rays are precious in real-time ray tracing. Rays are real information. The more rays per pixel, the better your image looks. When we're drastically sacrificing ray count for a vastly disproportionate frame rate increase (especially because of the above issue), the trade off just isn't worth it.
Yes, this version running at the same resolution as E12 will run at a higher frame rate, and when there isn't too much motion, it looks about the same. However, with a more dynamic scene where there are lots of disocclusions (newly revealed areas of the world that haven't been rendered in previous frames), you'll really see the reduced image quality. Not to mention that diffuse lighting takes longer to fade (to compensate for lower ray count), and reflections look noisier.
I really didn't want to give up on this, which is why I beat my head against it for so long. I just cannot find a way around these issues. I've learned a lesson with this experiment. I saw the red flags long ago, but the promise of the ideal outcome: 3x frame rate for little visual quality drop was too alluring, I just had to keep trying. The ideal implementation cannot be made because I lack the flexibility with OptiFine. At least I can say that I really have thoroughly tried everything within my ability to make this a success.
I really don't want to leave you all empty-handed for even longer. Though I am not happy with it, those who are curious and/or desperate for better frame rate can try it out for themselves. This version is essentially E12 with some minor fixes and HRR (Half-Resolution Rendering) implemented. I've seen anywhere from 1.3x to 2x frame rate increase vs E12, and this depends on your hardware and render resolution (crank up your resolution to see the biggest benefit). I haven't bothered specifically addressing AMD graphics cards, because I consider this a failure. Unless I receive overwhelmingly positive feedback, or OptiFine becomes a little more flexible, I'm giving up on the idea and going back to working on resource pack based voxelization and other core improvements.
If you're curious, I've added an option (Post-Processing>Anti-Aliasing>Skip All Anti-Aliasing) to disable all anti-aliasing and reconstruction so you can see the raw internal rendered image without any processing. I think purely visually speaking, it's a cool demonstration of how much information the upscaling filter is able to reconstruct. But again, I don't think it's worth the disproportionate bump in frame rate.
I'm sorry for the bad news, hope you understand.
PLEASE READ THE FOLLOWING REQUIREMENTS FOR USING THIS SHADER PACK!
- Minecraft 1.14.4(older version compatibility is work in progress)
- OptiFine HD U F3 or newer
- Options > Video Settings > Details > Alternate Blocks:OFF
- Options > Video Settings > Details > Trees:FancyorFast(Smart may break lighting)
- Options > Video Settings > Quality > Natural Textures:OFF
- Options > Video Settings > Shaders > Shadow Quality:1x
- Options > Video Settings > Shaders > Old Lighting :DEFAULT
- Resource packs with custom block models will probably cause lighting glitches!!!!!!
- Block texture alpha is not considered in diffuse GI tracing, so doors and trapdoors don't let any light through their windows currently.
- Being underwater in ravines/caves shows light leaking, and ?glowing water fog. This is unavoidable currently.
- "Disco Floor" flickering artifact mostly seen in reflections (the new Secondary GI Samples option can help with this)
- Secondary GI bounces (2nd bounce and onward) can take a while to adapt to lighting changes
- Issues with the rendering of semi-transparent/translucent materials
- Lighting breaks often when using resource packs with custom models, a solution is being investigated!
Since different GPUs can compile shaders differently than others, you may experience compile errors (causes "[Shaders] Error: Invalid program..." messages to appear in the in-game chat).
If you experience compile errors and you're using an NVIDIA GPU, you can help me fix them by following the steps onthis page, in the "How to Report a Compile Error" drop-down section and sending me the log!
Compatibility with AMD GPUs is being actively worked on. You will still experience some minor visual bugs, and you may experience random crashing.[i]If you experience crashing while trying to load the game or enable SEUS PTGI, try doing so first in windowed mode, with a small window.[/i]
Compatibility with Intel GPUs is not guaranteed or planned at all!
Attachments (1)
SEUS PTGI HRR Test.zip (4.2MiB)
This hidden content has been reported as still working 0 times this month.
1 times in total
This hidden content has been reported as not working 0 times this month.
1 times in total
Users browsing this thread: 2 Guest(s)