I see, it may just end up lying as a limitation of the engine instead of something that could ever change; although I hope Roblox listens to the developer community and eventually improves their multithreading system. Even better if we could run code on the GPU.
I guess you’ll just have to keep probing for any kind of openings to maintain the quality while keeping the performance tax at a minimum. Despite the limitations, this is still awesome.
Tweaked post-processing to claw back some more definition. It’s like trying to squeeze blood out of a stone.
Nice work!
Have you set the ResampleMode to Pixelate? I would think more people would prefer pixelation over blurryness
Wahh that looks fricking amazing!!
I take advantage of ResampleMode as the final stage of post-processing; So I can choose to use bilinear or nearest neighbour sampling for the output of the image with virtually no additional cost to the frametime.
Bilinear is good to use when the output resolution gets closer to the display resolution (In development I tend to prefer having it on at 480p and beyond), but I wouldn’t want to use it for example at 288x162, which is the resolution that the provided image is displayed at.
Hi folks! Here’s a list of things I’ve done with the renderer lately:
EditableImage Vignette Overlay:
Playing with EditableImages I decided to create a custom vignette overlay that matches the same resolution as the renderer, as well as respecting bilinear/nearest neighbour sampling. I’ve placed it in a separate ImageLabel over the renderer output as to not incur any performance penalty 
Studio Support / No Client Required:
The renderer is compatible in both server and client contexts by changing the RunContext property on only 2 of its scripts! Iterating has been important to me when working on this and now I do not have to load up a player client in studio every time I want to test something. I also recognise that this would be incredible to have integrated as a plugin should a game be developed using this rendering method!
Improved Scheduling / Reduced Input Latency:
By tinkering with the order of when the renderer begins processing a frame and by exploring Parallel Luau in more detail; I have created my own on-demand Serial/Parallel context switcher that doesn’t rely on multiple RunService events! This has enabled me to greatly improve load balancing during the raytracing process, granting better performance and matching input latency with Roblox’s own rendering pipeline.
x2 Render Quality Is Now Viable:
All the previous videos I’ve shown have had its render quality set to the base level (x1). Because of the improvements made to the renderer’s scheduling and various ongoing optimisations, I am happy to share the video below using x2 render quality
Another update; turns out I was processing colour information incorrectly!
For example, here’s how interior reflections looked about ~3 weeks ago. The walls into the corner had really noticeable colour banding.
Fast forward to today and here’s how it looks now!
Colours are much better managed and I can now rest knowing that it’s not being meddled with by processing things in the wrong order.
wow that is very impressive! do you ever plan to open source it?
