i tried having random position with geo node instead of adding a key and adding a modifier in the graph editor, how can i replace that with geo node ?
I didnât understand what you meant by " instead of adding a key and adding a modifier in the graph editor" but, here is a random vertex displacement, this should kickstart your journey,
exagon to circle socket not allowed, you need to use a statistic node
(if a dev read this: what about an implicit conversion?)
Iâm not trying to displace the geometry, already made a little custom node to do that, im trying to have a random number on the z axes of the OBJECT, not the mesh or position.
i tried having random position
i meant different position of the cube, literally, not the position as in like position attribute
1 Like
The only way that I can think of (itâs sort of a workaround) is that instead of leaving the Index input of the âRandom Valuesâ node unplugged you can try and plug in a âValueâ node with the value set to 1 so that the âRandom Valuesâ node can output a single random value.
Screenshot of nodegroup
1 Like
ah sorry
then try this? maybe
itâs literally using a noise texture, perhaps overkill for what you need
edit* no need for statistics
ps* you can control the speed with noise scale 0.01 for ex will be slow mo
1 Like
thatâs what i was thinking about, but as float usually have a grey circle i didnt think of plugin it, so the green circle is for integer ? it should be grey and when we connect it with a float number it should do a round operation automatically
Yes, usually the little grey circle is used to represent float values (and green for integers) but from what Iâve observed, currently, the Blender node editor system doesnât seem to be bothering too much about having matching input types (float, integers, vectorsâŠ) connected correctly to each other (meaning that if you plug a float value into an integer input or vice versa, for most of the times theyâll be working just fine. The same thing about how Vector values can be plugged into Color input sockets and they still work perfectly fine). But I agree, perhaps for the future, a little update on switching the color of the input sockets to match the types is properly going to be a vast improvement. And also, if I remember correctly, the last time I check, if a float value is connected to an integer input, the rounding operation will be automatically handled for you.
1 Like
2 Likes
Iâm interested in understanding better exactly what the trade-offs are between fields and attributes. Iâve tried to read this whole thread, but I havenât seen developers mentioning the repercussions of fields. I donât think all of those repercussions were immediately apparent to everyone commenting on the fields proposal. I think coders can often see the long-term impacts of decisions more easily than users can, because every time thereâs any conceivable ambiguity, they get smacked with it in the face and have to make a decision about how to handle it.
Iâm still in the âwho moved my cheeseâ phase of dealing with fields, unfortunately. It seems to me that one of the issues with fields is the ambiguity: when we get position, when exactly are we getting position? With attributes, that was clear: we say what position weâre operating on by our noodles. To deal with that ambiguity in 3.0, the answer is, âwe get the position immediately before we start evaluating the GN modifier.â While I canât put my finger on it, I have this intuition that we may have some trouble with turning attributes, mid-stream, into other attributes; that resolving the ambiguity in this way limits what we can potentially do with a single GN modifier. But this is only an intuition, something that feels risky. And even if it is risky, there are potential workarounds, even if theyâd be clunky.
It seems to me that the main advantage to the fields implementation is that we no longer have the MixRGB/Attribute MixRGB kind of duality; unfortunately, the 3.0 implementation makes it look like that node savings is more than made up for elsewhere. And it seems to me that a fields implementation is not actually necessary to solve that problem, because it could be abstracted behind interface, with Blender silently making a decision about which to use on the basis of noodle connections.
There is no ambiguity of where the position comes from in 3.0. The quoted sentence above is actually wrong (there might have been a tutorial that got this wrong). Which position is used has nothing to do with the modifier. Instead the position comes from the geometry that the field is evaluated on. Maybe the image below makes this more clear. The red arrow shows what you said (if I understand correctly), while the green arrow shows where the position actually comes from.
11 Likes
Thanks, that makes a lot more sense and helps out.
It still seems to me that there are some ambiguities there. Consider this one:
Or this one, how many Blender users are going to get this right on the final exam without peeking?
Obviously, Blender decides to do something here. There is something that it does, and consistently so. But Iâm not sure people are going to be able to predict from the nodes.
These are artificial examples, and there are other structures we could use to remove the ambiguity, but I think once users start putting a lot of nodes in a graph, theyâre going to run into problems with their intuitions related to these kinds of things (and the fact that there are hundreds of nodes is going to make it much harder for them to figure out where the problem is.)
These examples are less obvious indeed, and require a bit more getting-used-to. I do think that many of these low level nodes will be wrapped by more powerful node groups that work in a more obvious way in the future. Still, there is no ambiguity here:
- In the Transfer Attribute node, the
Attributeinput is evaluated on theTargetgeometry. TheSource Positionon the other hand is evaluated on the geometry passed to the Group Output. - In the second example, the first Vector Math node is actually evaluated twice. Once on the position of the geometry passed to the the first Set Position node and then again for the second Set Position node.
3 Likes
It helps to think about it this way: Fields describe a mathematical function, a formula. They are only evaluated on the input socket of the geometry they are attached to. Probably not how it works internally, but thatâs how I think about it.
So the calculation (logically) doesnât happen in the fields nodes, they just describe the calculation itself. The actual calculation happens in on the geometry, as described by the field nodes.
Again, thatâs probably not how it internally works, just what helps me think about it.
1 Like
That is how it works internally. Also see this paragraph from the first post:
2 Likes
Is that true? From reading the docs, it sounds like the Source Position is relative to the Target.
If thatâs not how it works, then the docs really need to be clarified.
The hints are in the names.
Target Geometry vs. Source Position.
I think itâs pretty clear.
The names Target and Source are very confusingly chosen for the attribute transfer node I think.
the Target of the attribute transfer is where the attribute data comes from, so it transfers an attribute from the target. The source position is the position of the vertices you are applying the attribute to. So the source points where the field is evaluated, and the target is the object to interpolate the attribute from.
Or maybe I have completely misunderstood. Which wouldnâ;t be the first time. 
Fields are a great system, but thereâs work to do in the naming and documentation I thinkâŠ
3 Likes
Yes, your explanation is correct.
What Iâm wondering is how could the naming be improved? What better 2 words to use, to hint the Target Geometry / Source Position combo?
From Geometry & Current Position?
Idk⊠Seems off 
Hello
3.0 is great,
When weâll be able get or write ** attributes by names within** the nodetree again?
The new way to access attribute is not intuitive and very cumbersome, it is also causing us a lot of limitation in our studio pipelines
Itâs confusing because the intial design, as quoted above, supported accessing our attribute like we are supposed to.
Last time i tried the field prototype, it was possible, now itâs not anymore and we are forced to pass every single data in modifiers even if it could cause huge inconvenience âŠ