Geometry Node: Array
A more or less straight conversion of the Array modifier into a node, with the added benefit of being able to specify either geometry, object or an entire collection (either whole or as random individual objects) as an input.
Why
The array modifier has shown it's usefulness over the years enough to justify it.
Why not just recreate the functionality with point instance, lines and other stuff?
(Which seems to be the suggestion from Hans Goudey on developer.blender.org , the current patch to add the Array modifier has been 'abandoned' and closed by Hans Goudey. Source: developer.blender.org/D9743 )
A) For convenience. it would be nice to have a single node that could be added to achieve a result that might require otherwise a dozen or more nodes to achieve the same result.
In short, yes we could recreate all the functionality of the Array modifier in it's current form by engineering a couple dozen nodes together to recreate the same operation.. but why should we have to? Clearly the Array modifier is a commonly used modifier, surely it's used commonly enough to justify simply having it available as a built in node to save time.
B) For extra functionality. As it currently stands, my proposed node can achieve things which are not currently possible with the existing node system and are unlikely to be possible any time soon.
For example, my proposed array node could take a collection as an input and array it, stacking different sized objects together, such as a stack of different sized books one on top of each other. I know of no way to currently do that using the existing geometry nodes available and from everything I've read on the developer portal I can't see any proposed nodes that would make it possible.
13 Comments
I also saw Hans Goudy's thought about the functionality technically already existing, and I absolutely share your disagreement with him, as the existing functionality has no way for automatic repetition of an operation. Pablo Vasquez has expressed support for porting the array modifier to nodes; while he's not as deeply part of the geometry nodes team, it does offer some hope to see that not all of the Blender team may share Hans' position.
I think an array node could be even more useful as a generic tool for repeating any sort of operation X number of times, not just repeating geometry instances.
To my knowledge, many modifiers are currently being switched to geometry nodes (which can be loaded on the fly in the same way as modifiers we have now) so it might be worth waiting on presenting modifier proposals until after that work is done. I imagine many new modifier possibilities will present themselves after Blender 3.0.
Actually according to what's on the developer.blender.org site, a comment from Hans Goudey would suggest they don't believe the 'Array' node is necessary.
Source: developer.blender.org/D9743
The same sort of attitude that ensured radial array never became a modifier, regardless of how requested it has been.
Not sure about this "flexibility first, usability last" approach that's permeated some of Blender's development. Great for devs, awful for artists. Artists want solutions that have all the tedious steps taken care of in one click, and then the flexibility to customize if they need it. I see absolutely no reason why this should be pushed back, so I'm with you. This node could simply emulate the node tree that would conventionally be used to create the same effect, I don't understand how that would be "inefficient".
The array modifier is inefficient because is creates new geometry instead of using instances. It would be nice to have arrays that don't use more memory with each additional object. It is also necessary to have an array where each object is its own geometry for some purposes.
I understand your frustration but the Blender dev team and supporting staff and budget is humerously small compared to their competition. While you complain, make a donation, then complain some more, and donate again.
Sorry, I don't mean to sound frustrated. I've just seen features pushed back with lax reasoning before. I've donated multiple times, had proposals committed to Blender master, regularly spend time on RCS...I'm not uninitiated. Suggesting that criticism is only valid when you "pay up" is not really in the spirit of Open-Source though.
To explain my position: Radial modifier was proposed years ago multiple times to MASSIVE support and rejected by devs many times. This was due to geometry-generating modifiers being deemed an "anti-feature". This was not a result of short resources, but of arbitrary decision making by those who prioritized efficiency/flexibility over usability. Efficiency is absolutely appreciable, but just because something is not its most efficient iteration doesn't mean that it shouldn't exist.
If you need to build a 12-node tree to create an array, that's not artist-friendly. We've been using the "inefficient" array modifier just fine for years. Also, as far as I'm aware Grady is suggesting that the array node do everything that a node tree would to achieve the same effect...it's no different to the efficient solution, it just requires less work from the user. He's not asking for the Array Modifier code to be used here at all.
The Radial Array was rejected on the premise that Dupliverts are the preferred efficient way to create arrays. This misses the whole point: using Dupliverts to create an array is a strenuous multi-step process and incredibly time-consuming. Everyone just uses the Array Modifier instead because it's one-click and easy.
This isn't anything new. There is commonly a discrepancy between the decisions made by devs and what would actually be useful to artists in any software....pre-2.5 Blender was riddled with them. This is where artist input is important.
I think the danger of geometry nodes is that the devs might give in to the temptation to think that if anything is 'possible' that is enough, with the view that if something is commonly desired then users can just keep some geometry node graph on file and append it to any file as needed. But in my view, if some common task requires 20 nodes to achieve, and it's the kind of thing that virtually every user of geometry nodes is going to need at some point, then there should be some kind of out of the box solution for it.
For this reason I would still like to see a simple bloody displacement node for geometry nodes. I don't see why I have to go through the hassle of creating an attribute, multiplying the normal against my scale value, then perform vector maths with the position and offset attributes just to achieve pushing the polys outwards slightly.
I just hope the blender devs don't see geometry nodes as a way of effectively handing to artists the ability to 'program' whatever features they want and thus 'we no longer have to'. Geometry nodes should absolutely come with the basic building blocks to achieve anything we desire, but it should also come with the basic common sense stuff out of the box.
Absolutely echo your concerns there. One major thing to consider is with the Asset Manager coming in 3.0, Geometry node presets are planned to come shipped. My hope is that if modifiers are being replaced with geometry nodes (as I understand they are) ALL currently available modifiers are ported and easily accessible as they are now.
The Solidify node seems to be going through just fine. The only thing stopping the Array node seems to be the same thing that stopped the Radial Array modifier....which we were assured would be rectified with 3.0.
If we don't spend the people and time to get it right enough on this first attempt we'll incur more technical debt and we don't have the resourses for more technical debt - that's what I imagine a lot of them think.
That is not what I said at all. All criticism is valid. But if you want something in Blender to be as good as it is in 3DSMax then you need to help them get a budget as big as 3ds, a team as big and as good as 3ds and you need to wait. 3ds/Maya/Modo/ etc. didn't get as good as it is in a mere 3 years.
Why would you want that from mesh array? I don't wanna instances. I wanna continuous mesh. For some reason conversation about having better array always ends up about instancing. Completely ignoring what array modifier is for.
thread TL;DR, there is a loop proposal on the dev discourse? devtalk.blender.org/t/loops-in-geometry-nodes-proposal/21357
We don't need the Array node. We need nodes for EVERY modifier! I think it isn't difficult — Blender already has these modifiers and developers just have to add them to Node editor.
It will be added in the upcoming updates I think