Recently, we added support for procedural texturing in the compositor. So you can use texture nodes you all know from shaders and geometry nodes. But now we need to decide what happens to the old Texture node. Our intention is to deprecate it in 4.5 and remove it in 5.0, but before we do that:
This is a setup using the old Texture node to mix in a simple simulated film grain to an animation that changes every frame. I don’t do much animation, but I use this (or similiar) in almost all of them. If there’s a way to achieve the same (or nearly) effect with the new support for procedural texturing in the compositor I haven’t found it. Animating various inputs for the Noise Texture node (Scale 256, but still doesn’t have an exposed Seed to animate) in the compositor in yesterday’s build of 4.5.0alpha has produced some snazzy effects, but not this one.
Edited to add:
That’s the latest tutorial I’ve seen this in.
Keep in mind the old way of moving the noise so much it’s basically a new “frame” is also still possible:
Under “yes I’m a perpetual blender noob, ask me how!” I was using 3D noise, not 4D, so I didn’t try the W input. 
Your first solution did everything I need for this (haven’t tried the other one), that withdraws my not-possible-using-the-new-texture-nodes.
The choice in my opinion depends on which path the texture data block will take in the future, right now, with the new texture nodes it could even be archived the only specific configuration that comes to mind is the possibility of connecting the same texture data block to multiple users which would not be possible with the new system, but the texture data block as it is really inflexible in my opinion so it represents a really marginal configuration. Apart from that, the new workflow is extremely more versatile and powerful as far as I’m concerned.
I tried to recreate the grain node of Nuke/Natron inside blender and the results were really satisfying.
I only have to report two problems that I faced during the creation:
using very low size parameters the frame at a certain point becomes black and I solved it by switching from automatic gpu precision to full.
for the second problem, forgive me if I’m a bit vague but I couldn’t repeat the error, during the creation of the node I noticed that in some moments my configuration remained “blocked” to a previous version, as if it was saved somewhere and despite the changes made to the group this continued to behave with a configuration of the previous nodes. I solved it by saving and reloading the .blend file.
In any case I continue to work on it and if there is a need for the .blend file I can provide it.
In the future will it also be planned for the compositor to add high-level functions with assets of groups of nodes? (A bit like the hair nodes of geondes)
This might be a known limitation of using half precision. I can look into using full precision for computations while storing results in half precision if the performance is good.
Do you notice the compositor executing but still producing the same result or is it not executing at all?
Yes, this is one of main targets of v4.5/v5.0.
compositor loading bar is running every time every change. it is a very generic and intermittent error sometimes it resumes by itself other times i have to save and revert.
I think the problem is due to the math or map range nodes (especially divisions) because by directly inserting very large or very small values ​​into the noise texture I don’t have any black frame but if I insert nodes in the middle to map or normalize the range that the user will use from outside the node to change the noise scale parameter I have the black frame with very small inputs.
In my case, I wanted to have a grain node behavior similar to that of Nuke especially for the size parameter, in Blender the higher it is the denser the noise, the noise of Nuke on the contrary, the smaller the value the denser it is. So remapping the value could be useful to have grain presets from a selection from a drop-down menu just like it happens in Nuke (or natron) and with the same values.
In fact I take this opportunity to give you some advice:
is it better to maintain the behavior that Blender noise has also in other parts or in the case of grain is it ok to remap the input values?
(Natron has the same parameters and makes a different grain, a little more pleasant, but it uses a white noise instead of perlin noise fbm and for the size it makes a blur probably using a dynamic kernel to counterbalance the loss of contrast of the noise, a little more complex and perhaps less performing to do with the blender nodes).
Is there already an idea of ​​which asset nodes to add first?
No concrete plans for that yet, but we will probably cover basic effects first like vignette, and do more sophisticated node groups like tone mapping later
It seems to not be as easy to get the same level of randomness with the new noise texture node, as I could with the old.
I used the old noise texture for dithering, and based on my experiments so far, the new node seems like it might not work as well for that. it seems to have the potential to cause moire patterns.
I have found a setup the appears to work as a replacement, but it requires additional nodes.
Excepting that, I really like the new nodes, and workflow.
This is how you can get an equivalent of texture node noise using procedural nodes.
Other than that there are a few patterns that I know are technically possible using the new procedural nodes but highly impractical.
a) any type of noise that has a “hard” type.
The way it works is that it takes the absolute of signed (non-normalized) noise before “fractalizing” it. Since the user can only work with noise post-fractalization this pattern can only be accurately replicated by manually building out every FBM loop iteration, which is not very practical.
b) Voronoi F2-F1 and Voronoi Crackle. Same as above, their depth parameter cannot be replicated because the F2-F1 math happens before fractalization (and I’m not sure how crackle works under the hood but i suspect it also falls into it).
The repeat zone added in the EEVEE NPR prototype lets you build a fractal noise setup like such, so if adding more parameters to existing nodes is not desired this would be the best solution, and I imagine is a lot more scalable and would let users do a lot more…
This is acceptable as we will soon introduce assets.
This post shall cover a general guide for transitioning from the Texture node to the new procedural texturing nodes.
It is not possible to get a pixel perfect result that matches the old texture, that’s is due to the use of different number generators, seeds, and slight differences in parameterization. But the general look of textures can be captured through the existing texture nodes. Some configurations of the Internal Textures might require larger trees like @etti showed above, but in most cases, reproducing the same look is very easy.
The old Texture node has an Offset and a Scale inputs. The same functionality can be achieved by using a Multiply Add node on the Vector input of the procedural texturing nodes.
The old Internal Texture system had various Color options to post-process the texture, including Color Ramp, Brightness, Contrast, Saturation, … . Those can simply be replaced with nodes like Color Ramp, Brightness and Contrast, HSV, … on the output of the noise.
Will these node setups be made available in the right-click menu, or asset browser or wherever? I know it has been said many times before, so I understand if this is starting to be annoying, but it is also true. Having to set up these nodes, even if there are examples, is inconvenient. And also, I don’t know which values I should or should not change to maintain the same kind of effect or texture, while trying to get different variations of, say, the cloud texture.
No, not officially anyways. Users are welcome to share node groups/assets that do that if they want though of course.
To understand your concerns better, why are you trying to do that?
No.
I do not think legacy textures are better. However, They were easier to use, because it was just one click to get a certain texture. I think for many Blender users, the thought process is that, for example, if I want to make a heat distortion, and if there is a node that is called Heat Distortion Texture, I’d use it directly, like the Glass Shader when I want to make glass. I understand it is impossible for Blender to provide every possible material or texture. But if you can provide certain textures with a node group, why not? You have already made these node groups.
I don’t have such files. I have tried to make some procedural textures before, but I didn’t succeed. Now I mostly use noise texture to get some random effects. It isn’t that it is impossible to get satisfactory results using texture nodes. It is that I don’t know how, not easily anyway.
