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.
