These new options look great. I for one love using procedural textures in my materials and any expansion of the current set is most appreciated.
Iâd love to see some additional regular tiling options added to the mix as well (e.g. triangles, quadrangles, pentagons, hexagons, polka dots etc) as well as some additional brick tiling (herringbone, basketweave etc).
Initial Particle Nodes task. Basically, what all needs done to make it in the 2.82 release:
My wish is that they donât go ahead with the compromises because users are impatient. It would be better to get this in for 2.82 as scheduled so it is done the right way.
It looks like a lot of particle node talk here, so Iâm not sure if Iâm in the right place. Sorry if this has been covered already:
Anyone know of any update on modifier nodes? Thanks!
i actually was wondering why they rushed particles nodes, why didnt they begin with normal scene graph representation and modifiers
I donât think itâs going to be like this. The scene representation is going to stay as a list, in the outliner (as far as I know!), and different objects and uses are going to be split up. I think (but donât take my word for it, ping @Jacques_Lucke instead) that particles are more of a priority because the current system is practically unusable and particle nodes might be simpler to design than mesh generation.
Agreed, Particles were in the most dire need of upgrading and the modifier system, despite the stack-based limitation, still works pretty well for a lot of things.
Honestly, the particle system as of now is limited to where it does not take much of a node-based system to make them do a lot of things we canât now, especially if it changes emission to a continual emission rate design. The bar to create a genuinely better system is low, and we are seeing a lot more user visible stuff now in the commits.
Can we have a cavity node please.
I wonder if this means particle nodes are getting close to being ready.
https://twitter.com/tonroosendaal/status/1174323448589508608
Jacques has said that a first implementation for particle nodes might be ready for 2.82 but that it wouldn´t have all the planned functionality. Figure window for new functionality for 2.82 will be mid to late decemberâŚ
I hope EN comes a bit more organized than those cables⌠oof 
Isnât it reasonable when the topic is âEverything Nodesâ? 
Haha, I was thinking the same thing when I saw that picture.
Considering they have those NUC cpus attached to the back of the monitors, youâd think thereâd be a bit less spaghetti.
The guidance that Iâd give these teams is simply this: âmake âeverything nodes,â but please donât make 'everything(!) nodes.ââ
Right now, the user interface does not force you to dive into nodes-land, which is quite convenient, but when you click on the Use Nodes button, âthere are the nodes.â And, when you make certain changes to those nodes, you see that the non-node UI reflects those changes. âPerfect!â The actions that we expressed in ânon-node termsâ were implemented behind the scenes by nodes, but we werenât necessarily obliged to push that magic button.
This makes âeasy things easy to do,â while making the power of nodes readily available for everything else. There are certain things that we do so often that we really do just want them to be âeasy.â Because, â95% of the time weâre really doing very routine things,â and we want to be able to accomplish those things quickly and accurately â without, as it were, âwriting a [visual] computer programâ to accomplish them.
Iâd also like the teams to consider the idea of "stock node-groups." Build commonly-used groups for common situations so we can use them like macros. Make it easy for other node groups to be contributed by others. Give us the benefit of experts who designed these node-groups for us, so we donât have to be such experts too. Push-up the level of the things that are available to us while you push-down the obstacles to getting there as seen by ordinary mortals with a tight deadline. 
Yes, nodes give us all the expressiveness we could possibly need â and sometimes we do need it all â but itâs a question of deployment. âHowâ to make that feature available in the most-beneficial way.
Agreed, node systems are powerful but time consuming and needlessly(?) convoluted to do simple tasks. Itâs so easy (especially for artists like me) to get lost in the node network being created.
For instance, I created an intro animation for my work using Animation Nodes, and while I loved the control I got to procedurally manipulate individual letters, it was a hassle to setup. Figuring out how to offset the animation per letter took a long time, and creating the network to make it work took a lot more manual work than I would have liked. And experimenting with what I thought would be simple changes were time consuming.
My hope is that theyâll make Everything Nodes very visual, intuitive, and efficient for the artist. A non-node UI as a surface level control for common setups/structures would be cool. Also, it should be smart, contextually figuring out what the user needs to make certain node combinations work (which AN starts to do, which I appreciated).
And I hope it goes beyond mere âjustâ nodes. Maybe it can utilize something like visual programming blocks as well, and other visual cues/tools to facilitate faster, intuitive building/manipulation of nodes.
Just a bunch of blocks and lines interconnecting each other can get convoluted and overwhelming fast.
I think houdiniâs VEX is the best reference. VEX is a simple C-like language. Cool thing that it has both node interface (it generates VEX code under the hood), and just code input. You can use nodes, or code or mix them anytime anywhere.
So I think some simple expression language that will do the same as nodes do will be the best alternative interface (in fact I hludini I almos always use code when using VEX - it is faster and more readable).
But not this âmodkitâ example, please. It is a horror.
Software in other fields does this as well. For example, Inspire Designer by Quadient, (think InDesign on steroids), also uses a combination of nodes and a C-like language.
Code nodes (with custom inputs and outputs) and the ability to add more inputs to simple math nodes like +, -, * and / really help reduce the complexity of node networks. In Blender you need multiple add nodes to add more than two values, which wastes space, and nodes are just really bad for expressing math anyway, as it gets hard to read even quite simple things like x * x * (3x - 2) (smoothstep blending formula) in nodes.
Changing the way minimised nodes are displayed would also help reduce clutter I think.
Particle Node examples from the Blender Developers channel: