Force displacement self-shadow error

[sboerner]

I've been testing "Force displacement" to see if it might be used displace bark on trees. But areas with negative displacements render black.

So I set up a test scene (attached) with an imported 1-meter plane and a 1-meter Terragen cube object for comparison. A 16-bit texture map divided into 11 strips with values from zero to 1.0 is used for the displacement. With a displacement multiplier set to 1, the 1.0 strip (pure white) displaces to 1 meter. It really works great.

But when the displacement offset is set to -0.5, the resulting render includes a random black section over part of the negative displacement.

Disabling "Cast shadows" for the plane object fixes the problem, so maybe it's a self-shadowing error?

[sboerner]

Quick update: Turns out that's exactly what it is. Here is a rendering of the first (displaced) plane with shadows disabled, and a second (undisplaced) plane with shadows enabled.

It seems that in the original scene, the shadow is cast by the original plane onto its displaced, rendered self.

I remember other threads here that give examples of mismatches between displaced objects and their shadows. But I don't remember seeing a self-shadowing example.

Probably unavoidable. Too bad -- it really limits what you can do with this.

[sboerner]

Replying to Dune's comments in another thread . . .

Regarding your other post, I don't really know how to solve that other than maybe distributing the displacement equally between positive and negative. So using a negative offset half the displacement. There have been issues before, but that has been (partially) solved. And the tree really needs a lot of vertices.

The 16-bit height maps that I export from Substance Painter use 0.5 as the midpoint, so anything less than should give you a negative displacement. That's why I've been using negative 0.5 as the displacement offset. I've tested this with 32-bit maps, too, which use zero as the midpoint, with similar results. You can minimize the problem by tweaking the offset value, but values over negative 0.5 can make the object look inflated and puffy. Like I said, it's too bad. This would be an amazing feature except for this.

All I'm trying to do is break up the silhouette of the branches, since the object will be in the foreground. Right now it seems the best option might be to import it into ZBrush, subdivide it into a couple million polys, and apply the height map as true geometry. Not sure my scene can take an object that large, though . . . it's already pretty heavy.

[Dune]

Strange that they use +0.5 as midpoint. 16-bit (or 8-bit) should only displace upward, so a negative starting point would have been a better idea. But there must be an underlying reason I'm not aware of.
In ZBrush you can subdivide unmasked parts, so you needn't subdivide the whole thing, just the obvious areas. That should keep it reasonably small. And there's a software called Balancer, which reduces vertices in a smart way, keeping UV's. https://www.atangeo.com/products

[sboerner]

It makes sense if you think about it. You need to be able to define negative displacements, such as skin pores. Or both negative and positive -- skin pores and warts -- without moving the overall surface. In the case of tree bark, there are depressions and ridges.

Thank you for the link. Blender has a decimation modifier with three or four different methods for reducing polycounts. Works pretty well, but I wonder if Balancer might work better? May have to test it.

I've run into other complications while trying to bake the displacement in ZBrush. Mainly you need a large displacement for the trunk but a much finer one (or none at all) for the smaller branches. Painting a mask doesn't seem to affect the displacement (which is strange), but there must be a way to do it.

[Dune]

Regarding ZBrush I meant that if you mask certain areas and subdivide, only unmasked areas will do so. Then you can add (extra) displacement in those areas and save (without any remeshing of course). Balancer will reduce polys especially in flattish areas, and keep more at edges, so for me it works very good. And easy and fast!

Good luck.

[sboerner]

Thanks, Ulco. Yeah, I understood what you were saying. But what I was running into is the need to taper off the displacement as it goes from the main trunk to the tips of the branches. If you don't do that, the smaller branches get blown up way out of proportion. I had hoped that this might be possible in ZBrush by gradually masking the displacement, but that doesn't seem to be possible. For the time being I'm going to concede defeat and move on. A regular bump map in Terragen will have to suffice.