4D Noise v1.2
This location is for Registered Users Only.
Perhaps you need to login or register.
13.1, 12.2, 12.1, 12.0, 11.3, 11.2, 11.1, 11.0, 10 or later
Linux, Mac, Windows
This is a port of the 4D simplex noise found at https://github.com/Draradech/csworldgen/blob/master/simplexnoise.cpp
It uses the image values of the input image to generate the noise. It is not fast, but it does the job quite well.
[Version 1.1] - Fixed a compile error on Linux and Mac
[Version 1.2] - Optimized for certain Nvidia GPU's (Thanks to Nikos Koutsikos, Lead Software Engineer at Foundry)
Nikos Koutsikos made some significant improvements to this noise node that on some gpus will make it an order of magnitude faster than the 1.1 version. To sumurize the improvements, i'll let him explain it:
This kernel has regressed significantly on performance on NVIDIA GPUs since Nuke 12.1. I have investigated this and it turns out to be that our switch of BlinkScript from OpenCL to CUDA has actually triggered much worse performance on this particular kernel.
After looking into the problem, I managed to narrow it down to the 3 arrays that are defined in the raw_noise_4d() function, simplex, perm and grad4. Since they are defined and initialised within the function, this will cause the generated code to actually initialise those arrays for every pixel. And while most compilers would be able to optimise that, the CUDA compiler cannot, making it much slower than it can be (and actually slower than the CPU).
I have written an optimised version of this kernel, which stores these arrays in locals and initialises them in init(), which makes the kernel much faster on NVIDIA cards. For example on my Ampere card the original kernel on 4K was running at 2 FPS, and the optimised version runs at 15.5 FPS. Profiling the kernel shows a massive difference, initially the kernel execution was taking 580ms and the optimised version takes only 4ms!
"Error compiling kernel: Error at line:72 use of undeclared identifier 'sqrtf'; did you mean 'sqrt'?"
Also, if you save this as a proper gizmo rather than an example nuke script, the upcoming nuBridge will be able to auto-install it :)
What system are you on, just tested on 8,9 and 10 beta without getting any compile errors. sqrt could work but sqrtf should work just fine as well.
And regarding the gizmo thing..
I am personally against gizmo gizmo's. (a gizmo inside a .gizmo), not being portable, modifiable, and version depended and all that
I could do a group inside a .gizmo file if that counts?
Well that sounds like we have found a bug in the blinkscript node.
Ill check it on mac at work tommorow, and if i can reproduce it ill report it.
(does it work if you change all the sqrtf with sqrt ?)
Error compiling kernel: Error compiling kernel
Ok, i found that this is a bug on the OSX and Linux versions of Nuke. But i have fixed it (atleast on the linux version)
Can you try out this new version?
I tested it on OSX and Nuke 9.0v8
I try to avoid nested gizmos as well but there are none in this tool, it's just four compiled nodes saved as nk.
Technically there is no trouble with this. I'm just saying that the nuBridge's auto installer currently will not be able to automatically install this. Having said that, I will look into updating it so it can deal with nk files as well, since it's obvious it should import/open the file rather than try to call it as a gizmo if it has a nk extension.
P.S.: There are no nextes gizmos in this example as far as I can see?
Allright, i might need to go back to all my other tools and do it for them aswell. But somehow i just personally like if a gizmo/toolset contains a little "tutorial"/example.
Especially with something like this where you might not get how to set it up right away.
Btw. Frank, while you are here.
We might need some more sub sections in the Hiero section.
I have a few softeffects in the python section and i can see that the Nuke 10 softeffects are slowly rolling in. Would love to keep the python and softeffects seperated.
Keeping Nukepedia consistent without imposing strict auditing on upload is a bit like hearding a pack of kittens :-D.
If you'd want to be super tidy you could upload a gizmo for your blink script node (with a user friendly interface that hides away the Blink node's geeky stuff), and then upload a toolset to the toolsets section, then cross link them in the respective discriptions.
People will then konw what they get and can download your toolset if they would like an example.
Just a thought.
As for the SoftEffects sub category in the Hiero section, I have just added one. If you could upload an example to test if the new sectio nworks as expected, that would be helpful.
Thanks for all the sharing!!
Im on easter vacation right now but ill provide a example when i get home.
One other thing...
If you (without being logged in) try to view the blink script section, you are required to login, unlike all other sections where you only need to login if you want to download.