I’m a VFX professional and a very long-time Blender user. I have a generalist 3D skillset but I am specialized as a digital compositor. I love the Cycles engine and have found it to be very capable, you fine folks are getting closer and closer to feature parity with the commercial render engines, slowly but surely.
The fact that progress is being made is fantastic, you folks are great developers. However, I can’t help but feel that it’s taking too long to implement support for Deep Output with absolutely no indication that it’s in the works or being seriously considered.
There are other things like light selects and built-in World, Object, refWorld and refObject position passes(without having to do strange conversions and workarounds to make them sort of work in comp packages) that also need implementing but Deep Output is a big one. OpenEXR supports the reading and writing of Deep data and has reasonably clear documentation.
I’m aware that generating Deep data and being able to write it are two different things of course. Given that almost all the major engines and packages support Deep Output by now, what exactly is it going to take to get it implemented as a utility pass in Cycles? Looking around, some of the previous mentions of feature requests for it go back as far as 12+ months.
I really don’t mean any offence but non-answers and skirting around the subject have been incredibly frustrating. I genuinely enjoy using Blender and Cycles and believe that having Deep Output would take what is a great render engine and get it on the path to become an amazing render engine that studios would have to be crazy not to adopt, promote and contribute towards.
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.
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?
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.
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.
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’.
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.
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
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.
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.
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…
I can see why you would edit that part out, but in doing so you have to change the sentence to something like:
I’ll edit it.