Same here.
does anyone know if lightweight is going to have decals? I know is forward rendering so im not sure if it can
Right now when you check decals scripts/shaders on github there is info only about HDRP, @SebLagarde are they HD only?
Iām not the HD dude so I canāt say much about how things should work / the issues you are seeing. I can say though that for now decals are HD only.
Yes, Decals are HD only, here is more details about the implementation. Have in mind that this is WIP, thus why you may experience different problem. We currently use a DBuffer approach, but this may evolve in near future.
Cons of classic deferred decal
-
Donāt work in forward (Opaque/Transparent)
-
Applied after Gbuffer pass so it doesnāt affect GI
-
Requires blendable uncompressed GBuffer
-
Want to avoid to make a blendable buffer as it puts more restriction on GBuffer:
-
Requires blendable data in RGB channel
-
Requires no compression (like no normal compression to be blendable)
-
Requires to know where element are stored in GBuffer to do mask correctly (HD allows users to configure their GBuffer as they want; we use abstract function to sample and store attribute)
-
Combinatorial explosion of blend mode when we want to support several case (multiply albedo, lerp normal, add smoothnessā¦) which is a nightmare with an unknow Gbuffer (as users can change the layout).
-
Difficult to deal with multiple materialId in Gbuffer (what to do when blending specular color, whereas the material is Subsurface scattering type ?)
The DBuffer approach
Restrict decal attribute to: diffuse albedo, metal, normal and smoothness (metalness workflow)
-
RT0: diffuse, opacity in alpha RT1: normal, opacity RT2: metal, smoothness, opacity
-
Decal can blend only a set of attribute if desired
Restrict blend mode to Lerp
Step:
-
Full Z-prepass
-
In deferred
-
In forward there is a full z-prepass anyway.
-
Render deferred decals buffer (diffuse, specular, smoothness, normal) - This requires additional memory to store the attributes.
-
Gbuffer pass that sample the decals buffer and lerp them (limitation of blending mode to restrict combinatorial explosion but also to match PBR requirement). The GI and emissive are correct.
-
Deferred Lighting
-
Forward pass with opaque that correctly handle decal (i.e switching between deferred and forward donāt change the result for opaque).
Pros:
-
Compatible between deferred and forward opaque
-
Decals support GI
-
Particles/Postprocess could affect the DBuffer to allow others effects
-
No restriction on Gbuffer
Pros/Cons
-
Require additional depth prepass
-
There is a an obvious CPU impact here in case of deferred (forward have a full depth prepass anyway)
-
However on GPU it can be a win in case of deferred depends on context
-
With heavy Gbuffer pass (like with scene where objects use a lot of LayeredLit shader), depth prepass is a win.
-
With a lot of alpha tested object, doing prepass with alpha test objects is a win
-
Doing a full prepass may allow to re-organize the rendering to throw async computation earlier, like light list creation, depth pyramid construction
Cons:
-
Forward transparent donāt support decal
-
Donāt support normal fading (i.e as we donāt have access to normal from Gbuffer or because of forward rendering, we canāt fade badly oriented project based on normal of the receiver)
How does Unreal do it, and why canāt you guys do the same thing? I just want to be able to place bullet holes in a performant way.
Unreal has a very different pipeline, so answering that question will unlikely lead to anything useful I am afraid.
If this is all you want to do, what is stopping you from doing this now? How many bullet holes are you trying to place that you cant do this now? Why not do the 3D decal method, using a GPU instanced shader. Then you could place 1000s of them and have them mostly cost a single draw per shader pass etc
Unity developers have not been forgoing decals up until now, we have gotten around them not being directly supported in the shader for a long time. Also a lot of games do it this way anyway. both methods have pros/cons.
Will this ever come to the core render pipeline or LW SRP?
Why you think itās completely different?
You can check the source code here: https://github.com/Unity-Technologies/ScriptableRenderPipeline - seems quite different to me.
Decals render by ID materials/objects, last created material/object render last:
But, after reloading editor, decals render mess:
Answers about Decals:
Feedback Wanted: Scriptable Render Pipelines page-13#post-3504724
I just unable to make Decal Projector work. Iāve got a simple png texture with transparency, material with HDRP/Decal shader and Blend Factor set to my texture. Floor material with HDRP/Lit shader and āEnable decalsā toggled on.
Material preview in project view is pitch black and Decal Projector do nothing.
May be I need to set some specific texture import settings? I just canāt find any info about new decals
In your screenshot you disabled āalbedo contributionā in the decal material.
This means that the decal will only use the texture alpha to affect metal/smoothness/normal, but you donāt have maps for those.
Enable the setting, and it should work properly :).
I tried it too, all the same
I also tried to project decal on simple plane with DefaultHDMaterial
It may sound dumb, but does it really intersect with the floor?
I double checked it)
Check the HRDP asset. I had to go there and manually enable the decal buffer before I could get it to work.
Thanks! I didnāt notice that toggle in settings)
No problem.
If you ask me, documentation on these previews canāt come fast enough. Itās a real headache to have to crawl the internet, hoping that someone else figured it out for you~