I try to keep most nodes minimized and edit them from the n-panel. It helps me to give a node a name which describes what it does.
The * (-1) node is a math node which multiplies its first input by (-1).
You wrote …
When I Pug the radius into the
Ico Spereit gives me an error (red connecting line).
Sorry, my mistake. The Radius node in my example is a renamed ‘Input/Value’ node.
It is not the ‘Input/Radius’ field input node.
Oh thanks! It worked 
Here comes my next question:
I have two Susanne objects
How can I compare the position of the faces of the two Susanne’s and then select the faces with equal positon. My guess would be to use the Position field, Capture Attributes and then a Comparison node. But I can’t really get it done. Maybe a different field? Any ideas/suggestions?
Thanks!
That is correct. And for extra understanding: all field data (including attribute data) only has meaning coupled with a geometry. So to compare two attributes of different geometries you first have to transfer them to the same geometry.
This is easier to understand if you consider that the equal node loops over the (domain of the) geometry it connects to (on the right). So it needs data for each point of that domain.
When a node has an ‘attribute’ socket the data that flows over the dotted line is not the attribute data itself (i.e. it’s not an array of numbers or vectors), but just the internal ‘name’ of the attribute. The attribute has to exist on the current geometry to be able to use it. Hence the need to transfer the attribute data to the current geometry before comparing it.
Hello, guys.
Is there any way of instance several objects and each one have its own texture? I’ve tried to search but I only find two ways: using a material index, which randomize the materiais per face, which isn’t ideal, or using several objects (each one with its own texture) and then instance the whole group.
But the question is if I can have one object and randomize several textures on this only object. Thanks in advance!
Or even better: I could use just one texture instead, but randomizing their vectors/placement to make each instance to have some part of that texture (with different locations and rotations, for instance). The issue is: how to do it?
I thought you might find this file useful:
https://pasteall.org/blend/67ddee8e990846dab313c97734adc6ee
Make sure to set the texture’s X and Y tile count in the node to ensure the uvs are mapped properly.
The test texture is by PamNawi on opengameart.org.
Thanks to @higgsas for help with the UV squares group!
Hello @HooglyBoogly , may I bring your attention to this bug (or not?) : see my post above
Hi there, I’m trying to recreate this in Blender (first pic). I created a node tree, but i don’t know how to add multiple lines between several instances in GN (see second pic). Any ideas? 
Works like intented! Thanks 
Is there a way to increase the number of lines and randomize the line’s thickness?
Hi, I want to create an animation of endocytosis. Basically when an object (sphere in the video) will fall on to a surface (the cell’s membrane), I would like it not only to deform that surface but also to be surrounded by the surface/membrane as the object moves inside. I have managed to deform my surface with proximity node but now I can’t figure how to make the surface surround the object. Any ideas?
Try to take all the network of node used to deform the surface, duplicate it and connect it in sequence with the original, that may do the trick!
Hi guys! Kinda in need of help here.
I’m doing an array of street lamps on a road, the street lamp object is a collection of various parts, comprised of a spot light, scattered on a curve. What I’d like to do is to have one of the instanced lamps to have the spot light turned-off. Do you think it’s doable? Especially since I’m instancing an entire collection I can’t find a way, maybe doing a separate array instancing only the spot light might help? Thanks in advance!
Desired result:
Points → Delite Geometry : Selection → Random Value : Type → Bool
Thanks man, as I imagined I did a separate array for the spot light and then put delete geometry for it, thanks for your help!
What do you mean? can you send a node tree?
I would like to once again raise the issue of not having fast booleans in geometry nodes. Fast boolean is absolutely essential for architecture work, since it doesn’t care whether a mesh is watertight or not. For example, in many cases, I use curves, etrude them, and then need to boolean out the part of what’s forming the walls that sticks above the roof boundary. If fast boolean would be available in Geonodes, this would be easy, and the curve can remain a curve.
Otherwise, i currently need to convert the curve to mesh, extrude, and then use a boolean modifier, as curve objects don’t have a boolean modifier outside of geonodes. This workflow is quite destructive and if something changes (and it always does, many times), then the whole destructive process need to be repeated.
It’s a mystery why fast booleans is not an option in GN. It has been asked for many times in this thread and elsewhere, but I’ve never seen a response from the developers.
But the problem you’ve described, there is a simple workaround. Make a dummy mesh object, add GN modifier and bring in your curve with object info node. Now you can use boolean modifier while still having the curve for non-destructive workflow.
Since we now have store named attribute and named attribute nodes, can anyone think of a good reason to ever use capture attribute node? I keep thinking about it, but I can’t figure a valid reason why I’d ever choose Capture Attribute over Store Named Attribute…?
Capture Attribute just seems like an inferior version of Store Named Attribute, which forces you to either use a given attribute right after you capture it, in which case there’s no point in storing it, or carry it alongside the node tree using very long, messy node links all the way to the place where you actually need to use it.
One could argue that the benefit of the Capture Attribute is that the attribute is anonymous, so that it doesn’t clutter the list of named attributes and doesn’t cost as much memory/performance, but this is not valid for performance reasons, since anonymous attributes remain stored in subsequent geometry whether you need them or not, while named attributes actually give you option to remove them down the node tree to save some performance and memory.
What am I missing here? What would be a reason to not deprecate anonymous attributes, other than backwards compatibility with existing scenes which use Capture Attribute node?
