How this is relevant to what I’m proposing? Could you show example how to utilize it in procedural content creation?
I was just scrolling down through the posts here to recommend that you be used as a resource. It would be great if your scattr node tree and some of your other procedurals could be ported to C to speed them up.
https://twitter.com/simonthommes
@OmarEmaraDev Also, CPetry has done some open source procedural texture generation stuff that you could look at.
http://cpetry.github.io/TextureGenerator-Online/
The fractal noise generator is similar to the 3dsMax Turbulence texture which I always found useful.
Also, Emiliano Colantoni does a lot of cool stuff with procedural textures used as displacement maps
https://twitter.com/IMilk_ManI
I also want to put in my personal request which is procedural text (as in letters and numbers) directly in the shader editor without using workarounds.
5 Likes
The texture node system seems sort of forgotten in all the blender development but, I also think this would be the ideal place to focus efforts to improve procedural/generative workflows.
If we were able to use texture nodes to work up novel patterns with variable channel counts and then feed these into the texture inputs in various parts of blender, it would allow for a lot of amazing possibilities.
Also, a purely texture oriented node environment would be a saner home for various generator types like noise and fbm. Ideally we wouldn’t have these in the shader editor directly but, rather reference texture node chains inside the shader node graph.
4 Likes
Like in old texture system. One could add a Texture nodetree into shaders and reference a texture done in that editor, maybe having also the ability to expose some parameters for variations.
Ok, awesome… but it sounds very similar to “nodegroup”
The only real plus would be to have easy previews of what is going on with the texture
I was thinking about the exposed parameter idea and how it wind up being similar to node groups after I posted this.
It is similar, however, I think that another advantage, besides previews, is having a more organized node list.
Instead of having texture friendly nodes like generators and potentially filters (like blur, edge detect, etc.) buried in a subcategory next to shader and light path nodes, it would be a lot simpler to have a dedicated graph where you don’t have a cluttered list of non-tex-relevant node categories to paw through in search of what you need.
Then there is the additional fact that the data is useful in places besides shaders. So I would disagree that the only benefit is just previews.
right, modifiers comes immediately in mind
Aww 
This is what I came here to suggest. Blur is the node I’ve wanted forever.
5 Likes
Hi Omar,
Thank you for deciding to work on this project during GSoC. My suggestion is the following.
Is it possible to create some kind of bridge between the Compositor and the Shader editor? This would work in the following way:
-You import or create an image from scratch in the compositor using all the tools at your disposal there.
-Link the output of that node setup to a new “output image” node. (basically a cache to transfer data between compositor and sahder editor)
-Go to the shader editor and add an image node.
-Select the output of your compositor “output image” node as the image to be used.
This would allow for very powerful procedural workflows, hopefully circumventing the limitations of the cycles/eevee nodes in manipulating images.
This workflow is almost possible already, as long as you save the compositor output to an actual image file. But if you could make it seamless inside of blender it would be much better.
As an extra note: The compositor would probably then have to be renamed to something like “image editor” or simply “node editor”
Thanks again for dedicating some of your time to this.
2 Likes
I use this for bluring:
6 Likes
Would be cool if we can even implement this trick/hack as a defult included group node? would be really nice to include some of tricks to blender cycles. until. proper node is not developed.
a consideration for ui/ux of this:
- I would keep the mapping node as it is, also for compatibility as some may have previously used drivers on it as is
- I would make extra 3 simple mov, rot , sca nodes,
these simple nodes would have vector i/o and the xyz visual also for inpu in case one may just fiddle with one param ( may also add tile or even “pixelate” (posterize really) as in using mul + modulo for repeating uv/ floor or round for pixelating uv, mostly for npr use i guess)
it is a very necessary approach to rotation especially, as math group approaches seams slower to me. these all are very useful in advanced mapping / npr especially
may consider this a simple backup plan, to keep it simple 
othewise, ui wise for the math/vector nodes that don’t use some sockets sometimes,
i would just grey them out, instead of removing them
it is more useful in case one has already a connection to that socket, so it does not remove it
again, may just be a simpe way, to fall back to, in case it proves tedious
2 Likes
Apologies, it seems like I spoke too fast : I was pretty much certain there was a mask node in Cycles, but it’s only available in compositor. Now, that would be a nice thing to have. The entire curve editing interface you proposed exists already within the mask editor, hence my reply (it’s just not connected to Cycles currently).
In response to:
“A potential fix for that is to implement multiple versions of the textures for 2D, 3D, and 4D dimensions, either as separate implementations or as a generic algorithm if possible. Giving the user the ability to choose the target dimension as an option.”
I think that adding separate nodes is a decent way to handle this, but I do think it adds a bit off extra work to add them on the fly. I think adding a dropdown menu on the noise nodes to choose the state would serve us better. Here is Houdini with the described behavior 
1 Like
Yes, having a drop-down menu for dimensions was initially my plan.
1 Like
I believe was can keep the backward compatibility when doing such changes, so don’t worry too much about it.
Brecht said that he would prefer a more dynamic mapping node instead. It is not going to change much, the main change is that properties will be sockets which will only give more flexibility and not take it away.
1 Like
Sometimes I want to use normal maps with vectors other than uv, like with triplanar box. I’d like for an option in the Normal map node to use a custom tangent vector as input instead of just choosing between the UVs from the dropdown. Also, I’d like for box, cilinder and tube to not be just options for the image textures, but vectors of their own.
2 Likes
In relation to the UI side of things, would it be in scope to explore adding a thumbnail preview to the top of image-related nodes? As compared to, say, Substance Designer, I have found it rather difficult to work in Blender without being able to easily preview what textures and downstream nodes look like. I feel like that’s one of the biggest flaws that makes Blender not even compare to Substance Designer, but adding it would be a big step to putting it on the right track.
One way is to use Node Wrangler add-on and Ctrl + Shift + Click on node you want to preview. Not perfect but it’s something. In SD I tend to always preview texture in 2D view rather then looking on thumbnail. Nevertheless this could be really helpful to have.
On the topic of the 2D texture view in Substance Designer, that would also be super helpful to have. Sort of like how the compositor lets you see the final result, perhaps even in the background, you could mark a node. Unfortunately the node wrangler isn’t the greatest to use for this, since you can’t just passively view the preview while also seeing you actual final result on the model you are working with. It’s even more of a challenge to use when you’re trying to preview displacement textures.
4 Likes