Are we ever gonna get an increase in light ranges? Maybe even remove the limit all together. Because I find a max range of “60” way too small. It would complement the new lightning system quite well too.
4 Likes
not this again
Compatibility is the only way to remove some annoying features of Voxel+ and make older games look right
Whats next, removing Voxel? Compatibility existed because it ran off the same engine as Voxel so took virtually 0 maintenance. It being removed makes me concerned for Voxel’s future. Compatibility and Voxel are the last renderers that look like the silly block game roblox used to be
15 Likes
You really see it in the highlights. Awesome looking stuff!
1 Like
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?
6 Likes
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