An example how this is handled in other (albeit much smaller) FOSS project:
Is there a way we could transfer every single attributes easily in Geonode 3.5 now? In Houdini we can do that easily, and it is more than convenient
Meta processing of attributes is currently no in the plans.
Could be done with loops, once implemented
Iâve created a nodegroup plugin that basically loop transfer a list of attributes
and it is more than convenient
Especially when doing intensive mesh restructuration, (ex when the mesh do not have any of itâs original topology left).
Does anyone find the Viewer node workflow kinda clunky and frustrating? Every time I use viewer I immediately get confused about the flow of my node tree because now the outputs branch into some random node floating about making everything messy.
Wouldnât it make sense to delete the viewer node and replace it by being able to âfocusâ nodes like in any other normal node based software? Instead of Ctrl+Shift clicking a node to spawn a a messy, floating viewer node, you could simply Ctrl+Shift click any socket, and when done so, the socket pin would turn into a bit larger, highlighted eye icon.
A bit crappy mockup, but you get the idea (the previewed sockets could possibly have constant screen space size so they donât get lost when zoomed out):
You could always have only one Geometry socket and one Attribute/Field socket set to preview at a time (in the same way the Viewer node works now). Ctrl+Shift clicking a socket which is being already previewed would remove the preview state, and Ctrl+Shift clicking into an empty space would remove all previews (both geometry and attribute at once, if they are active).
This way the user would not have to make a choice between previewing the node tree along any point and making the node tree appear confusing.
EDIT:
Hereâs a bit more refined mockup. Still not sure about it but itâs a bit better than the previous one as it doesnât overlap the text. Fixing that overlap would otherwise mean adding odd padding to the right of the node frame.
This concept uses only half of the eye icon and uses the original socket shape as the âirisâ of the eye:
EDIT2:
One more better mockup, because the one above wouldnât look that great if two sockets right next to each other were being previewed (one geometry and one attribute)
10 Likes
Yeah I agree so much, especially when you have big wide node groups you press ctrl + shift + click and the viewer is so far away so you unzoom and the zoom to find it and etc etc, very clunky workflow sometimes i just to quickly preview the node and I would love to preview it without a new node, I think this was even discussed when implementing the viewer to GN.
Did a quick mockup how it could look, and the eye viewer icon could simply be added into overlays in case you want to turn it off 
1 Like
I do not think the eye icon in the node header would work, because nodes can have multiple outputs. User needs to be aware which specific socket output they are previewing. If the icon was in the header, the only information user would have is âitâs some of themâ. You also would not know if you are previewing a geometry or an attribute on a given node.
In your example above, the icon in the node header would make it unclear whether you are previewing Geometry socket, Curves socket or the Surface Normal attribute socket. (Or possibly one of the Geometry sockets and also the Surface Normal attribute socket).
1 Like
Youâre absolutely correct lol, totally missed it
Yeah it confuses me also, I proposed something similar to your suggestion a while ago in rgiht click select. Right-Click Select â Blender Community
Yea that was my initial reaction to the viewer node as well. However in practice I am absolutely not bothered by it, since itâs quite obvious whether or not itâs active and what itâs connected to. I wish it were smarter in the sense that it could detect the data type itâs connected to automatically, but thatâs about it.
Now that Iâm thinking I think combining the eye on the node and on the socket is a good compromise, so you could just ctrl + shift + click on the node many time to cycle through the socket while you can easy toggle between the viewer.
Hereâs my problem:
-
When I Ctrl+Shift click to preview a node, the viewer just pops up at random near place. When I start previewing other nodes further down the tree, itâs often ugly when the preview node link just goes backwards because I didnât âtake the preview node with meâ when I panned the view:
The only way to make this less ugly is to place the Preview node at the very end next to the Group Output node, but then most of the time, itâs out of the view:
This means it can not be toggled easily using the eye icon. And it also means that when you want to add a new node, you are not sure if you are adding it to the viewer path or the group output path:
The only way to alleviate both of these issues is to be constantly dragging the preview node around, taking it manually with you wherever you pan and zoom your view. -
When you have a node with multiple output sockets, with the viewer node, you canât just click a socket you want to preview. You need to be annoyingly, repeatedly Ctrl+Shift clicking the same node until you cycle to the right output.
Having Ctrl+Shift clickable the sockets themselves and not having and Viewer node that has physically visible node links would be improvement in both these scenarios.
3 Likes
I believe this has been working for several alpha versions now, at least if you Ctrl+shift click on the socket or the label close to the socket. It might have been a coincidence, but it works for me in GN (not in shader nodes though). Iâm testing it right now and I can confirm it works in GN.
How to extract individual instances when those are generated / modified using GNodes?
Make Instances Real seems to be working only when existing objects are used (using Object Info and without altering their geometry - because then it doesnât work either).
Be more specific. No idea what you are asking.
How is it unspecific? Itâs rather clear. He is asking about a way to break instanced geometry generated by Geometry Nodes into separate objects, which are individually selectable in the viewport.
Well, it wasnât clear to me either 
Anyway, to answer the question (if that is it) thatâs not possible from GN . Because the way GN is structured as a modifier it always spits out a single object.
Youâd have to apply the GN modifier and then separate by loose parts.
But how would that work? Itâs not as if you can edit the separate parts of a procedurally generated collection of objects. Except hypothetically if we maybe in the future would have something like âdifferential editsâ on top of generated geometry.
Hi, another post from me stating the importance of incorporating Fast Boolean in geometry nodes. And whilst, I try to avoid booleans by using other means as much as possible, they are inevitable when working on architectural design.
Here is an example that is just not possible with Exact Boolean, due to the signficant computation time it takes:
I am currently working a bridge design proposal with very unique pavement pattern, and I am grateful that geonodes has advanced far enough for me to use it in this manner instead of Rhinoâs Grasshopper, as in most operations Geometry Nodes outperforms other element. However, the fact that there are no fast booleans yet, leads me to do some funky hacks, like creating duplicates of just what i need from the large geometry nodes trees organisations, just so I can use the fast boolean modifier for intersecting many tiles with large panels.
Interesecting a number of panels is very typical at the architectural and landscape scales, and Fast Boolean performs rather well in 95% of the situations, without the slowdown of Exact boolean. It would be really great to have Fast booleans incorporated into Geometry Nodes.
To do this at the moment, I am creating a placeholder isolated duplicate object from my main object that contains the geometry nodes tree:
And then interesecting with an extruded pattern
6 Likes
With Object Info â Geometry we can do Instance on Points, Scale / Rotate Instances etc., and then Make Instances Real produces individual instances - as expected. But if I touch the mesh, this no longer works.
So your statement âit always spits out a single objectâ isnât entirely true, instead I would call the current behavior as âit works as expected in some scenariosâ⌠which is a bit confusing.
Please understand that being able to retrieve the individual objects is very useful especially when exporting the generated stuff into a game engines, for example when you use GNodes for scattering objects which are supposed to be dynamic.
Trying to get the objects by separating from a joined mesh is really a messy solution, not applicable in many cases at all (when you want to prevent objects origins for example).
Our use case - we scatter trees on a game terrain, where each tree is a collection consisting of a visual mesh and a collision model. While the visual meshes can be joined into a single object, those trees collision models need to be exported as individual objects, with the correctly placed origin and extra object-specific settings necessary to make it work correctly in the game.
I think you would be excited by this post that @Howard_Trickey posted on the blender chat nodes-physics forum! (hope he doesnât mind me reposting it):
I think I have persuaded a friend of mine to help implement really-fast-exact booleans. He used to do research in this area and he and I now both agree that the EMBER approach looks better:: EMBER: exact mesh booleans via efficient & robust local arrangements: ACM Transactions on Graphics: Vol 41, No 4
So he and I will be working on that (in between me continuing to work on bevelv2). I may also do a fast-exact-bisect-by-plane node first, as a testbed for the math routines we have to write (256 bit integer arithmetic, some determinants of 4d things).
7 Likes