This is really amazing. I am hoping I will see an option to sample image texture soon. Right now, there’s still just the old attribute texture sample node that outputs the good old clunky geometry monolith.
I just tried, but i got stuck because the switch node seem to convert the field back to a single value, i suppose there’s quite a few nodes that don’t support the fields yet and we need to hunt for them once the proposal is accepted?
https://pasteall.org/blend/558975f10bc049f393809359aae788b5
This “Bug” i encountered above raise a question:
Then the problem is, how can we check if we are working with a field or a single value?
perhaps the viewer node could connect to any inputs value, so we could check the value from an input directly in the spreadsheet? so that would mean that the spreadsheet would not be exclusive for geometry but could read any values
just thinking out loud
BTW fantastic work, i never though it would be made so fast
Socket inspection can help figuring out if something is a field. Just hover over a socket that has been computed before. Afaik the switch node is the only node without a geometry socket that does not work with fields right now. All the other available math nodes should work.
Nodes that have a geometry socket but are not in Hans’ screenshot above, should work exactly like before.
Viewer node support for fields (as described in the proposal) has not been implemented yet.
Ah indeed this new feature. this cause crashes in the file above btw
Viewer node support for fields (as described in the proposal) has not been implemented yet.
Nice to see it’s in the plan
I agree about it being intuitive, I love the shader workflow so I did not have to think too hard to get things to work
I mean it’s no so hard to do something with it, noise texture is awesome by itself, can’t wait to see this in daily alpha, but what I’m really missing in attribute system is integer attribute. AN have it, SV have it, even text experimental build have it for letters order ([+10] to logic [-10] to workarounds), kind of don’t understand, why GN don’t have it for instances/points? Is it to heavy for CPU? Without it it’s hard to tell which system is better, because even current’t one would not require so many workarounds with this attribute.
Big thank you for all devs for making blender more capable every day.
Will it be possible to have a toggle to see builtin attributes values in the spreadsheet?
right now everything is hidden from user
Perhaps attribute in the spreadsheet that are read-only and not accessible directly could have a .active = False in their GUI?
There’s a few things i do not understand in this new system
How to create a attribute with random values, random float does not work well with field, it still randomize a constant value which is counter intuitive perhaps?
→ with the new index input
How to “grab” an attribute from the geometry, i did this mockup while geonode was still a proto, an attribute get would be needed for this proposal so the fields can be joined/grabbed from the geometry easily
Why there’s no fill property when creating an attribute, it seem weird to start from an empty attr
→ attribute input is doing it automatically when connected
Not completely sure if I understand what you mean but there’s an ID property and an index input in this build.
Unless something changed, id is not integer like in animation nodes. I mean integer attribute containing list of instances in certain order which could be use as any other attribute. Just as text_id if I remember correctly from text experimental build for instances. For example when you creating mesh line, first point would be 0 second point would be one, third point would be 2 and so on. I know that we can use point separate and then make attribute math operations , but this is work around exactly because we don’t have access, to integer. Line is simple example, but it goes deeper with number of dimensions. You can see it in your spreadsheet screen to the left from rotation, but you can’t do math operations on it unless I missed something.
The attribute node is to use the values of an already existing attribute, that’s why it is in the input category. It does what you want in the second capture if I understood it correctly (i.e. “grab” the attribute from the geometry).
For the random float, you can connect an index node to the seed to get different values.
Regarding “filling an attribute” I don’t think that’s the intended workflow in this proposal. Instead, you create the field that you need and then flug it where you need it, like this:
gotcha thanks for this index tips,
it seem indeed very logical and behave like H t
about the “attribute get”:
so this input attribute node is getting an attribute from a geometry?
and how do it know from which geometry to get the info?
let say if you have two geometries with the same attribute name…
Here’s a mock up on how i expected to “get” an attribute field
Edit:
You’re right the attribute input is automatically getting an attribute field value from a geometry (main one it seem) witouth even being connected to anything
my brain is bleeding at that fact,
i don’t understand how such system can work if we work with multiple geometry in one nodetree
precising from which geometry we want our attribute from like the mockup above seem to me like a necessity
But did you see my screenshot? By pluging the index as an Id in the point instance I get an ordered ID, and I can do math operations with it, as I did. I’m not sure what you mean with “unless somehting changed” since the index node and id sockets I’m talking about are specific to this prototype. Am I misunderstanding what you mean?
the ID column is the one on the right, the other is the row number. I can’t see your nodetree but it seems you didn’t plug the index to the ID?
Holy (…) so this is what I missed, thank you, got to try it!
Don’t let the attribute search when the node isn’t plugged into anything mislead you. The attributes it can use depends on the field the attribute node is connected to. Think of it like a “context”. Each field is evaluated with a certain geometry, and the attribute node and index node will use values from that geometry.
Aha! clever
Less intuitive perhaps
as it indeed fooled me good
Yeah, since it’s just a prototype I think it’s fine, but a more complete version would give some more visual feedback to make this more clear.