A post was split to a new topic: Get point’s position, from UV (geometry nodes)
Are we sure “capture attribute” is the right name for this node? Based on what’s been explained to me by several people it feels more like a “set values on points” node.
I assume I’ve also been wrong all this time thinking there was some special connection between the terms “attribute” and “fields” and the nodes in the lower half of the input list:
1 Like
There is a little twist to it, but I don’t want to add more confusion, I think you understand what it does now.
The thing is that this value is stored only temporarily.
When you use a Set Position node, you change the position of the mesh and it will stay like this.
While with capture attribute, you set/store a value, and once that value isn’t used in the tree anymore it’s deleted. Capture can make sense to me, anyway it’s an abstract term that is a bit specific to how GN is working. “Set” implies something immutable to me. “Store” could do, but that doesn’t imply it’s temporary. I must admit that “Capture” doesn’t imply it either. Could be interesting to learn about the reasoning behind the naming , it will probably shed more light on how that works !
1 Like
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
From my understanding, since the node network is evaluated “backward”, anonymous attributes will not have any performance impact if they are not used, and the “data” doesn’t leave groups unless explicitly on the output, so the argument can be made that named variables add complexity since it is up to you now to decide what branch of the network you want the attribute to exist on (but my guess is a similar back-propagating optimization happens under the hood so this is maybe a moot point)
I can still see utility in the Capture Attribute node in small utility groups that operate across different geometries where it is used in conjunction with something like a Field at Index node to do a intermediate calculation which will then be stored in a Named Attribute… So, like a local variable vs a global variable.
So, yeah, if you look at your old networks, Named Attributes help clean up those long unwieldy noodles, but why go through the hassle of naming things for bitts of your network where the noodles are short and manageable?
Good luck.
3 Likes
What’s the point of “duplicate element”, a new node in 3.2, what can that node achieve that was not possible or practical before it? I see it can replace “instance on points” when the element is an instance, but what other use case this node has?
Most significantly, unlike the geometries’ Count or equivalent inputs, the Amount input for the Duplicate node is a field input.
So, in previous versions doing the following would be non-trivial (whereas now it kinda is (if you’re familiar with GN)):
… before you had to come up with non-intuitive strategies to produce enough points and then distribute them in some way, or you had to over-produce points and then delete a random amount.
Also, just demonstrating points here… the Duplicate node works with other Domains also, e.g. Curves and Faces - which opens up a whole bunch of other generative features only available through convoluted “kludges” before.
Good luck.
13 Likes
Can you describe exactly what the node network is doing to get this result?
I had to parse it for a minute or two… a 7*7 grid is created, and an attribute is stored on every point of it: the point index. This will be useful at the very end.
The points in that grid are duplicated a random number of times (different for each point), and boxes are instanced on these points. So at this point you’ve got a grid of boxes, most of them overlapping with their own duplicates in the exact same place.
Then, a random vector attribute (describing the dimensions of the box) is stored on every instance (so, on each box) and that attribute is used to scale each instance, as well as offset them from one another vertically to make a stack (what happens with the last set position and all that plugs into it).
The attribute created at the start -because it has been propagated by the duplicate elements node- is unique for each stack of boxes, so it can be used to restrict the accumulate field calculation to each pile.
@zeroskilz I took the liberty to explain, do say if I’ve got something wrong though. It was quite the exercise in deciphering other people’s node trees, the accumulate field is kind of hard to make sense of at first…
2 Likes
Pfff… Accumulate Field is sooo Blender 3.1. 
I originally learned about the Accumulate Field Node form the dev themselves:
Great tut series from Johnny Matthews to learn about the Accumulate Field Node and great for comparing to my example to see how the Duplicate Elements Node simplifies things somewhat… Also good content on the Duplicate Elements Node on their channel somewhere…
Hello everyone,
Is it possible to get the velocity vector of an object that has been added to a node group via object info node? I’m working on a project where the size of an object is supposed to be controlled by the speed of another animated object. I don’t suppose a specific node exists for this yet but a workaround that does not involve duplicating and offsetting keyframes of multiple objects would be great.
Are there any plans to add a speed/velocity input node sometime in the future or is this outside the scope of geometry nodes?
1 Like
Hi, not the reply you hoped for but… any time derivative such as velocity (or acceleration) isn’t possible in “vanilla Blender” as far as I know, this is what geonodes solvers are supposed to remedy in the future. I don’t think they have a timeline for this but it’s basically next as far as I understand, because it’s needed for hair simulation in their new open movie.
Now some people can do magic : https://blender.stackexchange.com/questions/108373/adding-a-delay-for-a-driver
maybe you can adapt that to your needs
1 Like
Hi folks
There are a lot of use cases where geometrynodes is used to bake vertex-colors exclusively for shading purpose.
https://twitter.com/bbbn192/status/1534920720987394049?s=21&t=gmMkNOzCCyddMXfB5fPVIw
https://twitter.com/80level/status/1534830160956035075?s=21&t=gmMkNOzCCyddMXfB5fPVIw
This feels quite wrong isn’t it ?
Using a procedural system to compensate the limitation of another 
not very elegant, and way more computer intensive than it needs to be, compared to exclusively sticking to shaders
5 Likes
I wouldn’t say it’s wrong. There are many non-traditional workflows out there that work very well. If someone is doing it, there’s probably a reason.
This one is puzzling me though. Why would you want to do this? I do have a few theories on the subject:
- Geometry nodes has access to attributes such as edge angle and vertex neighbors that shader nodes don’t. This could be useful for some cases, but if I were using this, it would make more sense to simply output these attributes and use them in SN rather than manipulate them directly in GN.
- The values are simply being used to set attributes for shader nodes. Doing so allows you to set unique values per object, making shaders more parametric. I do this a lot, but I think it would be even better if you could actually set attributes on an object level. Currently, we only have one color attribute that can be accessed in shader nodes without drivers. It would be better if we could set unlimited object attributes, without unnecessarily storing this data on every single vertex.
1 Like
There’s also the issue of GPU kernel size. adding access to all of those attributes in shader nodes takes resources, which puts pressure on the kernel.
And calculating and processing those attributes takes processing time. grinding through those calcs for each vertex and edge on a 1mil poly mesh takes some time, but is doable. doing those same calcs for every single sample of every bounce of every pixel is a hell of a lot more calculations.
using GN to do some geometry calculations/manipulations before passing it off to the shaders can indeed be more efficient. It essentially allows users to create complex data, pack it into a lookup table, and let the shader nodes directly access that pre-processed data.
I know cycles has been built with minimal pre-processing from day one, which has its pros and cons. using GN like this allows users to do some of that pre-processing, eliminating some of the cons, without bloating Cycles.
9 Likes
On the other hand, users need to heavily subdivide meshes just for the data bake. That’s the main thing bugging me when I see these use cases maybe
I wish we have some kind of node available to bake images in geometry node, it could be possible, even with python right now, after all an image is only but a grid of color data inside uv space, we have all the info needed
2 Likes
wow! this is very useful thanks.
Looking forward to the solvers I guess
I definitely agree that some of the 4,5 and 6 level subdivisions are a brute force solution, and pushing more vertex data does indeed eat up some vram, but it doesn’t inflate the kernel. when the kernel gets too big, you see more and more crashes that are harder and harder to trace down.
1 Like
Don’t forget, unless the attributes are animated, you can always output a lower poly to a different object and bake them to a texture. This may seem limiting, but no more than traditional game asset workflows.
2 Likes