2
$\begingroup$

Alright, so I've used Photoshop to create a displacement map for some tire tracks going off trail (A crashed truck)

enter image description here

Blender registers this fine using this node setup: enter image description here

I also have Displacement set to "True" in the material settings (So it actually displaces the geometry of the mesh, not just a bump map).

Now I am trying to figure out how I should SubSurf it. I've watched BlenderGuru's video on using Adaptive SubSurf modifiers, which seems like a really convenient way of achieving what I'm going for. Using the following settings produces the following results: enter image description here enter image description here

From what I know, having the dicing scale set to 1px should subdivide the mesh again every pixel, correct? That should mean a perfect output, right? So why does the one simply using a SubSurf of 5 look better?

Right now it almost looks like something out of the Lego Movie. I guess it could be the displacement map, but I don't think that's the case because the displacement map is 4096x4096, and I blurred the displacement map to avoid jagged edges this seems to produce.

I've hit a wall. I have 6GB of VRAM (GTX 1060) and 8GB of RAM, so I need to be conservative with my geometry. If anyone want's to look around and see if they can find a solution, I've included the .BLEND:

Improve this question
$\endgroup$

1 Answer 1

Reset to default
3
$\begingroup$

The 1px adaptive displacement is the more accurate one. The reason you see it as worse is because it exposes your displacement map for what it is: an 8bit file (and one with an odd value range at that).

Your standard 8bit integer images store values as integers (whole numbers) from 0-255. That means an 8bit integer displacement map has only 256 possible height levels. Worse, your map is very low contrast. The 'blank' value is 128 (I think you might have another misconception here, see below). The lowest value I could find in a quick check is 108, meaning your entire tire track has only 20 different heights in it. Obviously, you're not going to get smooth gradients over only 20 possible heights!

Unfortunately, painting in Photoshop is rasterized immediately, so you'll have to repaint in a 16 or 32bit file to fix this. Even just using 16bit gives you 2^8 more height possibilities than 8bit. And remember, you were only using about 1/10th of the 8bit range. So make a solid white 16bit file, and paint some tire tracks with a heavy hand, the deepest point in the track should be close to black.

Above I commented on your use of 128 as a "blank' value and recommended using full white on the repaint. The reason for this is how Cycles interprets the displacement height. Cycles' displacement system is designed around floating point inputs, and simply takes the value given as literal distance. Meaning the "blank" value is black, and negative numbers need to be used to displace downwards. Simply Photoshop isn't really conducive to painting negative values, it's easiest to paint in a 0-1 range then just subtract 1: using math nodes to change the "blank" (scalar zero point) value by subtracting 1

As far as memory savings go, this answer of mine might be useful as well: Render fails at tesselation with out of memory error

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ I'll give this a go and see how it works out. However, the reason I used perfect gray as the mid-range is because the map doesn't just extrude downwards, but also upwards. (The kicked-up snow around the tracks) If I used perfect white as the base-line, I wouldn't be able to do that. $\endgroup$
    – Josh Silveous
    Commented Feb 14, 2017 at 11:46
  • $\begingroup$ Ah, ok. Gotcha. $\endgroup$
    – JtheNinja
    Commented Feb 14, 2017 at 17:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .