the [RAY] stat in both videos are wildly different numbers, and are mostly responsible for defining the frame rate. The latest video serves as an example for motion clarity even at low fps compared to previous methods of optimisation. Certain optimisations are enabled, removed, or scrapped whilst working on this while I iterate on the system in order to make it more accommodating for new features etc.
1 Like
So from reading both the RetroRaster and this thread itâs safe for me to assume that multi-threading is a pretty hard task? Glad that it wouldnât just be me that was confused when reading the related docs.
Nice optimizations with single threaded, too. Making one of these systems is way beyond my current knowledge lol.
I dont like multithreading. Thats what stops my fluid simulation in its tracks. Im getting great performance but multithreading is needed to make it better.
1 Like
I canât give my thoughts on multi-threading yet as I havenât written any code for it, but from my experience rendering out a pixel is independent from one another, so I think it would lend itself well to splitting the work into multiple threads.
I have researched parallel concepts like parallel slowdown and workload distribution (Making educated guesses by allocating certain amounts of work to threads based on previous frametimes).
I will be excited to share results once that is implemented!
1 Like
Today I am happy to share the progress of my renderer! I have been heavily optimising the renderer over the past few days, and as a result I am now able to run the renderer at 320x240 in realtime on a single thread!
Watch towards the second half for further stress-testing where I enable reflections on all surfaces.
5 Likes
Good mindset itâs a shame seeing people tell you basically not to bother but programming isnât even at itâs peak right now. The roblox engine is still an engine and we have no idea the future add-ons. Small steps like this will be looked back on in those future years as the backbone to future projects. Itâs simple RND. Without that you have no future or that future will be very very far from your grasp. Right on man!
Also bro no one is applauding you enough on the fact this thing is single threaded. In my head there is a lot of potential in optimization with the experimentation of multi-threading.
Idk how long itâs taking you to generate. In your video it seems at just a click of a button at such low resolutions itâs instant. People should understand on a more typical rig the raytracing is constantly running thatâs why itâs expensive.
Simply change the context of why you use raytracing and you can find some very performant methods.
May this could help. I donât care about making open worlds so I took inspiration from things like Yakuza with a split up open world. like a puzzle piece but you go through certain doors to get to the next coordinated puzzle landmass. I can pack a lot of usually expensive functions into these landmasses because well itâs happening on such a small scale and if youâre moving through the world well these threads are eventually entirely turned off. The expense is a short burst of experience. Rather than thinking the entire universe has to run everything at once.
Take a game like deepwoken where donât quote me but I think they said majority of their lag is from npcs. Those npc threads cover the entire world and are running no matter how far away you are. They donât turn off. By the nature of the game technically you canât turn them off.
What Iâm thinking with this is what if you can isolate the raytracing. I know you wrote of isolating it to gui stuff but why not isolate it in world. Raytracing only happens for specific windows. Specific pieces of glass. Specific something specific that is really only turned on for but a second. The fans will still be rolling like a chopper but nothing will melt.
This is off the dome but maybe a character has the ability like in cyberpunk frying your brains. The effect changes the resolution of your sight and warps the world adding raytracing to certain aspects of vision(parts of the world) for but a second. I say this too because your FPS drop off is not as insane as I thought it would be. I know some people are sticklers for fps but this is roblox a majority of people are not reaching 60 frames consistently. And just because gameplay is under 60 frames does not make a game unplayable especially if that frame drop off is conditional and not happening for long. Just a thought.
3 Likes
Looking over this thread, I think itâs amazing how itâs developed already and Iâm excited to see it develop in the future!
With the given performance on a single thread right now, it looks pretty smooth, considering (Iâm assuming) thereâs no other major systems in play like there would be in a standard Roblox game. I noticed you already mentioned Parallel Luau for multithreading, which could also add a significant improvement, but I was just wondering how you planned to optimise this further? Do you think Parallel Luau and any other optimisations could make this an option to run on lower end devices, or is it just not worth it as those devices will likely be using a lower quality anyway?
Do you plan to release this as a community resource when itâs done? I know a lot of people would definitely find it useful.
either way, I hope to see it in flood escape 2!
1 Like
Thanks for the words of encouragement!
More progress is still being made regarding single-threaded performance. Iâm likening the performance demands of the renderer to be plotted on an exponential graph, and Iâm constantly exploring ways to help prevent creeping further up that curve.
The high resolution renders arenât instant, but with the realtime optimisations itâs still pretty quick. Iâm checking in with friends as to what their performance is on their devices and it gives me a better idea of where the renderer stands.
Framerate dropoff is very important to consider and a good point that you made. Generally we want to avoid as much fluctuation in that as possible, so what needs to be controlled is the amount of rays per pixel.
The biggest things that currently affect performance is the portion of the screen occupied by materials that add extra rays (Transparency, reflectance), and the object density within a given volume (This can be easily assumed as Robloxâs raycast function having to consider more geometry).
My current philosophy for optimising has been to use as minimal code as possible within performance-critical loops; which, really, is the whole thing as we need everything to be as quick as possible from the start of processing a frame, to presenting it in the EditableImage.
Parallel would definitely make it run better on lower-spec devices; Iâm able to get away with developing in single-threaded only for now due to how capable my system is, but with the correct cross-threaded communication implementation, it should also be minimal overhead.
My main concern is that Roblox only provides 3 workers to the live-client, which is what the OS then assigns to a core/thread. Why this decision has been made I do not know; in the context of preserving battery life on mobile devices, I understand; but not in a desktop space where I have 16 cores ready to be used.
Using something like Bloxstrap would be the only user-friendly way to get around this limitation via the correct FFlag, and even then, that limits the user-base to windows PCs only.
2 Likes
Exciting progress: Skyboxes!
This helps make the world much more believable 
I am currently able to store and process 512x512 skybox textures with no measurable effect on frametimes vs the solid-coloured test skyboxes which I used before.
12 Likes
Wow man this is impressive! Iâve been following this project since the start and you have come a long way!
Keep it up man.
also flood escape 1&2 were my child hood 
1 Like
Whoa! What did I miss?
This is a huge advancement, hoping for multi-threaded soon.
1 Like
We got lights into the system!
11 Likes
wow. just add a tonemapper. and youâve got something equivalent to the FIB 3 lighting with ambient colors set to 0. insane stuff, man.
i also made an attempt, and that didnt really go too well
by the way, what optimizations have you done for this?
2 Likes
This is amazing! I have never seen anyone on Roblox make a rendering engine with those kinds of features ever with an added bonus of being in REAL TIME! I also have made a rendering engine that path traced instead of raytraced. Itâs for sure slower than what you have created, but it does have a denoising algorithm with good edge detection. Soooooooo itâs optimized? If youâre curious, you can find my post on what I made through my profile I am not that active on the devforum.
Anyways, that video you uploaded to youtube was the last thing I expected to see, and it actually made my jaw drop.
One of my thoughts is to make a version that focuses on full path tracing to create renders?. I love indirect lighting, and I wish Roblox had a basic implementation of it. I bet from this start, it could be really fast.
1 Like
Behold, the multi-threaded upda- Oh, just kidding! 
That will have to come another time.
In the meantime, hereâs whatâs new in this video:
-
Tone Mapping
This allows us greater control over how colour information (Particularly when multiple or intense light sources are involved) is mapped to the display! Thanks @akwardlol1029 for the feedback. -
Custom Upscaling
This allows us to vastly increase our FPS; simultaneously improving response times and enabling convergence into full quality rendering whilst camera/scene movement is minimal. -
Realtime single-threaded 640x360 output
This is the big one. After learning Robloxâs live client has a 3 worker limit for Parallel Luau, I had to think what could be done to reduce compute before moving on to more complex technologies and optimisations. Itâs possible that we would be able to triple the framerate in the video when switching to multi-threading. This is probably the most that I can reasonably do for optimising rendering in screen-space, and so in the future, optimisations in other spaces will be made.
See the results for yourself:
1 Like
Looks really nice man!
Iâm going to be completely honest the first few seconds (when it was loading) I thought that was it.
1 Like
Wow⌠this is phenomenal! Really, really, really good work, and I am astonished just looking at this thread. If ROBLOX is ever looking for new engineers; I presume youâre top of the list. But seriously, itâs sometimes nice to consider the "what if"s of ROBLOX, like what if ROBLOX had GPU access. Projects like these would benefit greatly.
However⌠considering security risks, abuse issues, and difficulties to do it (you cnaât just âabracadabra gpu nowâ), I assume ROBLOX is never implementing it. You should definitely write some serious renderer outside of ROBLOX (if not already) - it would look crazy good.
1 Like
Thank you! Iâve learned a lot during this and I am very excited about where this could lead.
In some regard I understand developers not having GPU access. Itâs a lot easier for Roblox to iterate on their multi-platform distributions by not having to document and preserve GPU-facing features, especially when GPU architectures and APIs can change drastically across all platforms.
I canât wait to see multithreaded performance - and I was wondering if you had some kind of temporal AA? or just frame accumulation artifacts, since there is ghosting/past frame flickers, so. If you made TAA nd it was competent thatâd be sick (though, itâd be some freak approximation albeit Iâm assuming youâre using editableimages so you have pixel access).
Perhaps upscalers? nearest neighbor sampling, or something of the like (but thats just an assumption from me)
1 Like