Can you share your file and/or test it with this patch? #138186 - Nodes: auto-hide unused inputs if usage depends on menu - blender - Blender Projects
4 Likes
been waiting for this for so long, thanks!
That works really well! Wow, thank you!
Hereâs the file, though itâs currently very much a mess. Still working on Object Offset and Merge. https://www.dropbox.com/scl/fi/5dat63udsozwb19gntie9/New_Array_02.blend?rlkey=wcfdva3r9rwgdcntbmw61o1fp&dl=0
Going through this has made me appreciate how great the Array modifier really is!
3 Likes
This, combined with disabling (not deleting) the modifier so it can be re-enabled later to get back to the primitive would be perfect.
Hi @jonlampel thanks for working on this. I took a look at your file together with @pablovazquez and wanted to share some initial feedback if I may:
General UI:
- Tooltips missing
- Make Panel Toggle (e.g., for the Use Merge)
Good job to see the new features already in the modifier. However this makes it a bit harder to review/compare with the old modifier.
Would it be possible to first âstep-backâ and do a 1:1 conversion of the old modifier (keeping the same naming and UI)?
This way we can more easily test to make sure we have complete backward compatibility. And it will also help test the limitations of the existing node group/modifier layout system and see what may still need to be tackled.
Separate topic, as with any other Geometry Nodes based modifier, we get the Output Attributes and Manage panels âfor freeâ.
It would be nice to find a way to hide them. Either:
- Per-modifier
- Similar as to the Show Node Groups option.
- âShow Extra** Panelsâ
- Per-node groups
- Similar to the Usage option, appliable for all the users of this Node Group.
- A Display panel, after Usage.
- Both? Default setting per-node group, toggleable by modifier.
I think both would be the most interesting option.
** âExtraâ is just one of many possible names. Donât want to get lost in discussing here 
4 Likes
Oh gosh yes, this was not at all ready for testing generally, just sharing for testing Jacquesâ branch (which works great!).
I can for sure do more of a 1:1 for the first iteration, but I want to make sure to build it in a way that makes it easy to support them later. For example, considering scale randomization at the start informs how the fit distance method behaves when using a relative offset. Once the proper structure is there, itâs easy to backtrack.
6 Likes
Awesome! Another recreation of the Array modifier was posted a few days ago, if it helps as inspiration or collaboration, havenât tested it thoroughly but seems quite close.
2 Likes
This is great! The merge control needs to merge only at the intersection of the copies and not the entire object, but beyond that it seems pretty spot on.
One more UI feature that geometry nodes donât have yet is red colored icon when modifier isnât doing anything (or being evaluated?). Geonodes only does that if group isnât chosen, but itâs not enough information. Wouldnât be able to replicate what Boolean does, or when bevel has 0m amount.
I think some sort of generalized check should be used, like: Nothing is being outputted, or there is output but:
- Output geometry is exactly same as input geometry.
- No attributes are captured, stored, or outputted.
If both are yes then show red icon.
8 Likes
I want to talk about another issue which is very problematic I found recently.
The reason itâs problematic for asset creation, is if I make a rotation socket in node group, it works well in the node tree, I can easily slide to 100 degrees without problem.
but when itâs used as a modifier, itâs painful to scroll, I can only scroll to about 10 degrees, which is nearly none. I have to type in values.
This made me once thought to make it into radians-driven value for my assets, until I found degrees worked surprisingly well in the node tree.
Ok, I have an array modifier thatâs not entirely finished but is pretty close and could be used for basic testing.
In the file youâll see one modifier, Array Classic, that attempts to mimic the original 1:1.
Here are some UI limitations I found:
- An object subtype option would be nice so that the dropdown search for the curve object only shows curves rather than every object.
- Clicking in the empty space to the right of a toggle panel toggles the boolean rather than the panel opening and closing.
- Tooltips all have the socket number rather than the name of the input.
- Vector 2 inputs like for the UV offset are not possible
And some geometry node limitations (or maybe limitations in my knowledge of geometry nodes lol):
-
The original modifier affected all UVs, but in geometry nodes the user has to specify an attribute. This is not convenient because the UV map canât be chosen via a list of UV maps but is instead typed in manually. Multiple UV maps could be adjusted, but it would require adding more inputs for each one. Some way of accessing all UVs in geometry nodes would be nice.
-
The merging behavior of the array modifier canât be replicated, at least in a reasonably performant way. I think the Merge by Distance node needs to have an input that specifies which target vertices can be merged with the original. There needs to be a way to make sure the vertices of one copy never merge with each other regardless of how close they are and can only merge with vertices of the previous or next copy. I tried several workarounds, but they all fall short in different situations.
-
I donât think thereâs a way to efficiently estimate the maximum number of copies needed (and support variable sizes) without a way to break out of a repeat zone once a certain threshold value is reached.
Other geo nodes notes:
- Iâm using some of the newer nodes a lot and absolutely loving them!
- Can the bounding box nodes have a size output? Itâs easy enough to use a Subtract, but I do that pretty much every time I use a bounding box node.
- Could group inputs be organized into their panels? Working with 40-ish inputs is pretty wild when making new connections
- Could new inputs be hidden on nodes that have unused inputs hidden?
- The panel toggle feature was pretty hidden, so at first I thought it wasnât available in the latest builds. Can it just be an option of the panel? Having it be a new menu entry in the add menu but only when a panel is selected is a bit confusing.
New features:
In the file youâll also find a modifier, Array ++, that has some new capabilities. (Note, it will look messy if not using Jacquesâ build.) These are some things Iâve wanted in the modifier for a very very very long time. Iâve tried to still keep it as simple as possible while also making it WAY more powerful. Hereâs what you can do:
- Circular arrays. Easy enough. Just has some basic controls.
- Collections. You can array a collection instead of the active object. Perfect for books on a bookshelf, boxes in a stack, etc.
- Rotation and scale now work with all offset types (including UVs) rather than just the object offset type. No more adding empties for simple rotations!
- Randomization. Itâs awesome.
- Stacking. You can specify the bounds shape in the Geometry section and it will stack your copies accordingly when using relative rotation, random rotation, or random scale. I need to add a spherical option, but already itâs crazy useful. Beginners shouldnât have to learn how to use Accumulate Field to stack stuff.
- Fit Length and Fit Curve have an option, Fit Inside, to take into account the size of each copy so that the total length of the result actually fits inside the specified distance.
- Fit Length and Fit Curve have an editable Max Count. In the modifier it was hardcoded, but in this version, it is even more important since there are more ways of accidentally making the count go towards infinity (like setting it to Fit Length and decreasing the relative scale).
- Option to realize instances. Turning this off is super helpful if you want to boost performance when itâs at the end of the stack, keep the transform data around for use on later geo nodes modifiers, or place the instances along a curve without bending the mesh.
- Option to output instance index, for use in shaders and other geo nodes modifiers
There are still a few things to fix, and it could definitely use some optimizing, but it should be ready for basic testing.
6 Likes
Great job Jonlampel! Very useful new functions in the modifiers!
One thing thats a bit concering though, is that the Geomtry node Array is about 100x slower than the old modifier oneâŚ
Old modifier
New geomtry node
Even worse with the advance one, taking almost a second doing the exact same thing as the old modifier, only 2000x slower!
I seriously do not see how Geomtry Nodes can replace the old modifer anytime soon with this performance. @HooglyBoogly Is there any plans to adress this?
9 Likes
The node setup itself definitely needs some optimization. My version computes a lot of extra things and more work needs to be done to skip that when the new options are not used. Just wanted to get it all working first. The Fit Distance and Fit Curve are especially brute forced at the moment.
Can you also try the version from Fwfeet that Pablo linked to above? That is a better comparison of the exact difference in performance between nodes and built-in modifiers since the way itâs computing the array is much closer.
Can you also share your test file and settings? Curious how much I could bring this down just by optimizing the setup.
4 Likes
Can you also try the version from Fwfeet that Pablo linked to above? That is a better comparison of the exact difference in performance between nodes and built-in modifiers since the way itâs computing the array is much closer.
Its way, way faster! Yay!
I just set the array count amount to 10 000 on all of the modifiers, a high but not at all uncommon amount for some things. Also, it was done on just a cube.
1 Like
Ah got it, thank you!
Are you using Merge? On my end, with the advanced version, that is the majority of the performance drop. With 10,000 cubes and a relative offset of 1 on the X axis, I get a total time of 290 ms. Hereâs what the slowest nodes are in this case:
- 278 ms - Merge by Distance
- 8.7 ms - Set Instance Transform
- 2 ms - Realize Instances
- 0.2 ms - Instance on Points
So actually, most of the calculation is trivial but the array modifierâs merge must be crazy fast in comparison. If I turn off merge the total time drops to 12 ms, and if I skip realizing instances itâs about 9.5 ms.
2 Likes
No, I did not use merge in my tests, but I also noticed that turning it on makes it crazy slow, I really wonder how the old modifier is so effective? Perhaps it only merges the first 2 ones and the last one, the rest just being instances or something?
1 Like
I think because the modifier only needs to check the vertices of the previous and next copies while the geometry nodes one needs to check every vertex of every copy. Thatâs one of the big limitations mentioned above.
Interesting that itâs so much slower on your machine even without that, though. Iâll try testing on some different computers and see whatâs up.
4 Likes