There is no plan for that. We plan to keep energy conservation for regular material. And diffuse is encoded into as few bits as possible for efficiency so it would not allow a large value range.
Toon shader is different in that regard indeed, as of today and might change, considering the diffuse ramp that do not have any clamped color.
alright, it would be REALLY helpful to be able to boost the diffuse lighting on the toon BSDF for certain important objects/characters in stylized games that have a lot of dark areas
@SebHillaire Hello there 
Since Substrate now uses F0 and F90 for the reflectance, i had to convert my own material function for the Complex IOR (for metals via their IOR n and k values). I was made aware by other commenters on a Youtube tutorial about Substrate, that there is already a “Substrate-IOR-To-F0” node, for those, who want use IOR values.
My question would be, could you also include such a function for the “Complex IOR”, for metals? I attached my material functions code as a text file, if you want take a look at it.
MF_SubstrateComplexIOR.txt (203.3 KB)
@Suthriel Hello!
And thanks for the great suggestion! + an implementation
I have added a TODO for us to consider and review this to be added.
Hello! In our mainline, we added a “Substrate IOR-to-F0 (Conductor)” material function(counter part of the dieletric version “Substrate IOR-to-F0”). The sRGB to linear has been left out, but you can use the sRGBToLinear node if you want to have it. This will be available in 5.8.
Thank you for your suggestion!
/Charles.
@Charles That sounds awesome And i included that sRGB2Linear, because without it, the colors looked way off, way to bright. I first thought, that i needed the other node (Linear2sRGB), but somehow, that formula required the sRGB2Linear to look correct.
Here is a comparsion, left the same materials from the previous post, right its the same, but the sRGB2Linear is inactive. Looks wrong, too bright ^.^ Maybe you just add a note or description, that it might need the sRGB2Linear node to look right in some setups Oh, and we would need 3 sRGB2Linear nodes, since the nodes themselfes are just scalar, not vectors, so one node for each color would be required.
@Charles@SebHillaire
Hi! I am trying to replace tonemapper and struggeling to find right method to do it.
Should I keep the “Disbale Pre Exposure Scale“ Checked?
Should I multiply Pre-Exposure(Inv Property) with inputs and Pre-Exposure(Property) before output.
Should I gama correct tonamepped Color using pow(TonemappedColor, 2.2);
Custom Node Code:
// Inputs:
// SceneColor - float3 (linear HDR scene color)
// Slope - float3 (Default = 1)
// Offset - float3 (Default = 0)
// Power - float3 (Default = 1)
// Saturation - float (Default = 1)
// Constants
const float3x3 agxInputMatrix = float3x3(
0.842479062253094, 0.0423282422610123, 0.0423756549057051,
0.0784335999999992, 0.878468636469772, 0.0784336,
0.0792237451477643, 0.0791661274605434, 0.879142973793104
);
const float3x3 agxOutputMatrix = float3x3(
1.19687900512017, -0.0528968517574562, -0.0529716355144438,
-0.0980208811401368, 1.15190312990417, -0.0980434501171241,
-0.0990297440797205, -0.0989611768448433, 1.15107367264116
);
// AGX EV range
const float minEV = -12.47393f;
const float maxEV = 0.526069f;
// Step 1: Apply input transform matrix
float3 transformedColor = mul(SceneColor, agxInputMatrix);
// clamp min to avoid log2(0) with epsilon
transformedColor = max(transformedColor, float3(1e-6, 1e-6, 1e-6));
// Log2 encoding
float3 evColor = clamp(log2(transformedColor), minEV, maxEV);
float3 normalizedEV = (evColor - minEV) / (maxEV - minEV);
// Polynomial contrast curve approximation
float3 normalizedEV_sq = normalizedEV * normalizedEV;
float3 normalizedEV_quad = normalizedEV_sq * normalizedEV_sq;
float3 contrastAdjustedColor =
+ 15.5 * normalizedEV_quad * normalizedEV_sq
- 40.14 * normalizedEV_quad * normalizedEV
+ 31.96 * normalizedEV_quad
- 6.868 * normalizedEV_sq * normalizedEV
+ 0.4298 * normalizedEV_sq
+ 0.1191 * normalizedEV
- 0.00232;
// Apply ASC CDL look adjustment
float3 luminanceWeights = float3(0.2126, 0.7152, 0.0722);
float luminance = dot(contrastAdjustedColor, luminanceWeights);
float3 adjustedColor = max(contrastAdjustedColor * Slope + Offset, float3(0.0, 0.0, 0.0));
adjustedColor = pow(adjustedColor, Power);
float3 tonemappedWithoutOutputTransform = luminance + Saturation * (adjustedColor - luminance);
// Re-apply output transform matrix; no gamma correction since UE does sRGB encoding
float3 TonemappedSceneColor = mul(tonemappedWithoutOutputTransform, agxOutputMatrix);
// Clamp before gamma (important to avoid NaN)
TonemappedSceneColor = max(TonemappedSceneColor, float3(0.0, 0.0, 0.0));
// Gamma encoding
TonemappedSceneColor = pow(TonemappedSceneColor, 2.2);
// Final output
return TonemappedSceneColor;
I am also curious to know if there will be AGX tonemapper in future to choose. because it would great to have option to choose different tonemapper that supports post process effects like color lut, vignette, sharpness out of the box.
Feature Request:
it would be great to have built in outline as a part of this node instead of bsdf node.
This way we can use otline on upcomming toon bsdf based material and materail with other bsdf. we can mix toon shaded material and realistic with outline common in all.
and it would be nice to have a outline features like:
Hi,
Tonemapping: this has nothing to do in this substrate thread. You will have to look at our OCIO pipeline I guess to replace the tonemapper.
Yes, outlines is a feature we would like to eventually provide built in with the toon BSDF. Thanks for the suggestion!
There will be an implementation that will have to scale between our supported platforms. The parameterization you propose does not fit in the legacy GBuffer so that is already out of the range of possibilities for some platforms. Let’s see, this is still TBD - no ETA.
Thanks for pointing out the OCIO.
regarding outline, wouldn’t it be possible to make the outline part of the main node so we can use the outline feature with any shader, not just toon bsdf, just like the AO input, which is part of the main material node?
I looked Into OCIO and it’s for Color space but I want to replace the tonemapper using the option “Replacing Tonemapper“, blenable location in post process material. I am curious if my code is good and especially if I need Gamma Correction at the end. and also if there is better way to make it compatible with post process exposure setting so it scale with it.
And I found a bug:
When I set the Scalar parameter’s UI Control type to Enumeration and assign an Enumeration. it adds an extra option with the name of Enumeration asset along with a post fix “Max“.
Feature Request:
Please make all the post process effect intact with the replace tonemapper feature. right now effects like local exposure, vignette, sharpen and color grading and film control breaks when i set my post process material’s blenable location at “Replacing Tonemapper“. if this is intentional than there should be a blenadable location to replace tonemapper where every post process effect and feature should woork instead of breaking.
Hello developers, I recently tried the “Ray Tracing Quality Switch” node on Substrate slabs, and it gives an interesting warning: “Please reach out to the development team for feedback and if you want support to be added.”
I also played with other switch nodes:
Are those features coming soon or on the roadmap? It would be great to use switch nodes for both visual effects and performance. I also hope for a “static switch” that can be toggled in material instance.
Hello,
Yes some switch work and some do not. The main reason behind that is “can we know the substrate tree statically when we translate the shader”. If the choice is dynamic it cannot work because substrate can only deal with static material topology.
Quality Switch and Static Switch should work if you do not use a dynamic branch (dynamic test at runtime but static selection). I will check if there is an error or something I forgot about the error you mention for StaticSwitch.
Static parameter switches should also work.
RayTracingQualitySwitch for instance cannot work since at translation time we do not what the shader will be used for. It only once it is compiled for your GPU that we will know that and it is too late for any high level work (substrate or any other) at this stage.
Thank you for reporting: I will update the error message to be more specific for the Switch nodes.
Edit: I confirm that the only switch node supported are the following (tested for 5.8)
the other one cannot be supported. I will udpate the message error message. Otherwise you have the select node that can be interesting to select a substrate subtree (parameter blending only) based on a bool. That can be driven dynamically (but only one slab can flow through each selectable path).
Thanks for a detailed explanation! I’m glad to hear that static switch gonna work in 5.8
Here’s another tiny issue about user experience - some substrate nodes have been localized, but we can not search for their original English names.
(Maybe this is not the best channel for UX feedback, but blueprint editor has a good multilingual search function. I’d like to see that in material editor)
It’s really helpful that you clarified that, thank you. In that case, do you have any tips for winning back RT performance while using substrate? I know a lot of automatic simplification is already happening below the hood, but the RT-quality switch replace node made a big difference, and I’m concerned that it won’t be possible to make certain scenes performant/in-memory.
@piggest_pig Thanks for that extra note. This has now been reported.
@jblackwell All substrate material in raytracing land are fully simplified to a single slab as you noticed. As in: all operators are forced to be parameter blended (not for path tracing). So performance wise it should not be too bad.
For game performance at 60hz:
Thinking about it further, maybe there is something we can do to have a node where the substrate tree is evaluated for the non RT path normally, while the other path is fully simplified anyway for RT so we will know it will be single slab + features tracking. Such node will however not work for Path Tracing (or we would have to introduce another tier of material simplification with specific substrateTree and processing in bettwen Normal and FullySimplified). Some avenue but TBD.
This leads me to a dumb Q… Functionally what’s the difference between these two (a binary value picks between T/F), and will support for the bottom one be added?
BTW, otherwise, thanks for your help and responsiveness.
All the 3 nodes on this image are supported and can flow substrate data.
Top Switch node + StaticBoolParam == bottom StaticSwitchNode as far as I know.
Good day,
Simple issue here I have not noticed before which hopefully has simple answer.
Examples below show the following:
-A non Substrate material which blends colours using fresnel. Exaggerated Normal Texture to show its effect.
-A substrate material with the same inputs but it seems to ignore the PixelNormals and hence the Colours only blend based on geometric Normals.
I must be doing something wrong but cant figure it out. Would love some help. Cheers
UE Version: 5.7.0
Hi, my architecture studio is slowly switching to 5.7.4, and I am testing all the master materials we used in 5.6 to see how they behave in 5.7.4 and if any modifications are needed. Before asking my question, I need to explain the lighting system that we use, we have created a custom plugin to serve our needs for lighting which consists of two sky meshes, the visible one is called the backdrop mesh and the one contributing to the lighting is called the sky mesh. In all situations, we must be able to see the backdrop mesh, cause there are scenarios in which we have to reduce the saturation of the skylight (to achieve the lighting we are looking for) but we don’t want the visible sky to become desaturated. By default, whenever we have a substrate glass material, we see the sky mesh (which is understandable since the sky mesh is affecting the reflections and global illumination) but to bypass this, we used to enable “is thin surface” for the glass material and reduce the IOR to 0. This effectively made the glass invisible keeping only the reflections, and the best part about it was that we were able to see the backdrop hdri instead of the sky mesh through the glass. Meaning that changing the sky saturation did not change the visible sky that we see through the glass. However I noticed in 5.7 this behavior is changed. Regardless of any value I set for the glass material, I cannot see the backdrop mesh, I only see the sky mesh. Beside that, changing the IOR to 0 will somehow make the glass material to emit light. So we made a new master material for the glass to check if we are missing something. We realized if we set the MFP scale to 1, and base color to black, we can prevent the glass material to be white and emitting light, however this does not solve the issue of not seeing the backdrop mesh. So my question is, how can we get the same behavior we had in 5.6? (Short explanation for the attached photos: The picture where the sun is not visible through the cube, we are looking at the skymesh through the glass material which is not the wanted behavior, the second screenshot shows the backdrop mesh which has the sun which we would like to see). One final note: we only use path tracing.
