This is very confusing. How would I go about creating a decal that, when 2 of them intersect, they blend rather than adding up?
For example, I wanted the intersection area to be the same color as the non-intersecting area, and translucent. How?
Using either basecolor+opacity or just emissive color doesn’t achieve the look I want.
1 Like
Did you ever find an answer to this? To get decals to blend together aside from adding together.
1 Like
any news on this?
3 Likes
Turn off tangent Space Normal. This Solved the blending problem
2 Likes
How is this still a problem? Epic, time to do something, we’ve waited long enough…
6 Likes
please Epic … Solve this
Only in UE5.1 is working !
Wrong and Nothing in UE 5.2 and 5.3
Please Epic?
7 Likes
Is this new system for manually applying dbuffer decals now completely broken in 5.2? Even if it did work you then can’t also use decals normally on that mesh? What a stupid system. Broke all the existing stuff for a less important feature. Just add the decal blend modes back instead of removing them without replacement pending some “future work”.
2 Likes
Hi all,
Let me see if I can try to help out with some of the things being discussed here.
For the record, I don’t think this question is affected by the decal blend mode changes that happened in UE5 that originally started this thread. For emissive decals, they have always been purely additive in both UE4 and UE5 no matter what the decal opacity is. I’m not saying that’s a good or bad thing, but that is simply the behavior of emissive decals. (There are certainly situations in which that is desired behavior.) For opacity-masked base color it is expected behavior that they would stack on top of each other like that, as that is the expected behavior of opacity-based compositing of decal channels.
If anything, the only way I can think of do to this at all is using the DBufferTexture nodes and disabling Receives Decals. With that approach you could build up a mask from multiple decals using your own blending logic and then use that mask to modify whatever channels you want. Note that you can treat the DBufferTexture channels as arbitrary projected data, once you’ve turned off Receives Decals. The ApplyDBuffer function is just a reference for emulating the regular decal behavior.
Yes, you can just regularly apply decals without using DBufferTexture nodes or disabling Receives Decals. If you have a case where this isn’t working please provide more details.
Can you provide more details about what isn’t working for your case?
Decal Blend Mode chris murphy methode dosnt work in ue5.2 and 5.3 and working only in ue5.1
in ue5.2 , 5.3 nothing effect in surface object !
1 Like
Yeah this isn’t working for me either, thought I’d broken something when upgrading a 5.1 project following Chris Murphy’s setup. Can’t believe this hasn’t been fixed yet.
Edit: not sure if this is the correct way to do it or is helpful to you, but it seems the problem for me was trying to use Dbuffer input with combined material attributes (as shown by Chris Murphy in 5.1, which works great) I am now using Dbuffer input with the individual material attributes and was able to achieve the same effect I had before
Looked into the code of Material.h
UPROPERTY(meta = (DeprecatedProperty, DeprecationMessage = "No longer used."))
TEnumAsByte<EDecalBlendMode> DecalBlendMode;
Looks like it’s not coming back.
Also dbuffer interaction (response) seems to have migrated to the receiving material itself
Sorry for long answer
So… Epic being epic, I’ve tried in 5.4.3 and if you left empty any of the material inputs then they didn’t get written.
BUT! if you are defining any property on a set material attribute node, or INSIDE A FUNCTION, those would get written. This said, If you create an empty material, and just plug in a normal texture as output, it should work as a normal decal only.
For some reason the compiler just recursively explores all functions but doesn’t checks if they are finally connected or no.
Another workaround if epic would like to fix this, would be to give the community control over each independent GBuffer alpha channel.
They already store three float4 buffers, BC, Normal, and packed Metal/Specular/Roughness. and they just get the opacity input and use it for every alpha channel of those buffers instead of give the option to define them separately, which, would also fix the issue by giving control to the users.
So it’s quite an easy fix, just need to see if they fix it