I’m very sorry for what I have said. I just wanted to share RADIUS. I’m sorry >_<.
Another thing I wanna say, you did an awesome job on making this; but what is the difference in Ray tracing and global illumination? Don’t they do the same thing? This question got me really confused.
Nice work man. Keep working on this and we could see a game with a really distinct artstyle.
what is the fflag in question? I want to try this with my game
Here’s what I configured on my system. Use at your own risk, of course.
FIntTaskSchedulerAutoThreadLimit → 32
FIntTaskSchedulerAsyncTasksMinimumThreadCount → 14
DFIntCLI69398a → 14
DFIntRuntimeConcurrency → 14
Hello! Creator of RADIUS here
To be completely honest, calling it the “fastest” is there to grab people’s attention, but this does not belittle its speed. And in regards to the “quality over quantity” aspect, I completely agree with you! We have different visions.
I really advocate for a healthy community, and I really love seeing other people’s work on the subject. I really did not like the lack of accessibility to proper ray/path tracers, so that’s also another reason that I’m making RADIUS.
I’m a young person. I was naive and still am. Please forgive me if those buzzwords provoked you, in which case I will remove them from the post.
Thank you for the kind words; regardless of how you presented the initial post it is incredibly impressive what you’ve done and you definitely should be proud of that.
I am just a stickler for letting work speak for itself, and it’s hard to demonstrate the effectiveness of its performance if there’s no reference against other publicly available solutions if that’s what you initially claimed; it’s very exciting what you’ve done and I do believe your system will be up there, but it’s gotta have data to back that up if that’s how you wish to present it.
Bruh, since then was that??
I made a basic raycasting engine for fun some time ago, and I think it was using 8 or 10 of my 12 threads, but I ran it today, and it was using 3 threads, looking at the micro profiler
Parallel lua was already bad, due to its very significant overhead, but now it’s just garbage…
I know that trick, but it looks like garbage still. It’s great for faking lenses on cameras or other meshes like that, but for actual reflections like mirrors, it starts to fall apart. I also don’t like the viewportframe trick, because the graphics in viewportframes are different than the client’s graphics, and they can get pixelated and buggy when you move around.
Hello folks 
Just been doing occasional tweaks here and there; I’ve rewritten how the post-processing stages work so there’s now the ability to individually toggle the following:
that’s incredible. It looks so much clearer.
Looks like this is really shaping up. Looking forward to seeing just good this is at rendering quality compared to Roblox’s current systems. Just wondering, should this eventually be put into a game on Roblox, how do you plan to adhere to the 3 thread limit? Do you think you will have to sacrifice a lot of the quality?
Something about custom rendering engines in Roblox looks/feels different, and I don’t know why.
The 3 worker limit would require you to get creative to obfuscate Roblox’s arbitrary limitations.
I say arbitrary as any official documentation and comments from Roblox staff regarding this limit is incredibly sparse, and any request for comment gets ghosted by staff.
There is an engineer that responded here by essentially saying (And I paraphrase):
The system works, and it could definitely take advantage of the hardware, but we won’t publicise information that may change on-the-fly.
Personally the philosophy of writing parallel code is to ensure that you can maximise the performance out of the hardware you are running it on. It could be that Roblox is holding back the worker limit to retain parity with lower-end mobile devices so developers don’t end up making games that become too demanding for them; however this would be a fallacy since this kind of bottlenecking is already possible (And much easier to accidentally do by developers) by stressing out the GPU.
So if I was to make use of the renderer in its current state while upholding the 3-worker limit, I would disable both Global Shadows and Light Shadows, and set my game to take place at night/dark setting; perhaps taking advantage of horror-type games lending itself well to low resolution content.
(A relevant example of this combination would be REPO)
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.
