Unity Terrain SampleHeight different results when used in Shader ??

Unity Engine
, ,
1

UPDATE: Fixed :smile:

Hello

To summarise the issue I’ve found a thread detailing how the SampleHeight method works in the backend:

The code works within a burst job I’ve implemented. I had the idea of packing this into a custom ShaderGraph node (HLSL file). To translate this code over to HLSL I did the following:

So this produces the following result:

1083×623 311 KB

The fully white planes are the ones in a burstable Job (same as Unity’s Terrain System) and the coloured ones are the GPU Shader versions done with sampling the heightmap.

To my knowledge tex2D already does Bilinear interpolation of the tex-coordinate to the nearest pixel in the backend, and I double checked this with OpenAI ChatGPT. The actual geometry of the terrain does indeed also look interpolated.

I can’t for the love of god figure out why they don’t match if both are sampled via Bi-Linear Interpolation?

2

I suspect it’s because I was placing objects, but am not 100% sure, so worth a mention just in case: I have a vague memory of having to take the Terrain GameObject’s world Y position into account when working with Terrain height samples.

The docs say that the result is relative to the Terrain space, not that they are in the Terrain’s local space.

3

Hey thanks, this makes sense but everything is positioned at y value 0

1 Like
4

The strangest thing is the two do meet near the top at points so it’s not related to a y-position or height value problem. Their interpolation just appears to be different somehow

And here is a comparison with Unity’s default Terrain. The Burst-Job C# script appears to match Unity’s where as the Shader version is quite a bit off:

1280×495 841 KB