Question Any (better) alternative to Decal Projector for decals?

I've been using the Decal Projector since I migrated my project over to HDRP, and I've generally been frustrated with it compared to the decal component I was using under the built-in renderer. There are two major issues that bother me about Decal Projector, but I currently don't know of any way to address the issues (even in terms of buying a better decal component for HDRP.) The issues are:

1. No ability to limit the decal to specific objects. For example, I add an explosion decal to objects that are hit by an explosion. But this decal will paint all nearby objects, which looks really weird if some objects are moving. Ideally each decal would draw only on as single object, so the object can move and bring the decal with it.
2. No angle limit on the decal. If a decal is placed near multiple surfaces, such that the decal is normal to one surface, it will look terrible if it happens to overlap another surface that's perpendicular to the normal. Here the decal is bleeding onto the wall:

I don't need triplanar projection here, I just wish the decal would simply not draw on surfaces if the difference between the decal's orientation and the surface's normal is higher than a certain angle. I can limit this ugliness to a degree by making the decal very thin, but then things don't look good if the surface is just a little uneven.

The decal system I was using under the built-in renderer had features to address these issues, but Decal Projector doesn't. And from what I've been able to look up, Decal Projector seems to be very low on the HDRP priority list, so I'm not optimistic the HDRP team is planning to improve it in the foreseeable future. That leaves buying a replacement, or building a replacement on my own. However, I don't see anything on the Asset Store that doesn't simply reuse Decal Project without adding any new rendering functionality. And in trying to build my own, it seems that using a "Normal Vector" node in a Decal shader doesn't give me the normal of each pixel, and instead just gives me the normal of the decal itself. That is, I seem to get the same value from the Normal Vector node for every pixel, regardless of whether it's a pixel on the floor or a pixel on the wall. So, I can't use the dot product of the pixel's normal and the decal's normal to try to apply an angle limit.

So, anyone have any advice on a better approach to decals that addresses one or both of these issues? Thanks.

 

Regarding the normal vector issue in a Decal shader, to clarify that, I made a very simple Decal shader, which just sends the normal vector into the base color:



I then put the decal next to a corner. My expectation here was that the normal vector would correspond to the individual pixels being painted, and that the color on the wall would be different than the color on the floor. Instead, it seems the normal vector is the same for every pixels painted by the decal. For example, here's the decal near the corner, with a sphere within its bounds:



I would expect that sphere to be painted in many colors, given the various normal vectors each pixel should have, but it ends up having a uniform color.

Does this seem like a bug? I'm inclined to report it, unless someone thinks it's really supposed to work this way.

 

Thats not how it works, youre outputting the normals of the decal volume geometry (which are just not set, thats why you end up with result like this i guess). To get the correct scene normals, you'd need to sample them from GBuffer, but i dont think theres a node for shader graph to access GBuffer. You can try writing your own, _GBufferTexture1 texture is what you need to access.

 

Thanks for the reply, and that disappointing. I tried seeing if _GBufferTexture1 lead to anything, but either I don't know how it works (which is true...) or it's not accessible from ShaderGraph. I tried comparing the Normal Vector node output (which should be the orientation of the decal as a whole) against the GBufferTexture1 value, hoping I could adjust opacity to hide the decal if the Dot product was small enough. But the decal still paints every surface the same, regardless of orientation of the decal or curvature of the model:





I'd still be interested in knowing if anyone else knows of a way to limit decal drawing on surfaces based on relatively angle of the decal to the surface.

 

You cant just declare it as a property and hope it will appear there. You'd have to remove that property and use custom function node for that instead. Also normals in that buffer are encoded in some way, you'd have to encode them as well.

 

Fair enough. There have been some other properties I could just declare like that and they worked like magic, such as _MainTex for UI shaders, but maybe that's an exception. (I think I remember some LWRP shadergraph shader that also just declared _CameraOpaqueTexture as a property to get some data as well.)

So I tried to create a custom node to sample _GBufferTexture1, but that just results in 'Undeclared identifier _GBufferTexture1'. There's some information on acessing GBuffer here: https://forum.unity.com/threads/hdrp-post-processing-shaders-accessing-gbuffers.726158/ , including some mention of a DECODE_FROM_GBUFFER. And it's not related to shader graph, and I'm not sure what of that code can be moved into a custom function, or if that's even reasonable, or what the gbuffer data ultimately represents once decoded. So, clearly out of my depth on accessing this data.

And bug picture, it seems that so far there are no suggestion of other approaches than the Decal Projector, which is also disappointing, but maybe it's representative of how this isn't yet a fully mature system on which people can develop complex custom functionality, and it'll just take some time.

 

Thank you, I really appreciate the detailed breakdown. I wasn't aware of that table before, but I guess that explains why I could never apply decals to transparent objects back when I was using Deferred Decals under the built-in renderer. Thanks for the breakdown of the tradeoffs, which I wasn't aware of. I'm glad to know it's still a topic of investigation, even if it's probably not happening any time soon.

 

Not a decal expert here, but in my limited experience in decals, mesh decals are sort of useless and has very limited use cases. It is a cool feature, but I wouldn't trade it for transparency support of decals or angle fading. If DBuffer is already a full bus, maybe it is better to change to cluster...

As for HDRP decal system in general, I think there should be a color override like the fade override. Color can be changed via the shader at the moment, but I often found my decals need to change colors to match surface color. This forces me to make multiple copies of the same material with different color variations.

 

May I ask what were really gaining with mesh decals? Im finding the angle stuff pretty annoying, as it applies to so many normal usages ...

Am I missing some great common use case for mesh decals?

 

@SebLagarde

It's hard to understand what you intend to actually work with decals. We spray copious amounts of bullet holes and scorch marks in our level using deferred decals (in the standard RP) currently. These obviously have alpha (transparency). Is the HDRP going to support this essential approach?

 

Thats not what they mean when they say transparency support. They mean the support for transparent objects to receive decals, something you can not do with regular deferred decals.

 

So, despite losing angle support that I had with deferred decals under the standard RP, I was really happy that HDRP decals worked on glass. @customphase already answered it correctly, but in HDRP the decals themselves can certainly contain transparency, whether they're projected on opaque or transparent objects. Here are two decals, one on a wall, and one on a window:



Under the standard RP, the decal on the glass would not have shown up, as deferred decals apparently don't draw on transparent objects.

 

That's exactly my point, the guys at Star Citizen use it to retain high resolution texture details while keeping the workflow and performance fast enough. But this is assuming the underlying texture is monochromic. eg. metal surface with more decals covering the surface.

To me it sounds very case specific.

In most use cases, outside of SC, the unlying texture is not monochromic, and hence usually have high enough textures and most details if needed, rendered with decals. Hence my point, very limited situations where it actually benefits.

 

I'm somehow failing to grasp what the difference is of a decal that's used for rendering a bullet hole vs. one that's a detail on an object like used in Star Citizen. Sure one is dynamic, and the other probably static.... but other than that, it's still the same thing rendering wise, is it not?

 

Bump, still no alternatives to the current HDRP decal. I need a solution that works with very steep angles and can be animated. As our project mature, we came to the point were we really see the limits of HDRP which limit us in graphical quality and flexibility.