We’ve been talking with some colleagues and I think we have some missunderstanding regarding this in Blender.
As microdisplacement we understand something that can give you very fine detail without the intervention of the user and acting just in the parts of the mesh where it actually needs detail, and Adaptive Displacement is the same as actual standard displacement but to subdivide the mesh it takes into account the edge length in screen, so it generates more geometry near the camera and less detail far away from the camera.
But are we in a mistake? Are those two displacement in fact just one?
AFAIK, in Blender Cycles “adaptive subdivision”, “microdisplacement”, and “adaptive displacement”, etc. all refer to the same thing, the Cycles experimental “Adaptive” option
which can be set on the Subdivision Surface modifier (only if it’s the last modifier in the stack) which represents the final render-time tessellation of the object taking into account both subdivision and displacement together (this togetherness may be why people use so many different terms for this one feature in Cycles). Perhaps a more formal (and verbose) description would be “screen space adaptive tessellation at render time”.
But also many programs have a modeling or procedural operation “subdivide mesh” or “subdivide polygons” etc. with an option to make the subdivision detail level adaptive based on the topology of the model (curvy vs flat bits etc.) and these are independent of screen-space size. But these are usually static (or at least procedural and upstream from the render) operations. I don’t know of any common standard term for this, other than just something like “subdivide the mesh using the max smoothing angle option” or whatever you like.
Blender’s subdivide operator and modeling commands don’t seem to have (maybe I’m missing it somewhere) the ability to do static surface-adaptive subdivision outside of Cycles. I think OpenSubdiv can now do some of this, so it might be nice to get some more options in the regular subdiv modifier to make it able to be more “adaptive” to the curvature of the geometry (maybe this is just a matter of exposing more of the OSD TopologyRefiner::AdaptiveOptions?)
The second one you described, which is screen space independent, is what I understand as micro displacement, while the screen space dependent one is what I understand as Adaptive Displacement.
The ideal thing would be to have both at render time, so we have detail where needed as microdisplacement and an optimization of this as adaptive displacement.
What I’m not sure it exists at all is the microdisplacement one, but since a lot of people is talking about that, maybe there is a way to enable it that I’m missing.