You really see it in the highlights. Awesome looking stuff!
We plan to support this mode as well as Voxel and Compatibility for the foreseeable future.
How long til the Voxel technology gets âsunsetâ? 2 years maybe?
While this is a cool instance in concept, please dont just treat this like fonts and never allow developers to create their own tonemapper layouts.
Having Compatiblity work alongisde future/shadowmap sure will be interesting though.
Yes, I was having trouble putting my concerns into words, but I have the same concerns⊠This is not a good sign.
Well I guess itâs time for compatibility to go now. Really like the replacement for it as Iâve wanted the compatibility tonemap to be used in other lighting technologies for quite a while.
Now with that out of the way, canât wait to see the new voxel lighting engine next year!
Iâm glad that Roblox gives us the option to preserve the old Roblox look.
I got over 40 subplaces and their lighting brightness breaks because Lighting.Brightness gets modified by a script. Is there a way so the Lighting.Brightness adjusts automatically to the voxel format?
Considering that, unlike Compatability, Voxel lighting is part of the same rendering engine as Shadowmap and Future, I donât see that happening short of a new âFuture is Brightâ scale replacement of the rendering setup of the engine. Why, you may ask?
A brief explanation:
The only difference in terms of function between Voxel and Shadowmap is toggling if both sunlight and directional light sources (SpotLights, SurfaceLights) cast defined shadows based on shadow-mapping or if the voxel shadow casting methodology (on a 4x4x4 grid) that gives Voxel its name. This isnât too dissimilar from how most rendering works in other similar rendering engines that are found in other engines and software.
Although this similarity already exists, there exist at least 3 further pieces of evidence that support my claim that the three remaining lighting engines are intrinsically linked in such a manner that it seems unlikely that Voxel will be deprecated/sunset any time in the next few years:
- As one can see when adjusting the graphics level of the client/editor (
game.RenderSettings.QualityLevelorgame.RenderSettings.EditQualityLevel, respectively) when using eitherShadowmaporFuturelighting technologies, the visible impacts of each technology change based on Graphics level. More notably, this appears to come in the form of both a full reversion to Shadowmap and then Voxel as you go down in quality settings - with this being the primary way in which graphics settings are most significantly able to impact rendering compute load with either engine.
A brief list of easily observable changes easily observed by graphics level in Future lighting technology - does not include all changes
- Your mileage may vary, but on my hardware (GTX 1660 Super, 64GB DDR4, i5-10400), with the base technology set to Future, these lighting feature transition points are (Mipmaps Excluded):
- Graphics level
21toggles⊠honestly? Not entirely sure - aside from LoDs/Mipmaps, thereâs some clues that I can find via static frame analysis that it may toggle certain features such as more accurate Anti-Aliasing. - Graphics levels at or below 19 use less effective Anti-Aliasing than is found on higher settings.
- Graphics levels below
16do not render DepthOfField. - Graphics levels below
12have a reduced range for rendering ambient occlusion. - Graphics levels at or below
11disable most Future lighting technology features (physically accurate lighting), drastically changing the appearance of neon material and the brightness of environments - with all future lighting being gone by graphics level10. - Graphics levels at or below
10appear to more or less act like shadowmap/voxel, with accuracy at range decreasing with every subsequent decrease in level. - Graphics levels at or below
09no longer render in High Dynamic Range. - Graphics levels at or below
08have a reduced rendering range for ambient occlusion on materials. - Graphics levels at or below
06disable the rendering of metallic/reflective/smooth surfaces found in Future lighting - resulting in metallic/reflective/smooth objects appearing as they do in Shadowmap/Voxel. - Graphics levels at or below
05disable ambient occlusion for the Normal PBR channel for MaterialService, and appear to also disable any form of shadowmapping at all for SurfaceLights. - Graphics levels at or below
04disable the Normal and Roughness PBR channels for MaterialService, and disables reflections based on metallic/reflective/smoothness seen in Voxel/Shadowmap. - Bloom is disabled at or below graphics level
02.
- Graphics level
-
The broad level of feature parity between these three technologies points towards the three being developed more or less as presets/variants of a single overarching project - that which has previously been labeled as Future is Bright. It likely would be highly impractical to develop these not in tandem with one another - especially since, as those who have been developing for long enough will know, that is how they were initially created - as a project built upon the results of a Hackweek project that happened between 2015 and 2017.
-
Certain sections of the more complex technologies exist in the render stack in the less complex technologies, with features such as EnvMap persisting in VRAM in Voxel lighting, and in certain circumstances influencing actual environmental lighting.
Of course, all of these should be no surprise - after all, early on, a massive amount of transparency was given to developers on what was being done with rendering. On the comparison page for the website for the GitHub repository originally used to release test builds of FiB following RDC 2017, one can see the reasons why they decided on the current hybrid system - and what compromises were taken to ensure that it was viable for the platformâs average user to run. This page provides a moderately technical explanation of how Voxel lighting works - and how the other two technologies have been built on top of it. Although there have been many changes since the creation of that final public explanation, many of which have solved some of the issues with Shadowmap (Especially Skylight visuals and Global Illumination - which, although by no means perfect, are far more advanced than they were in late 2018.)
Overall, this just very lightly scratches the surface of the way in which Roblox does rendering (based on what I can find through my research) - the level of complexity and work that has gone into the rendering engine on Roblox is enough to boggle the mind and fill dozens of presentations/publications (literally! @zeuxcg, who was responsible for starting and shipping 10 years worth of changes to Robloxâs rendering (among other things), has several excellent presentations and publications that you can watch/read to learn more about rendering - theyâre linked on his website here. - and I donât see the path set forth all those years ago changing anytime in the next few years.
Improvements will be made as time goes on - this is a step in the direction of some of the most long-requested features for the engine to date, after all. Rendering, as with most things in such a complex environment as a game engine, is a matter of picking what is worth supporting, and what is worth cutting in order to allow for progress. This has happened before - and this change will finally free some of the long-standing barriers to improvements that have disrupted progress in improving rendering in-engine.
Although I feel that there is definitely merit in allowing for more granular settings to be configured by developers for the existing engine most notably, altering diffuse/lightgrid/shadowmap/envmap configs in a much more granular manner (or disabling any/all outright within a scene), I also feel that such changes will inevitably come based on updates such as this allowing for previously unavailable levels of control over things such as tonemapping.
For better or worse, you canât rebuild a building to reach modern standards while a building that was built under design considerations that no longer are impactful stands in the way.
This has been a gross oversimplification and this post has rapidly grown to reach the length I have gradually become notorious for over the course of the two to three hours Iâve spent writing it.
I hope this serves as helpful to someone, at least. If youâd like to learn more about rendering, thereâs plenty to see here on DevForum and elsewhere created by current and former members of the rendering team at Roblox - itâs worth looking at them if this post has interested you.
To the current rendering team at Roblox, thank you for your hard work. (and sorry for clogging up your discussion thread) - very excited to see what changes are in store for us to see for the first time at RDC this year!
Even without using that, I can already tell he used ChatGPT. 
i have a feeling this is the start of more lightning effects and possibly one day in the future scriptable shaders
Another example of the differences:
Compatibility:
Voxel + Retro Tone Mapping:
Itâs about the same except the addition of more shadows (See castle on the right).
If possible, maybe add cool legacy lighting effect? Itâs almost the same as compatibility exceptâŠ
⊠except itâs memories
old lighting was so hacky back then, you couldâve used transparent neon to blur screens, good times
This is just plain wrong. Compatibility, as outlined several times by former rendering engineer zeuxcg in 2019, was explicitly designed to be a part of the FiB rendering engine, as they could not afford to maintain Legacy. I have also seen decompiled engine code that shows that the bulk of the changes Compatibility make are extremely low-cost. Removing it is an absurdity and directly contradicts the reasons given when it was first added.
Yes, it has been long-requested that developers can no longer clamp the brightness of their lights and shadows to more temperate levels. Totally!
I knew there was something off about that paragraph lol
I was afraid this would happen sooner or later.
Once again, Roblox announces that it will remove another much-used feature with only a half-baked replacement available for people to use.
Correcting colours (or, as an aesthetical preference, disabling HDR) is only one part of the reason some developers continue to use Lighting.Compatibility. Believe it or not, some of us actually like its clamping behaviour for lights and decreased shadow intensity! If you are to go through with this, at a minimum, we need settings to clamp light brightness and shadow intensity to our preferred visual preference.
Removing functionality with limited or for some purposes, borderline no replacement at all, is NOT the definition of making ââimprovementsââ to your lighting system. The whole reason Compatibility exists at all and was even created is because it was low-cost to maintain compared to the Legacy lighting code stack.
If the Roblox of 2024 cannot maintain âlow-costâ features introduced by the Roblox of 2019 any longer, why should developers maintain their commitment to the platform?
No. Once again youâre pushing forward with a change that nobody asked for that threatens to cripple the aesthetical design painstakingly devised by developers over the course of the past 11 years since Dynamic Lighting was first introduced.
Roblox must introduce functionality that restores the ability to clamp light brightness whilst expanding the light radius, and ensure that the achieved result is 1:1 with what we could already accomplish before this pointless removal.
Worth noting that since the technology was first introduced, it was already massively levelled down from its accuracy to Legacy in early 2020, so I guess Roblox never were all that committed to what they told developers at the time anyway. Great way to double down on what has been an objectively poor year for developers and players alikeâŠ
So why remove it? Compatibility merely disables aspects of Voxel internally. Some of us are old enough to remember that this much was made clear in 2019:
Evidently, shadows also look worse in the post-migration part of this as a result of force-enabling anisotropic occupancy. Again, you seem to forget that many people choose compatibility because of the behaviour it has with lights and shadows.
Overall, great work guys! Superb way to re-affirm your commitment to developers at a time when⊠Oh, people are already losing faith in you.
Cruel and unneeded change at any cost appears to be the trend of 2024.
Yet another useless update, WHY?? It can be very difficult to replicate what compatibility looks like with voxel. Please think before you go through with this, or create something more similar.