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.
7 Likes
Yes, I was having trouble putting my concerns into words, but I have the same concerns… This is not a good sign.
3 Likes
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!
4 Likes
I’m glad that Roblox gives us the option to preserve the old Roblox look.
3 Likes
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!
12 Likes
Even without using that, I can already tell he used ChatGPT. 
3 Likes
i have a feeling this is the start of more lightning effects and possibly one day in the future scriptable shaders
1 Like
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).
8 Likes
If possible, maybe add cool legacy lighting effect? It’s almost the same as compatibility except…
… except it’s memories
7 Likes
old lighting was so hacky back then, you could’ve used transparent neon to blur screens, good times
7 Likes
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!
6 Likes
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.
34 Likes
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.
13 Likes
If this change enables you to build out other features of the lighting engine like making realistic lighting better, I find it a good update.
Games who will have the most work with this change are probably classic style games with huge maps and lighting.
2 Likes
Oh neat, I actually love the way voxel lighting looks, I’ve been wanting to recreate it in a different game engine just for the fun of it.
How does voxel lighting work actually?
I couldn’t find much information about it when I searched for it.
It’s cheap to compute and it makes lighting look very stylized.
I recall that computing voxel lighting is so cheap and fast that it can even be done on the CPU.
Compatibility Lighting, with all of these lights having a brightness of 5
Voxel Lighting + Migration changes, same brightness
Voxel Lighting + Migration changes, and lights adjusted in an attempt to look like how it was in Compatibility
It doesn’t have the same effect I was going for. I’m trying to achieve a similar style of light & light colors that certain games like Garry’s Mod (and by extension, the Source Engine) use, but having to switch to Voxel, even with the migration implementations, doesn’t make it feel the same now.
The purple lights in this castle were based off of the lights in the rp_richland map, especially the purple bath-tub (don’t have any images for that):
What can I do to fix these lights? One user replied that I just have to change the bloom, but I don’t use a significant amount of bloom that would cause this, rather Voxel likes to severely magnify and create a glowing effect on parts that have a bright light on them, and I can’t remove that glow effect without turning down the light’s brightness significantly.
5 Likes