- over 1,000 free tools for The Foundry's Nuke
Voronoi Gradient v2.7
This location is for Registered Users Only.
Perhaps you need to login or register.
11.0, 10.5, 10.0, 9.0, 8.0 or later
Linux, Mac, Windows
28 Oct 2019
2065
Nuke implementation for 2D Gradients. Proof of Concept.
Create an arbitrary number of color-samples in 2D and produce a smooth, natural interpolation over the entire image.
The Gizmo uses Natural Neigbor Interpolation to calculate the pixels inbetween samples, using Blinkscripts.
You can also output the underlying Voronoi Diagram or play with the smoothness value to control the amount of the softening (0 = Voronoi Diagram, 1 = Accurate Natural Neighbor Interpolation).
Another important function is the ability to sample input colors, instead of defining them yourself. Setting the Type to 'Sample' uses all created points to sample the input colors at given positions. Furthermore you can use the 'Fill' Type to interpolate missing information in any image. A premultipied input is required for this.
Changing the Colorspace will change the color falloff. This can be used to achieve the best artistic result. Setting the Colorspace to HSV for example, will interpolate the colors over the spectrum.
There are several tricks and hacks used in this Gizmo to make it work, so please report any bugs you find, I am sure there still are some.
The user knobs and the inside of the gizmo are well documented to help with understanding the concept.
(The algorithm implemented is not the elegant geometric process, but a simple brute-force method, which was easy to implement. This however makes the tool super slow and you might wanna use the speed optimization control to make it a little bit faster at the cost of some quality. That's why I would still consider the whole thing a proof of concept. Although, with my update to v2.7 I'd say we are production ready now :) )
Example 1:
Creating the NNI or respective Voronoi Diagram via feature points
Example 2:
Using the Sample Type to generate a cleanplate
Example 3:
Using the Fill Type to fill in missing information (driven by alpha)
Example 4:
Using the Fill Type to generate a cleanplate
Update to 2.7 (2019-10-28)
- Fully reworked feature point value forwading to BlinkScript. For the 4th time. Animation of Feature Points not buggy anymore. (hopefully)
- Minor update to the UI
Update to 2.6 (2019-10-06)
- Fixed a bug that prevented the smoothness setting to be applied to the Fill mode
- Minor Speed Improvements for the Fill mode
- Works now with aspect ratios other than 1
- Updated the description above with more examples
Update to 2.5 (2019-10-05)
- Added gap filling mode
- Fully reworked feature point value forwading to BlinkScript. No point limit anymore.
- Updated a few knob labels, defaults, etc.
Update to 2.4 (2019-09-07)
- Added Smoothness parameter to the NNI
Update to 2.3 (2019-09-07)
- Fixed a GPU related bug in the SetPoints Blinkscript
Update to 2.1 (2019-09-01)
- Fixed a namespace bug
- Added pointcount to the UI
Update to 2.0 (2019-08-31)
- Reworked the core
- Points can be animated now, but this introduced a limit of 50 points for now (100 points broke the Blinkscript)
- the sample functionality is now handled by a blinkscript and not a TCL expression, which makes it more stable
Update to 1.2
- Fixed another Expression I forgot in 1.1
Update to 1.1
- Fixed the string separator declarations for some Expressions from ',' to ,
Comments
Two things though:
-the "to" points shoe up in the viewer but they don't do anything?!
-it'd be great to implement the "Magic Carpet" functionality of sampling the incoming area under the respective point for the colour rather than having to set it manually.
A plugin version of this would be great to make it a bit faster.
The sample functionality is already implemented, just change the Type parameter to Sample :)
What do you mean with "to" points. I expect the viewer to look like the one in the screenshot above.
A plugin would be faster indeed, but the problem lies within the algorithm. My code is short, clean and slow
There is a way faster method to calculate the pixels, but its implementation is really hard, so instead I used the brute-force approach, that scales quadratically with image size. In order to reduce the processing time to less than 1s I added the optimization parameter. If you crank that up it will be a lot faster.
The whole setup is quite experimental and uses a lot of tricks/hacks in different places, I don't even know how it works on another system.
Indeed, it's all there and the "to" points in the viewer was user error.
Awesome, this will be a great supplement for IBK workflows, thanks!
I hope it will be a simple method to generate cleanplates for keying. Right now I am working on a variation of this tool, to fill in missing information (= black alpha) in an image. This is pretty straightforward , but takes even longer to calculate. As long as I don't come up with speed improvements in the Blinkscript itself.
ERROR: VoronoiGradient 1.Expression_Sa mpleColor.temo_ expr0: Unexpected '' in '[sample [node sample_image] red... and so on, I'll attach link to screenshot. www.kalderafx.com/vfx/nukegizmos/voronoigradient/voronoigradient_error_01.jpg
Also it seems that animated points are not properly evaluated, image is not refreshed even when I force-refresh and clear cache.
working with Nuke 10.5
ERROR: VoronoiGradient 1.Expression_Ge nerateColor.tem p_expr3: Nothing named 'Nothing' in '[value this.parent.col or_[lindex [split [value this.parent.poi nts] ,] [frame]].a]'
Warning: VoronoiGradient 1.SampleBlur: [Blur] Abort/cancel checked with no valid trees. This op most likely needs to have its parent set correctly.
ERROR: VoronoiGradient 1.Expression_Sa mpleColor.temp_ expr0: Nothing named 'Nothing' in '[sample [node sample_image] red [value this.parent.pos _[lindex [split [value this.parent.poi nts] ,] [frame]].x] [value this.parent.pos _[lindex [split [value this.parent.poi nts] ,] [frame]].y]] '
If you have any insight in to this error I'd appreciate the help. I'm also happy to send you files.
thanks!
Apart from that, amazing!!
I'm using to try to create a cleanplate of a light on a stage with varying lighting changes, but need to remove some empty seats. Can't seem to get it working to sample per frame.
ERROR: VoronoiGradient .BlinkScript_Se tPoints.SampleP oints_c_5: Nothing is named "Nothing"
ERROR: VoronoiGradient .BlinkScript_Se tPoints.SampleP oints_p_5: Nothing is named "Nothing"
I tested Nuke 8.0 on Win and Nuke 10.1 on Linux so far.
If there is an error with the SetPoints I might need to build in more failsafe checks I guess...
Cheers...
Tested it on 11.4 Centos 7 just now and it works fine. The knob does not evaluate though l, which is probably causing your error. It seems that some workspace configurations are more sensitive than others.
I replaced the whole part where I feed the sample points into the BlinkScript with a completely different and more elegant method.
If I can, I'll try it on a Nuke 11 build and see what happens
I just did an update with some major improvements and animating the points should not be buggy anyore. Tested on Nuke 8.0 on Win and Nuke 10.1 on Centos7, both locally and on th farm.
Would be great to hear if it works for you! :)
I have so many places to use this.
I'm on non comercial Nuke 11 3.5
Adding extra points, adds them in an extra Tab and make them only visible when that tab selected, rather than all points being seen at same time.
Now, I am very new to Blink scripts, and C++ is a language I have almost no experience with... So some of my confusion may stem from that. I'm trying to use my desire to make changes to this to learn Blink scripts, and whatever of C++ I may need to.
In a previous version, you set up a array of points that appeared in one of the Blink nodes. But in this version, I can't find that Blink script node. The points just seem to appear by magic.
Where are those points set?
Indeed, HOW are those points added? The Add Point button has no script on it to create anything. I get the impression that he Expression nodes are refering to a points array somehow. But where and how does that exist?
In general I think I'm getting the shape that the Expressions for SetPosition and SetColour use the number of points to create a visual index (as it were) of x,y coordinates on the left side, and the RGBA values on the right side. As shown on the PostageStamp_SamplePoints.
I suspect I'm also getting confused by the TCL in the Expressions. I just dont understand what they are referring to with the points. MInd you, TCL has only ever been something I dipped into as needed, and the syntax is very different from other languages I've learned. Parsing the expressions is doing my head in.
I realise you can only comment to a certain level of experience. But if there were any more explanations you could throw in, that would be really helpful.
Thanks
Thanks for your interest!! I will try to clarify as good as I can. You got most of the assumptions right :)
In earlier versions I used different methods for feeding the point data (rgb and position) to the Blinkscript. Each of those methods had flaws and restrictions, so I had to come up with something new. The idea is, to generate a looong expression, that writes these values to a visual array. This would look like this for the red channel:
x==0&&y==0 ? point1.red : [...]
If the pixel coordinate is 0,0 then use the red value of the color knob "point1" in the UI. After the : we continue writing more exceptions, one for each point. For 3 points, it would look like this:
x==0&&y==0 ? point1.red : x==0&&y==1 ? point2.red : x==0&&y==2 ? point3.red : 0
It basically is a command chain of instructions to write all point data to the image. Now this is what the Expression node has to evaluate in the end. But I don't know how many points there will be or if there will be deleted points, so I need to generate this expression chain on the fly. I do this using a multiline TCL script. These are not documented by The Foundry anywhere I guess, but there are plenty of references online that do not need to be in context with Nuke. There is actually a lot more possible with TCL than is documented or written in tutorials.
In the UI of the Tool I have a hidden knob that stores an index list of all points that currently exist/were created by the user. This list is updated via python every time the user adds or deletes a point. (These functions are defined within the onKnobChanged event, not the button itself, since I did not want to the Tool size grow with more points added and each of them containig a whole script to delete this button. So it is generalized in the knobChange event)
In the multiline TCL within the Expression node i take this list and loop through it with a "foreach" command, looking up the corresponding point rgb and position data. Within each foreach loop I add an expression to the command chain mentioned above. So under the hood Nuke FIRST evaluates the TCL that produced the command chain. THEN it evaluates the generated chain/expressio n. This allows us now to have as many points as we want and even have them animated, because the expression is forced to evaluate every frame. I was very lucky that the Expression node allowed all these shenanigans.
For how to approach Blink, I think it needs a lot of trial and error. The documentation is bad and there is almost no way to debug. I learned a lot by looking at other Blinkscripts and nowadays there are better tutorials online.
I am also learning more about callbacks in Nuke. I've dabbled around the edges with Python and TCL so I'm extending myself into areas that seem dark and scary.
What I'm stumbling up against is that I can't see the Python in the call back while in Nuke. I can only see it by copying the group, then pasting into a text editor. And the Python is all on one line, with "\n" for the line breaks.
I attempted a browse through the developer docs and the main Nuke docs, but I couldn't see any way of managing these callbacks, other than using a method to populate the knobChanged callback. And certainly no way of working with the Python already in the callback.
I hope I'm missing something. Otherwise it seems like The Foundry have made these things more difficult than they need to be.
Also very glad to be pointed at good tutorials / docs that give good insight into this.
This is a must have when attempting scripting in Nuke.
I am not quite sure why this is happening between cards, but until I can find the time to update the tool (and also introduce some new features) you can try to go inside the group and find the Blinkscript Node(s) and turn off "Use GPU if available" checkbox under the Kernel Parameters. Also it would help a lot if you find out, which of the 3 Blinkscripts throws the error.
RSS feed for comments to this post