POM material

[RyanB]

@bogieman987;315930

Thanks , I had a hunch that it might have had something to do with that part, but overall, I still had no idea.
I’m plugging in the color from else where, so would it be as simple as adding a new input, say Color (couldn’t think of a more appropriate name) and then in the code, just have it like so

texatray = Color+offset;

Also, so you don’t have a floating character, would you have to move the plane up a touch and use the Pixel Depth Offset connection?

That value is purely for the height of the surface where the ray is being sampled.

The function returns the necessary coordinate offsets as the “Parallax UVs” or “offset only” value. So you just need to use those offsets to look up your color function. You can easily replace the concept of “uvs” with world position if it makes it easier to understand. Basically that can exist external of the function.

Here is an example where I used the “material complexity” gradient and sampled it by the other cone gradient. You can use any kind of coordinate defined color map way.

Here it is hooked up to the simple non-parallax material where I first create the height gradient using spheremask, and then use the resulting ‘1d coordinates’ as a lookup for a ‘material complexity’ type color blending function. But could be anything I just used the cone since it would make a nice height-layered effect on the final cone way.

To use it with parallax simply requires using “Parallax UVs” on the function using the same height gradient:

Notice that we use the same original math to create the cone gradient, sampled using the Parallax UVs. Then we can sample the gradient with that updated gradient and it looks like :

The parallax function actually does output the final height of the ray intersection, but currently the material function converts that Z value into world space for pixel depth offset which is why in the above image I had to re-sample the height gradient using the final parallax UVs. Probably not a big deal.

Regarding PixelDepthOffset and floating characters, you will always have some error. how you handle it depends on the type of texture. I think the most common usage case would be stone floors and brick walls. If the gaps between the stones are small enough that you wouldn’t question walking on them in real life without discomfort, there should be no problem. If you are talking about pixel depth offset for some huge gnalrly terrain effect then yes maybe you can offset the plane but then you may have the opposite problem where the character gets clipped by parts of it. If your heightmap has lots of low frequency negative space it may be better to model out the low frequencies using very low resolution geometry then use POM to get finer details to pop.