Cycles Gabor Noise Texture Node
Needs RevisionPublic

Authored by Charlie Jolly (charlie) on Thu, Jun 21, 5:34 PM.

Details

Reviewers
Brecht Van Lommel (brecht)
Group Reviewers
Cycles
Summary

Texture Node for Gabor Noise Method Band-Limited Isotropic only.

This is an implementation of Gabor noise, based on updating the original D287 patch from Jarope and using Musgrave node as reference.

see: https://developer.blender.org/D287

This patch is based on 2.8 branch.

Diff Detail

Repository
rB Blender

Top left corner textures (2x2) are musgrave, voronoi and noise for comparison.

Seems there are a lot of various implementations of Gabor noise.

From previous patch OSL version would need to be implemented. I'd assume this would also need a glsl version too.

For the moment I'll wait for general feedback on whether adding Gabor would be acceptable before working on the todo items.

Some questions from checking the code:

  • Do you think it is important to expose frequency, bandwidth and truncate? If not, you could get rid of GaborParams, just store impulses, lambda and sqrt_lambda_inv in a float3 and hardcode the others.
  • Is there any use case where the user would want to control the seed based on some texture etc.? If not, just making it (and maybe scale) fixed parameters instead of input sockets might be better (see e.g. the sample parameter in the recent AO node commit).
  • What range does the impulse parameter typically have? If it's fairly large, some other poisson sampling method might be a better choice.
  • Does quick_floor really make a noticeable difference?

General:

  • No need to define your own RNG functions, we have a LCG in kernel_random.h
  • OSL would be needed, yes, GLSL would be great as well.
Brecht Van Lommel (brecht) requested changes to this revision.Mon, Jun 25, 8:12 PM

Overall this seems very useful to have.

  • It looks like this is based on the Gabor noise in OSL, if that's the case we need to change the license header in the file?
  • For OSL we may be able to use the builtin Gabor noise and ensure SVM matches it exactly, we do the same for Perlin noise. In that case we have to accept some code duplication for the RNG.
  • Note frequency, bandwidth and truncate are also hardcoded in OSL, so I guess we don't need to expose them.
intern/cycles/kernel/svm/svm_gabortex.h
26

Why is this using noinline?

Just using ccl_device may be ok to leave it up to the compiler, but explicitly telling it no to inline seems bad for performance with small functions like this.

26

quick_floor will conflict with a function using the same name in svm_noise.h (on the GPU only because the CPU uses an SSE version). We should share the code instead.

31

For these has and RNG functions we can use gabor_ prefixes to avoid possible naming conflicts.

This revision now requires changes to proceed.Mon, Jun 25, 8:12 PM

It is similar to the OSL version from what I can tell. The original patch D287 doesn't directly reference OSL but it is similar in places.

OSL for reference: https://github.com/imageworks/OpenShadingLanguage/blob/master/src/liboslnoise/gabornoise.cpp

Exposing other variables provides more artist control which wouldn't be possible if we restrict the texture to the same as the OSL version.

Here are some tests adjusting frequency and rotation.

Impulses seem to be calculated differently compared to the OSL version.

Code wise I've not changed much from the original patch so I can't comment too much on this.

I've spent a little more time on this and I've made a few changes so that it matches the OSL version more accurately.

Below is a comparison of both OSL and the WIP patch and also an example of how exposing frequency would be useful.

I also re-implemented the RNG to closely match the OSL version but this is currently not giving the same patterns for the same seed, I don't know if this is even possible.

Note that the output is in the -1.0 to 1.0 range.

Below is a comparison of both OSL and the WIP patch and also an example of how exposing frequency would be useful.

It seems quite similar to scaling the texture coordinates?

I also re-implemented the RNG to closely match the OSL version but this is currently not giving the same patterns for the same seed, I don't know if this is even possible.

It should be possible, I guess there is some subtle difference in the implementation still.

Note that the output is in the -1.0 to 1.0 range.

This should be changed to 0..1, most Cycles texture nodes follow this convention.