I have been playing with displacement mapping in some tests and a couple personal projects going back to like R78 or something. And I have had no problems with them per se, in MeshStandardMaterial, and I really have accomplished some really nice displacements (with my buddies LightWave/Octane, ZBrush, Substance Painter) these handful of times I have used it… But I actually have some questions that I have not been able to find answers to… and I have two gigs about to begin that I would really like to use displacements on…
 Are Displacement Maps supported in all browsers and all devices that support WebGL in general?
 When Displacements are supported, are they particularly taxing on the system resources of device viewing them? Anyone have any useful info?.. Test results on various devices likes older iPads/Androids and whatnot?.. It’s kind of hard to tell on my GPU workstation and wifey’s new-ish iPad…
 displacementBias is still somewhat mysterious to me… It often seems like it wants to be somewhere close to minus what the displacementScale is (displacementScale = 0.05; displacementBias = -0.025;)… Is displacementBias suppose to represent mid gray of displacement map?.. Someone please explain this to me. Leave nothing out.
 I have not tested much on highly decimated/optimized/retopo’d low-poly meshes, but a couple tests on really low-poly yielded some pretty dodgy results with tearing all over etc. Does anyone have any kind of guidance as to the minimum vertices required to be able to properly displace geo before it has problems? Things that are roundish in nature have far fewer problems than boxy types of meshes… And I really need to get a better handle on this asap.
Thanks in advance guys. Please help.
And anyone who has not played with displacement mapping is doing themselves a disservice by not doing so. It is the shizz.
: Displacement maps simply take a texture, and read its .r (red) value to move a vertex in/out along its normal. It’s not very resource intensive, since texture lookups are super cheap, and calculating things once per vertex is much less taxing than calculating once per fragment.
: That’s to be expected. The displacement gets applied to the vertices, so if you have low-poly geometry, the resolution in which to show your displacement will be low. Depending on what your geometry is, maybe you could subdivide it before adding the displacement map for a smoother result.
Also, if you want low-poly geometry show lots of height detail, maybe you’ll want to look at this bump-map example. I think it does a great job at showing lots of detail on an otherwise smooth surface.
Simplified version of how it works
And what it is under the hood of Three.js:
You know, this got me thinkin’ (usually a dangerous proposition)… If we are using ORM textures for Occlusion, Roughness, and Metalness, and Displacment is using RED channel, and Alpha uses GREEN channel, could we not possibly make a DAB texture that would be Displacement, Alpha, and Bump, by sticking Bump (and forego using normal map, if one’s application would allow for it) into BLUE channel and somehow telling three to grab Bump map in the blue channel of DAB texture?..
The idea of having ALL PBR maps inside two images is very attractive indeed. Is there any way to overcome where three grabs channels for given maps?
And someone please answer  if possible…
The idea to have several maps in one image is… interesting.
One disadvantage I can imagine is inflexibility of such method. For example you want to change displacement component (for a certain reason). What to do in this case?
When all maps are separated images, there’s no problem with dynamic changing.
Yes, it is a little bit of a disadvantage, but I have made quick edits to particular channels in PS, of my occlusionRoughnessMetallic textures that Painter spits out with glTF 2.0 exports. And you can always override a given map by loading a grayscale version of it and assigning that to your map.
Have you used occlusionRoughnessMetallic textures yet?
I haven’t tried having displacement with just bump rather than normal map… I will need to do that. Maybe displacement really needs normals to look/work good… But hey, maybe instead of Bump, one could do Emissive , and it would be a displacementAlphaEmissive (DAE) texture…
Edit: In regards to  and , I guess I was thinking that maybe new geometry was happening on the GPU in WebGL too, like we see in production renderers like Octane et al (you can displace The Alps on a single-poly plane in Octane)… Further testing proved this to not be the case in WebGL/three… Okay, so now I know I need to have more geo than I was hoping for to accomplish the look I need. In a perfect world, WebGL would be able to displace like the Big Boys…
Someone please answer  and let me know if displacement is supported across the board anywhere that WebGL is able to be viewed.
And  (displacementBias) is just as mysterious to me today as it was yesterday…
With regards to : I think it’s safe to assume that displacementMaps are supported across any devices that support WebGL, since it doesn’t require any crazy WebGL extensions. But I think it’s up to you to do your due-diligence and run some tests to make sure, so if you’re ready to launch and it doesn’t work everywhere, your excuse won’t be “Some guy on the forum said it would work!”
Just run this example on the devices your project is supporting, if they work, then you’re good to go!