Remove tonemapping from MeshBasicMaterial

[bhouston]

Description of the problem

We ran into this issue with Clara.io. We want to be able to show specific color widgets for manipulation, while on top of a Tone Mapped scene. But we do not want these specific color widgets to be tone mapped themselves. Currently the tone mapping is applied on the MeshBasicMaterial in this line here:

https://github.com/mrdoob/three.js/blob/dev/src/renderers/shaders/ShaderLib/meshbasic_frag.glsl#L52

I would like to remove this.

I believe this is justified because MeshBasicMaterial is actually an unlit material thus tone mapping is sort of illogical on this material anyhow.

This will affect how basic materials look, but I believe it is the correct choice.

This is especially a problem on dark scenes where one wants to increase the exposure but it will then bleach out the manipulator/widgets.

Three.js version

• Dev
• r80
• ...

Browser

• All of them
• Chrome
• Firefox
• Internet Explorer

OS

• All of them
• Windows
• Linux
• Android
• IOS

Hardware Requirements (graphics card, VR Device, ...)

[bhouston]

The other alternative is to make tonemapping optional on materials via a define that is controled by a per-material toneMapping = true boolean. We can do that. I am not sure it is needed because MeshBasicMaterial is actually an unlit material, it has an explicit color that should just be respected -- or at least that is my interpretation of it.

[mrdoob]

The other alternative is to make tonemapping optional on materials via a define that is controled by a per-material toneMapping = true boolean. We can do that.

I think that sounds good.

Otherwise, I can easily imagine the situation where someone is using MeshBasicMaterial in a lamp and tone mapping the whole scene. It would be weird if suddenly the lamp didn't matched with the rest of the scene.

[JustASquid]

I'm in the same boat now with UI elements using MeshBasicMaterial that are being tonemapped. Was a fix or workaround ever put into place?

[WestLangley]

@bhouston Is this still an issue for you?

We decided early-on that tonemapping should be set at the renderer level uniformly across all materials. Is material-specific tonemapping desired now? Seems like overkill to me.

Yet, having a per-material on-off switch seems odd to me.

Removing tonemapping from MeshBasicMaterial is an option, as you suggested.

[bhouston]

I think if there is consistent demand then we make an option called .toneMapping =true/false on materials that allows you to opt out.

[bhouston]

It all depends on whether you are trying to match an overlay color or an existing color in the scene directly. If you are trying to match an existing color in the scene, then you want it tone mapped, if you are trying to map an overlap color, then you want it to not be tone mapped. Thus I see both use cases here.

[WestLangley]

@bhouston I do not have a problem adding such a feature. It is the API that I have a problem with.

renderer.toneMapping is a type of tone mapping;
I don't think material.toneMapping should be a boolean.

Maybe this?

material.toneMapped = false; // default true

I assume it would be a property of Material, so all materials would have this feature?

[bhouston]

Sorry, I undercommunicated. I agree, it should be material.toneMapping = true/false to allow a material to opt-in or not of tone mapping. We are on the same page.

[WestLangley]

@bhouston ... but it doesn't seem to me you agreed with what I wrote... ?

[mrdoob]

material.toneMapped = false; // default true

That sounds good to me.

[WestLangley]

OK. Will do.