What would the spreadsheet viewer do with fields anyway? Would it simply add a custom column of any value type, or would it preview all the temporary fields of a single geometry?
If it adds a custom column, should multiple viewers at once be supported?
The thing is, fields do not belong to any geometry, itās just an out-of-context function, like an expression. The āPositonā field is not the position attribute of any geometry, itās just a reference to something called āPositionā in the evaluated data flow context. So it does not make sense to have collunms for fields, because they are just not actual geometry data.
I was going to suggest a node that took a field, evaluated it on an input geometry, and output a column with a custom name, but I just realized that I reinvented the store attribute node.
I guess with fields, the spreadsheet itself is not as necessary as I thought. Although, when working with fields, I find myself wishing there was a quick reference of changed values, as I was used to with the named attributes workflow.
Maybe we can allow anonymous attribute to be temporarily shown in the spreadsheet? But I think in the prototype they said it was a bug to have anonymous attribute shown in the spreadsheet, I am not sure whatās their design decision. My idea is to have the attribute capture node showing the anonymous attribute only when viewer node (or some similar thing) is hooked up to it. Donāt know how ideal it would be though.
The idea is to support a field input on the viewer node. So you just plug in whatever field you want to see in the spreadsheet. And it would also show as an overlay in the 3D view.
How does that work though? For example if I just plug a position node to the viewer node, how does it interprete the position field?
Yeah, there are some details to work out. I suppose it would show another column in the spreadsheet, maybe highlighted to show itās from the viewer node. There could be options for how to display different attribute types in the 3D view overlay settings as well.
Hello guys!
Iām looking for a way to dynamically get the number of points at certain moment on the tree or the last Index ID number. Is there any way to get the length of the index list and store as a constant attribute? 
But I thought, in order for a field to have any meaning, it has to be evaluated on a geometry of some type. Would it simply be shown on the current group output?
That would be a job for the attribute statistics node that is (I think) super close to inclusion : ā D10202 Geometry Nodes: Attribute Statistic node
The size output should be piped into a freeze attribute node and there you have your constant
That being saidā¦ Iām not sure how you would go about accessing the last component ? without lists
Thanks for your reply!
But, just now, Lucke decided:
āFeels like the Size output shouldnāt be in this node, it has nothing to do with the attribute itself.ā
Oh boyā¦ 
Where Size should be? Along with the Index input node then? 
I assume the size means domain size? Like number of points in point domain? I think we can just look at the T panel in the spreadsheet for that. I mean it makes sense to remove it, itās not the size of the attribute, but rather the size of the geometryās domain. Yeah I think we can just use the id for that
Iād like to use that exactingly number, from the spread sheet mesh > vertex > #number_of_points, dynamically in a field. Do you know if we can do that currently?
Thatās what I call āthinking outside of the boxā! Bravo! 
I understood it! Thank you very much!
Unfortunately I was running this branch:
What is the current branch that we should explore regarding the Fields Geometry Nodes?
Thanks @Eary for the light there!
Just use master and go to User Preferences. There you can enable Developers Extra and in the Experimental Tab you enable Geometry Nodes Fields.
Oh boiā¦ Dear Dalai! I was able play really happy on the fields prototype branch getting used to the concept:
But in the master alpha 3.0 things are feeling strangeā¦ It feels like the fields paradigm is not happening under the hood and forcing to go to the attributes workflow to solve things like thisā¦ I donāt knowā¦ 
Why this donāt work anymore in master and used to work on prototype branch?
The Attribute Fill is not part of the Fields implementation in master. Once Fields is out of experimental (before that actually) you will see a warning in your nodetree if you are using nodes like that one.
Basically you should only use the nodes that are already āportedā to the fields system. Those are the ones available in the Add Node menu when you enable Fields.
I used fill because thereās currently no way to show fields in the spreadsheet, Hans said they will get the viewer node to work with fields but I honestly donāt know how they are going to do it. until then the only way to do it is to use Attribute Fill/Store Named Attribute node(havenāt been implemented yet).
In real life practice you will just use it without storing it, I stored it because I wanted to show you in the spreadsheet.
I seeā¦ I will try explore the Alpha build again keeping that in mind. Thanks for the clarification!
AbraƧos (de um brasileiro morando no JapĆ£o) e bom trabalho pra vocĆŖs! Vida longa e prĆ³spera!
