What I am trying to achieve is set the decal map on top of the detail map. Currently what occurs is the detail map draws on top. Secondly would changing the order work with detail map on UV2 and decal map on UV1?
Thanks
It would indeed seem more logical to me that the decal map be displayed after the detail map.
cc @PatrickRyan for his opinion.
I think we could consider this a bug if we had to change it. We could also add an option for the user to choose to draw the decal map before or after the detailed map, but I donāt know if thatās a good idea / if it would be much use?
No, this would only change the uv set used by the textures, but the drawing order would remain the same.
Thanks for the response. 
It would be used by me for sure. I need to be able to determine the sorting order of the maps, and right now the detail map draws over the decals which hides the decals behind it. So not sure how useful decals are when detail maps are enabled because you cant see them.
@Baktrian and @Evgeni_Popov, I agree that the decal should be drawn after the detail map for color data. In the case of non-color data, however, there may be an argument for either order and we would likely need to offer the user the ability to render in either order and/or mix them. For example, if a bullet decal has normal information, you may want to render that after the detail normal texture so that the original surface normal is adapted to the bullet hole changing the normal.
On the other hand there may be a time when you want both as may be the case with spray paint. You may want to modify normals around the edges of the paint area to imply a substrate added to a surface, but you may also want it to conform to the underlying surface normals in the middle of the decal. In this case you may want to mix them, or even render the detail map second so you donāt obliterate the normals from the surface.
I believe at this point that our decals only handle color data, but I could see adding non-color data to the system in the future. It may be worth more consideration on if we just change the render order as a bug or if we expand the feature to allow the user to control the order, in which case we retain back compat as the default render order will be what it is right now. Thoughts?
@PatrickRyan @Evgeni_Popov
when you say our decals only handle colour data, do you mean when the image does not have transparency? Is this related to the fact that the detail map shows the texture as black and white? I wasnāt sure why it did this eitherā¦Looks see-through as well.
I think there are many use-cases for having either the decal map drawn after or the detail map, and its just different for every case.
For something like the AO map, that absolutely has to be drawn last since AO should cover any albedo texture, decal or detail map, but that does not make sense in terms of the detail map, as that can be sometimes paired with the albedo texture. For example, further brick details on a brick wall.
The decal is something you expect last because it is being stuck on top of an object.
For all these reasons, I think it would be easier to just let the user decide.
@Baktrian, when I say color data, I am specifically talking about factors and textures that affect the color of the material instead of data on how light bounces off it. Color data is albedo and emission where non-color data are things like normal, roughness, metalness, ao, etc. Your example of AO coming after decal is another good example, but I donāt know if we would consider bundling AO with a decal. If we expand the system to include normal textures with decals, I can see an argument for AO, but adding AO from a decal may be too little ROI in terms of performance to really support it.
Right now, our decal system supports only color data in the form of albedo and in that sense we could easily say that decals should always render last and bug the feature. But if we want to be future proof while protecting back compat, it may be worth letting the user control the order of the decal, but that would be a question for @Evgeni_Popov as it may also cause a lot of complexity which might make supporting the feature difficult. I think this is a call he should make as the potential for code complexity is not clear to me.
My example of the AO was just an example of ārender orderā on the material.
I donāt mean to bundle it with decal.
Iām starting to understand the difference here. The decal map in the example i posted uses the MeshUVSpaceRenderer, and the albedo texture is where the resulting decal and its texture is updated. So it makes sense the detail map is on topā¦
Still in the case of decal maps, there should be a way to set that on top.
I think supporting both cases should not be too difficult.
I have created an issue to keep track of it:
In the meantime is it possible for me to temporarily patch it somehow, so decals draw on top?
This PR will add the new feature:
It adds a new applyDecalMapAfterDetailMap property to the standard / PBR materials (default: false).
Amazing work @Evgeni_Popov. Looking forward to testing it out once its merged.
Have tested the build on my own fork and found one small issue with it.
Seems like the decal map still has a shadow of the decal map underneath it.
Could this have anything to do with blending?
Yes, the decal does not replace the albedo color, it blends with it.
Maybe we should add a āblendā / āreplaceā mode, but in any case that could only apply to the albedo component, so would we get the expected result if we only replace the albedo texture and keep the other contributions untouched (bump, ao, emissive, etc)? What do you think @PatrickRyan?
@Evgeni_Popov or @Baktrian Iāve been going around in my head about the implications of blend/replace. Do either of you have a PG that I can use to test with to make sure I understand the challenges here?
Actually, the āblendā mode is using the alpha component of the decal texture for the mix:
surfaceAlbedo.rgb = mix(surfaceAlbedo.rgb, decalColor.rgb, decalColor.a);
So, I think itās already doing what we expect: if decal.alpha=1, it replaces the albedo color with the decal color, else it is blending according to the alpha value.
What we see in the screenshot above is the effect of the final normal on the surface color: the detail normal is blended with the bump normal and is used in the lighting calculation. Itās a bit strange in the screenshot because the detail map is not really a detail map, it does not add small scale details as a detail map should.
Im not sure if this is correct so I will post a playground with the updated code later today so it can be tested on a variety of decals, detail maps and meshes.