Cycles Gabor Noise Texture Node
Needs ReviewPublic

Authored by Charlie Jolly (charlie) on Jun 21 2018, 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
Branch
arcpatch-D3495 (branched from blender2.8)
Build Status
Buildable 2191
Build 2191: arc lint + arc unit

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.Jun 25 2018, 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
27

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.

27

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.

32

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

This revision now requires changes to proceed.Jun 25 2018, 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.

@Brecht Van Lommel (brecht) I'm going to try and revisit this. From working on the Voronoi node I think that it would be better to implement this separately to the built in OSL gabor noise. This way it is much easier to keep Cycles, OSL and Eevee in sync. Can I get your view on this?

That seems reasonable, we don't have to use the OSL builtin one.

  • Rewrite patch with Cycles, Eeevee(GLSL) and OSL support
  • Incorporates anisotropic modes from OSL implementation
  • Supports periodic/seamless textures (if scaling is set to whole numbers)
  • Exposes variables to control impulses, bandwidth, frequency, rotation, weight (amplitude), phase and variation (randomness)
  • Seed is exposed for varying small periodic textures
  • Supports additional kernel shapes
  • Removed multiple calls to RNG and uses a single call per sample, in my tests this seemed ok
  • Direction input for Anisotropic mode (possible bug in Eevee as it needs to be connected to work correctly)