Cycles: Add vector displacement option
ClosedPublic

Authored by Brecht Van Lommel (brecht) on Jan 13 2016, 6:56 PM.

Details

Summary

This patch adds vector displacement to Cycles, which allows to displace meshes
not only along the vertex normal, but also in the tangent plane.

To support that, the displacement socket of the Shader output is now a vector
socket, but still behaves like the old displacement as long as "Vector" is not
selected as the displacement type in the mesh options.

When Vector is selected, the Z component of the displacement output is used
to displace along the normal, the X axis to displace along the UV Map tangent
and the Y axis along the bitangent (perpendicular to normal and tangent).

Note that unlike the regular displacement options, Vector displacement
does not apply the multiplication with 0.1, which makes it easier to use baked
displacement maps.

Diff Detail

Repository
rB Blender
Lukas Stockner (lukasstockner97) retitled this revision from to Cycles: Add vector displacement option.Jan 13 2016, 6:56 PM

heres a test blend with 2 vector displacement models

https://www.dropbox.com/s/aa2qjbzuk7z7v3n/vector_disp_lukas.blend?dl=0 (180mb)

the patch isnt correct yet (well it is but not compatible with mudbox) y and z should be swapped then it works

i love it!

Code seems almost good enough, see inlined comments. However, worrying aspects:

  • Socket type designator in the interface is becoming wrong and useless
  • You are requiring tangents layer now for all shaders which are using displacement, even if there's no vector displacement used. Tangents are not really cheap to compute and increases synchronization time which is something you don't want at all for the viewport render.
  • Displacement type "Both" has meaningless name now.
  • You can not bake vector displacement in Blender to my knowledge, so it's all purely just for some externally baked textures use, which isn't totally great.

As for channels -- i'm not sure there's single convention here, we should just stick to one of them.

