Official Compute Thickness pass Feedbacks / Support

Hi !
In 2023.1, part of the focus on HDRP was the improvement of transparents in general.

Among other tasks, HDRP now provides a fullscreen pass to compute the accumulated thickness for objects on a given **LayerMask**.

HDRP computes optical path and the overlap count (i.e the number of triangles traversed), which can be useful for instance for SubSurface Scattering or Refraction.

The overlap count can be used for flat or non-closed objects like vegetation.

There’s a few limitations when mixing Transparent and Opaque objects but it should work with any type of material.

This post is to centralize feedback and support for this specific features and transparency questions in general.

Documentation is coming but in the meantime, here’s a few tips to use this if someone is interested:

• Compute Thickness needs to be enabled on the Default Frame Settings under Rendering foldout
  
• Compute Thickness needs to be enabled on the current HDRP Asset
  
• One or more layer needs to be checked under the Compute Thickness properties in the HDRP asset
  
• One or more object has to be in the one of those selected layer for the pass to be filled with any meaningful data
  
• Lastly, the result of the thickness pass is accessible via the HD Sample Buffer node in the Shader graph. The node requires the layer index as input

Default Frame Settings



HDRP Asset



Layer index



HD Sample Buffer node



The use cases:

• More accurate Refraction and Absorption without having to author a thickness map.

• SubSurfaceScattering/Translucency with no thickness map needed

• For Vegetation and non closed objects, an overlap count can be used to multiply the thickness of leaves to have a fake accumulation for dense alpha clipped vegetation for exemple.

Varying the thickness of the leaves (see attached gif)

• This can be used as well in more creative ways like sampling the thickness of objects in other layers than the one the object is to create X-Rays effects like.

This will be demonstrated further in an upcoming sample on transparency as well.

Limitations :

• Does not support Tessellation
• Mixing open and closed mesh on the same layer can cause negative values. For better results, use separate layers.
  
• Mixing transparent and opaque objects can creates unexpected results due to when the transparent object are rendered in HDRP

Cheers!

 

It add a simple fullscreen pass to compute the thickness of multiple object at the same time for each given layer. That sample the existing depth buffer to have the thickness interacting with the environement cf. the image of the green glass dragon interacting with the plane.

You have a control on the performance by controlling the resolution of this layer it can be full screen, half resolution or quarter resolution.

 

For the buffer to be filled with the thickness of the object, the object needs to be in a layer and that layer needs to be selected in the HDRP asset list.
Then the only way to sample this buffer is via shader graph by using HDSampleBuffer node.
So, you don't have to use shader graph for object to write their thickness into the buffer, but you have to use shader graph to read that texture and do something with it.

And yes, it's compatible with transparent and opaque objects.

The best way to setup this would be to have a specific layer for object that needs to write their thicknesses and only use that layer for that and nothing else.

 

That would be possible, but that will block us to split object on different layer. For instance we can split transparent and opaque on different thickness layers to avoid interaction issues.
We'll think about it as an improvement to have an index reserved for material-based selection if possible.

 

yes, if each material / objects are into a different layer, each layer will fill a separate buffer and you will be able to get the thickness of each separately

Can't really comment on URP although, AFAIK, nothing's planned. And you are right, when you boil down the algorithm to its simplest component it's basically subtracting backface depth from front face depth (thus why we have issues with open meshes.. etc)

 

would be great if you can talk about your case, IIRC, it's not satured on our side because we thought users might want to know if the value is negative for example, that's an info that will be gone if we saturate it ourselves.

For this one, if you can provide a mesh that's problematic, I'll happily have a look

Thanks for the feedbacks !

 

Basically to have the per pixel depth, Compute Thickness subtract the depth of back faces with depth of front faces. As long as the mesh has even number of those front and back faces for each pixel, it's fine.
When your mesh is "open", you can have an odd number, you can end up with a negative thickness. That can also happen if your normals are not properly facing "outside" your mesh for exemple. See here for more details

You can send me directly the model, and I'll have a look then, don't bother with a report if you're not sure.

 

I just tested this and it seems like it works.
Are you sure you actually selected the proper layer in the debug view as well ?

We could have used rendering layers as well. It's just that RL are limited to 16 and are also used for lights and decals in HDRP and we can be limited very quickly so this is mainly why it has been decided to use GameObject layers for this

 

Don't be, it's actually very valuable and it makes some sense. IIRC, there was another reason why we chose gameobjects layers (why the use of mainly in my answer) but I can't remember why currently, I'll raise this and see if anyone else remembers.

 

Yes, debug view can only see ONE layer.

It's enough in some situations depending on the thickness and scale of your object, usually you probably want to have a way to remap the thickness a little, especially since SSS can be subtle sometimes depending on your parameters and setup. However, some samples are coming (in a few weeks / months) to have a starting point for this feature. I'll update the thread here when it's done

Nope, that's why it's a bit of an "advanced" feature as by default, it's just a new pass in the pipeline but you have to sample it in SG for it to do something. By default, it doesn't do anything and default LIT shader won't sample it. For now it's not planned to have that by default, but it would be possible theoretically.

 

it's not about the difficulty, it's about budget.
We could indeed add more than 16 rendering layers but then it would mean having another GBuffer which is something that has clearly more drawbacks than benefits as a whole.

 

I understand, but sadly we (in SRPs) have very little control about gameobject layers since it's in the engine directly so can't really say if it's possible on our side :|