It would be a great feature to have, but at the moment there are quite a few features higher on our priority list. Realistically we can’t give a time estimate for it. It’s really the same as other features, we’d need more time and developers to get it done faster.
5 Likes
Apologies for the delayed response, quick trip to the airport and back.
That’s a bit of a bummer. Not to press the issue too much but do you think it’d take something along the lines of when Epic gave the dev team a grant to improve FBX support? I think that was around the 10,000 Euro mark in 2014.
An unofficial rough estimate would be a great starting point for what it could possibly take to get a feature like that implemented.
Also, I’ve got some programming experience and a solid understanding of OOP under my belt but I’m not super familiar with the Cycles API, any pointers on where to poke around should I be desperate enough to mess about? 
1 Like
This is not completely Cycles-related, but it would be really great if we could use all available Cycles textures in the Displace modifier as well, instead of only rendertime micro-displacement.
Additionally, it would be even more powerful if there’d be UV projection options for the Displace modifier, such as cylindrical, spherical, cube, planar, shrinkwrap, …
— Edit: Someone pointed me to this plan, which will hopefully be realized soon. 
5 Likes
I second this. That would indeed be quite useful.
2 Likes
Cycles micro-displacement has been left hidden in Experimental status for more than 4 years now. It’s about time it becomes a Supported feature.
17 Likes
Continuing the Cycles Displacement discussion, here is some feedback from user Romanji at Blender Artists:
The standard setting for the Displacement node should be set to Displacement, not Bump only which kinda defeats the purpose. There are 3 steps involved in setting up Displacement. 2 are not really intuitive and maybe should be handled better in terms of communicating it to the user.
The displacement node in the shader editor is obvious. The setting of the node in the property editor is totally not obvious.
The fact that you have to subdivide your model and need to use Subdivision modifier is semi obvious (since it is the only way to do that) but it could also be confusing to people.
9 Likes
Agreed that this should be streamlined. I don’t use displacement often but when I do, it takes a good two minutes and three test renders before I finally tick all the boxes.
It’s going to be easier already with subdiv as an object property (as in you won’t have to add a subsurf modifier), and it would be made even easier by changing the default displacement type in material properties to ‘true’ or ‘both’.
2 Likes
I think the default type could stay on “bump” but move the dropdown into the material output node. That way it easy to reach and find.
First I thought that it could be put into the displacement node but since you can have several displacement nodes in one shader graph I am not sure if this might cause problems.
3 Likes
A way to avoid confusion would be: no option, Displacement only makes …Displacement! Let’s do the bump connecting bumps or normal maps into BSDFs Normal sockets
4 Likes
Well you can have several output nodes per material as well, but I don’t think this would be a problem. It’s mostly a design decision, I imagine.
@lsscpp that makes sense as well. After all, bsdfs have a normal input so…
1 Like
Yes, but afaik only a single one can be active while several displacement nodes can be active at the same time.
1 Like
Well, isnt there a difference, though?
If you have several BSDFs but only connect a bump map to a single one you get a different result than connecting a bump map to the material outpout node via displacement node.
Also can you suggest that the standard setting for the Displacement node is set to Displacement, not Bump only which kinda defeats the purpose.
Without the first part of the sentence, it reads as if the current setting is Displacement, and that it should be changed to Bump. 
I can see why you would edit that part out, but in doing so you have to change the sentence to something like:
The standard setting for the Displacement node [should be] set to Displacement, not Bump only which kinda defeats the purpose.
1 Like
You’re right. 
I’ll edit it.
1 Like
The default was displacement for a while, but we got a lot of bug reports because of it. What happens is that users create a material in Eevee or Material shading mode where only bump mapping is supported. Then they switch to Cycles and the scene looks broken because the displacement height was set very high, or there was some shader node setup that doesn’t even produce a valid displacement.
There may be some ways to avoid that, like making the displacement socket only available for Cycles and having a separate bump socket. I’m not sure if that’s something we should do, or wait for Eevee to add displacement support.
9 Likes
Is it ever “correct” to use the displacement socket as a bump map? I thought it was merely a convenience for people too lazy to use the Normal Map node…
1 Like
Yeah, that sounds cool
2 Likes
To get the same result you should connect bump/normalmap to all of the BSDF normal inputs
as @Josephbburg says, displacement used in “bump mode” is a kind of shortcut*
edit: *which I like and use by the way…
This is certainly nice, but I would love it even more if we could create any network of nodes in the shading tab and output it to be accessible by modifiers. I think pablo dobarro wants to do this with scultping brushes.
4 Likes