Useable internal attributes of SOPs

[Raschko]

Hello.
I stumbled over a tutorial (https://youtu.be/KRkFARl40Uw) that shows that the Mountain SOP uses an attribute “height” (if available on points) to define the height per point. Quite useful, I didn't knew that.
I haven’t found a system behind for which attributes something like this works or how one can find this out.

Of course there are attributes like pscale that are used by many nodes, those are listed in the documentation (https://www.sidefx.com/docs/houdini/model/attributes), and there are nodes like the scatter SOP for example, where you can define the attribute name that is used (density by default).

But is there a way to find out where something like this (in the mountain SOP) works which I’ve overseen? Or is it just the Mountain SOP which maybe just has an undocumented feature?

Just want to be sure I’m not missing something big.. ;-)

[anim]

7 hours ago, Raschko said:

I haven’t found a system behind for which attributes something like this works or how one can find this out.

any node that is based on VOPs and uses Bind VOP or Parameter VOP would automatically bind attribute of the same name and type if exist instead of its value (unless mapping is altered in Binding tab ), (materials work the same way)

Mountain SOP just happens to be one of those nodes, it's just an HDA and if you dive inside you can see it's based on attribvop, dive deeper and you will see Bind VOP named height, that will bind automatically
you can also see lot of Parameter VOPs in there, those would bind also, like one named parm_elementsize so if you create attribute called f@parm_elementsize =5; it will override value of that parameter, etc, some have prefix parm_ just to make it more difficult to override by accident, but the principle still works the same so its still possible

for nodes that are not HDA's based on Attrib VOP it's not that easy to tell, it may be hardcoded, a lot of them though offer some kind of interface where you can pick attribute etc...

[Raschko]

Thank you Tomas,
that makes sense. I didn't come to my mind in this case to have a look inside the operator.

I have to say, it would be great to have that in the documentation (or marked in the UI, for example on the mouse over tooltipo f a parameter). So users know instantly when they can use these attribute names (or, worse, when they should not use certain attributes name to avoid interfering with the nodes acidentially).