intern/cycles/kernel/kernel_bake.h
475 ↗(On Diff #5824)

Just pass type and do actual check in the function. Otherwise all this lists of bool flag arguments are getting annoying to follow.

intern/cycles/kernel/kernel_shader.h
348 ↗(On Diff #5824)

Mustache brackets.

intern/cycles/kernel/osl/osl_services.cpp
718 ↗(On Diff #5824)

Wrong type.

intern/cycles/kernel/osl/osl_services.h
170 ↗(On Diff #5824)

Not sure this is best name for the thing. It suggests that's it's possible to have both bump and vector displacements for example. Think having object:displacement_type is more clear.

intern/cycles/kernel/svm/svm_displace.h
99

Mustache brackets.

intern/cycles/render/mesh_displace.cpp
119 ↗(On Diff #5824)

Same as above.

171 ↗(On Diff #5824)

Better to be explicit here, for the robustness against adding more displacement types in the future.

intern/cycles/render/shader.cpp
218 ↗(On Diff #5824)

This is weak actually. Will require tangents even if they aren't needed due to mesh displacement type.

And usual comment about mustache.

Thanks for the quick review!

  • What do you mean by "Socket type designator in the interface"? The displacement option in the Material Properties panel? Well, true, textures aren't shown there anymore - it might be possible to show both Vector and Scalar options there, but that's probably a bit much for the menu.
  • Replied inline for the tangent comment-
  • True, changing it to "True + Bump" should be more intuitive.
  • Not currently, but at least for Multires sculpting, it shouldn't be too hard to add afaics. Dyntopo is a bit more tricky since you don't necessarily have a basemesh available there.

Regarding channels: Yes, it appears that Mudbox expects Y and Z to be swapped. ZBrush is flexible, so it doesn't matter too much there.

intern/cycles/render/shader.cpp
218 ↗(On Diff #5824)

The problem with all the shader-related options is that the same shader might be used for multiple meshes, but the displacement type is a per-mesh setting. So, two options here:

  • Add tangents here as soon as one of the users has Vector displacement enabled
  • Handle the tangent attribute in the Mesh code - that would waste memory if the user selects Vector displacement, but doesn't actually connect something to the displacement output, but that case can most likely be ignored.

UI wise I wasn't really sure what to do here when I implemented initial displacement support. Currently my thinking is that ideally, displacement would always be a vector socket in the output node, which gets an object space offset vector.

You'd then have a new Displacement node to compute that vector along the normal, which could also have Strength and/or Distance socket like the Bump node, instead of users having to use math nodes. There would then also be a Vector Displacement node, and maybe eventually some node(s) for mixing or layering displacements more easily.

The bump code would need to be modified to work based on offset vectors instead of scalar values along the normals. Which is possible but not a trivial. For backwards compatibility you'd need to automatically insert a Displacement node in existing files.

That's a lot of work of course, and I think implementing it this way could be fine for now, just giving some ideas for where this could go eventually.

As for designator -- sockets in the node editor are color-coded and with this patch the color of socket does not match actual logic of default displacement method. Not sure what would be the solution here, but this is something to be checked on to make more clear feedback (colors in blender are important!)

I don't see difficulty of getting base mesh -- selected to active is how you get "base" and "cage" meshes.

intern/cycles/render/shader.cpp
218 ↗(On Diff #5824)

You can add if(std == ATTR_STD_UV_TANGENT && displacement_method == DISPLACE_VECTOR) {return true}; to ccl::Mesh::need_attribute. This should work i would think.

@Brecht Van Lommel (brecht), yes, was thinking of same things here, but that's more work and this patch could be used as a base for the upcoming changes. Since it's all considered experimental still wouldn't really worry about some upcoming changes in the next releases.

Great work, Cant wait for this one.

What would be really handy is being able to use the Cycles vector node to also save out Vector displace maps from object tapology

Lukas, Any chance you can update this current patch. It's again one of those examples of a feature that really would be helpful but has just sat on here for so long that no chance of working with master anymore. Being able to output vector displace maps would also be handy, as well as vector displace supported within the sculpt tool for texture's. I know you have a crazy amount to do already but vector displace is kinda standard now even in realtime engines and support in cycles would be VERY helpful.

Lukas, Any chance you can update this current patch. It's again one of those examples of a feature that really would be helpful but has just sat on here for so long that no chance of working with master anymore. Being able to output vector displace maps would also be handy, as well as vector displace supported within the sculpt tool for texture's. I know you have a crazy amount to do already but vector displace is kinda standard now even in realtime engines and support in cycles would be VERY helpful.

Any new about this patch ?

Lukas, Any chance you can update this current patch. It's again one of those examples of a feature that really would be helpful but has just sat on here for so long that no chance of working with master anymore. Being able to output vector displace maps would also be handy, as well as vector displace supported within the sculpt tool for texture's. I know you have a crazy amount to do already but vector displace is kinda standard now even in realtime engines and support in cycles would be VERY helpful.

This feature really opens new possibilities and timesaving tricks, hope this will go into master sooner or later

Now that D3015 is in place we can add a builtin vector displacement node.
This adds a start for that, but a complete node should also have:

  • Option to use tangent space, object space, and maybe world space.
  • Option to swizzle XYZ axes to determine which way is up (assumes Y now).
  • Tangents that match other software used to created the displacement maps.

Anyone who's interested, feel free take over this patch or gather example
files so we can figure out what the existing conventions are.

Update to latest master.

Test with the file provided by @Ronny G (nutel) in https://www.youtube.com/watch?v=iNAdi1nzOvE, with a tangent space map:

Scale 0.25Scale 1.0Scale 4.0

This is without adaptive subdivision, since there's cracks, probably due to tangents that need more work.

  • Add tangent/object/world space option to vector displacement.
  • Add object/world space and midlevel options to displacement.

The main remaining issues is getting the right tangent space to be compatible with other software. The results look mostly right, besides some cracks and discontinuities. I'll leave investigating that until after we have smooth UV subdivision in Cycles, since I suspect details in how we handle that are a big part of the mismatch.

This revision was not accepted when it landed; it landed in state Needs Review.Feb 3 2018, 1:03 PM
This revision was automatically updated to reflect the committed changes.