Oh thanks! It worked 
1 Like
Here comes my next question:
I have two Susanne objects
- A normal looking Susanne and
- One that at some part has distorted faces (see pic)
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!
1 Like
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.
1 Like
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?
1 Like
I thought you might find this file useful:
https://pasteall.org/blend/67ddee8e990846dab313c97734adc6ee
It allows you to:
- Use a texture of any size, as long as the tiles are constant.
- Randomize each tile based on the given index.
- Randomize rotation of each tile. (Works best with square aspect ratios.)
- Use a custom ID for randomization. (such as mesh islands)
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!
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
1 Like
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?
1 Like
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.
6 Likes
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.
5 Likes
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?
1 Like
This is not true, anonymous attributes will be removed when they are not referenced anymore. The capture attribute node can actually completely skip generating the data if it isn’t needed.
In general, anonymous attributes give us quite a few optimization opportunities that we wouldn’t have with named attributes.
But I think the bigger reason to prefer anonymous attributes is that connections are expressed with node links, and you don’t have to use arbitrary (or potentially conflicting) names to reference data. Of course different people will prefer different workflows, but the anonymous workflow is definitely more portable and probably easier to read, especially when we have something like hidden node links.
We’re not considering deprecating anonymous attributes, that was never the idea with adding the named attribute nodes.
8 Likes