No TAA; while I tried exploring it in earlier iterations I decided that it wasn’t going to be the correct approach given my lack of prior graphics programming experience and also reservations that compute could be better used elsewhere.
I do perform frame accumulation to help reduce frametimes, and I perform some post-processing passes on it to remove any further artefacts than what you see in the above demo. I’m currently rendering 1 pixel for every 8 pixels which IMO is the absolute lowest ratio anyone can go by conventional means before the benefits cancel out and you would just be better off rendering at a lower resolution. But since frametimes have a direct impact on input latency, this approach is a win for realtime rendering. When the FPS gets high enough (60FPS is a valid target), these artefacts do diminish into obscurity.
Whilst DLSS is undoubtedly a better upscaler, using neural nets etc, it’s worth citing the similar ratio their lowest option uses while requiring costly proprietary hardware/software:
[ PIXELS : RENDERED ]
My renderer: [ 1 : 0.125 ]
DLSS Ultra Performance: [ 1 : 0.110 ]
Reading the room and saying to myself that I am working in an environment that is not ideal for graphics programming helps temper ambition regarding what techniques I implement, and encourages me to get some good experience on taking advantage of Luau’s functionality and optimisations in some key areas.
I finally implemented multithreading support, meaning that I can render 960x540 in realtime!
While Roblox’s live client by default limits Parallel Luau to 3 threads, I decided to see how far I could push this by derestricting the thread limit with FFlags, going from 3 to 14!
My CPU has 16 cores/threads but I figured that I should leave 2 threads for Roblox’s Render/Main thread and any other background tasks on my system.
Post-Processing just needs a little bit of tidying up to behave like before when the renderer was single-threaded, but that shouldn’t be too hard to do.
This still feels like Roblox graphics, even with the perfect raytraced reflections. I kind of like that
This feels like proof Roblox can do a little better with their reflections, instead of just reflecting the skybox. I feel that after Roblox optimizes their engine a little more, we could be seeing SSR or even RTR on higher graphics qualities in the settings menu.
RADIUS’ priority is quality over quantity (Pathtracing, Monte Carlo, 1000’s of samples per pixel).
For as much as I have made connections with other raytracer-folks in the community since making this project not one of us has come out swinging claiming to be ‘the fastest raytracer’; we just share our knowledge and help improve our low-level understanding of Luau in order to get that extra bit of performance out of our own individual solutions.
I’m doing this for fun, and eventually to use in my own future works off-platform, and Roblox has been a great starting point for that.
What I will say is that their post comes across as sensationalist claiming to be ‘the fastest raytracer’ since what they have created is a pathtracer; the differences are fundamental in that pathtracing increases more samples per pixel and spreads rays out randomly in order to achieve a ground-truth closer to reality.
If they claimed to make ‘the fastest pathtracer’, I’d agree if the material was available for all to use and validate themselves; but I feel that it’s being presented in a way that’s disingenuous to the average laymen who would need to go to google to understand the difference between raytracing and pathtracing.
So with that said, please don’t stir comparisons or competition, I don’t want any part in that.
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.
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.
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.
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:
Renderer: Smoothing
Removes significant artifacts from provided render
Renderer: Anti-Aliasing
Helps eliminate those jaggies
Renderer: Sharpening
Used to bring back some definition lost in the smoothing process
Roblox: Bilinear Filtering
Takes advantage of the GPU via Roblox’s ImageLabel for a ‘free’ final smoothing of the image; not recommended for low resolutions, but helps smooth things out beyond a certain resolution.
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?
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)
