Compatibility Lighting becomes Retro Tone Mapping [Sunset + Migration]

I mean… if you just run a quick command bar snippet to turn off CastShadow on all parts then you automatically get that behavior out of the box since Roblox’s avatar parts will have CastShadow on by default?

-- Select the Workspace or something else that contains parts.
local target = game.Selection:Get()[1]
assert(target, "Nothing selected!")

for i, desc in target:GetDescendants() do
    if desc:IsA("BasePart") then
        local model = desc:FindFirstAncestorOfClass("Model")
        local humanoid = model and model:FindFirstChildOfClass("Humanoid")

        if not humanoid then
            desc.CastShadow = false
        end
    end
end
1 Like

that can be a pain if you copy stuff to workspace a lot

This isn’t an excuse for Roblox to retain legacy rendering tech if it’s making things difficult to maintain and upgrade.

The entire point of compatibility was that it used the same engine as voxel, just had some tweaks

Providing a halfbaked replacement for the “low maintenance alternative” that exists because they wanted to replace Legacy with something easy to maintain is not excusable

The situation has changed, due to further iterations being made to the lighting system under the hood. They will make more sense in due time.

The effort costs of maintaining compatibility mode with this new direction in lighting is exponential, with diminishing returns that weren’t worth the effort or performance compromise to support.

Ultimately the artistic direction of your game should be controlled by you, and not by an opaque flag that deliberately kneecaps features that are objectively better and used by a majority of modern Roblox devs.

5 Likes

Then use the colorgrading, that has the same effect. It practically is compatibility except in a new form and with no kind of clamping available.

Can’t that be achieved by changing the Ambient/OutdoorAmbient properties, though? Those aren’t being affected by this change.

1 Like

thats what the script changes

i now have to find new math formulas to make sure it isnt too yellow at night with the new color values

And as I said, this change won’t suddenly make scripts not modify those fields anymore. You shouldn’t have to make any changes to those scripts either unless they were optimized for FIB’s tone mapping.

Voxel + retro tone mapping is already nearly identical to Compatibility, yet you seem to only be concerned with Voxel without it, which has been a thing for years.

This is a common point that many in this thread love to use. But you can also look at it like this: if, internally, the two are nearly the exact under the hood, then what’s the point of having both as separate options? It’s only extra unneeded bloat getting in the way of better things.

1 Like

Ultimately the artistic direction of your game should be controlled by you, and not by an opaque flag that deliberately kneecaps features that are objectively better and used by a majority of modern Roblox devs.

The issue here is Roblox does not offer this control for all forms of lights, lights that overlap with each other can not have the overlapping portion darkened for example. Yes you can modify the game to remove scenarios where this happens but it’s unnecessary work and will likely break no longer maintained games.

Bro don’t talk about bloat in the engine that has like 5 ways to access Workspace.

no? in my testing the retro tone mapping is very off when migrating so this will mean the scripts need adjustments

Unless your game already had loads of settings altered before the change, it shouldn’t look different whatsoever.

i do change a lot of settings from default since im going for a certain aesthetic

Compatibility has a lot of post processing disable which gives a raw look (also handles colors way differently which is another issue since the tonemapping doesnt look the same color wise)

Hi @KiwiMilks,
Do you have screenshots or details you could share with us on the severe artifacts you are seeing? The common solution to overshadowing is indeed to disable shadow casting for the main object causing the problem, but we can look if there’s anything else at play for your place or alternative solutions we could suggest (you can also message me and @ItsRainingPixels in DM if you prefer).

Hey @AdvancedOpenGL,
The Retro ToneMapperPreset is really the identical same tone mapper used in Compatibility. Color variations would likely come from changes in the lighting (eg. no brightness clamp, shadow isotropy).

Would you be able to share with us some screenshots of the color issues you’re facing and highlighting the areas you find problematic, so we can help pinpoint what might be happening and possible solutions, please?

2 Likes

You should not see any difference to your experience’s performance under Voxel and it will be the exact same performance profile (Voxel and Compatibility are the same technology under the hood and therefore performs the same). Let us know if you’re experiencing anything different!

Most of it is accurate to Compatibility but some parts of it look like Legacy Lighting.
We should probably have two ToneMapperPresets which should look like Compatibility an Legacy.
(even tho they are similar)

Looking side by side the reason it looked “off” to me and the reason why I was complaining is that fog seems to be a bit different + shadows being way darker is whats causing the color to be off (i’ve already fixed all the issues and migrated to Future on most of my games so here is a side by side in a basic Compatibility game I have)



In the first image the platform and water seem mostly the same minus the lighting messing it up
In the second the water color is noticably different (possibly due to brightness differences?)

The “off” seems to be that special effects are ramped up which changes how the game looks a decent amount

Here is the place I used if you want to mess with it (its just a reupload of a really old version of NDS from 2014)
Link: Natural Disaster Survival 2014 - Roblox