Hi,

Is there a way in PDG how I can pass workitem data array to parameter attribute?
For example:

And get all array without querying an individual item (@new_string.1)

Thanks
Ostap

If you mean you want to reduce all the values of a PDG attribute into a single value, you would have to use a python expression. For example to set a string parm to the space-separated list of string attribute values:

Can you please explain why you are not providing the whole array for the array attribute? Why did you decide to choose the first element (from the array) and not last or middle?

Do you mean when using @attrib in HScript? It works that way because that's how the @ HScript operator is defined, and how it works in SOPs for geometry. The @ operator returns either a string or a float value and @attrib is a shorthand for @attrib.0. It's not specific to PDG - PDG is using existing HScript functionality that was created for accessing geometry attributes.

I think that the idea boils down to providing better support for array attributes out of the box in HScript.

Yes, it is currently possible to use Python for that purpose, as @chrisgreb mentioned, and I'm personally fine with that, but this is not a workflow that we can promote to artists to pass array values around.

The first step would be to make sure that setting a string parameter with @myattrib(or an alternative syntax if backwards compatibility needs to be preserved) will expand all its values like Python's join()method does, instead of only outputting the first value as it is currently the case. We do have @myattrib.0if we only want to access the first value, so having it also available with @myattribis redundant (in the case of string parameters).

The second step, for convenience reasons and also to confirm the support for such a workflow out of the box, would be to provide additional methods in the pdg.Portclass to evaluate such array parameters to what they actually represent. So if we have a string parameter myparam set with the value 1 2 3, then we'd get the choice between these methods:

- self['myparam'].evaluateStringArray(work_item), returning ['1', '2', '3'].
- self['myparam'].evaluateIntArray(work_item), returning [1, 2, 3].
- self['myparam'].evaluateFloatArray(work_item), returning [1.0, 2.0, 3.0].


Note that I only mentioned string parameters until now. For integer and float parameters, the behaviour of passing @myattribwould remain the same as it currently is, that is returning the first element only.

Ideally, at the node level, we would stop hacking arrays into space-delimited string parameters and would start consistently representing arrays as multiparm blocks. The problem comes when trying to set such a multiparm with a PDG attribute representing an array. It is once again perfectly doable through setting a Python expression for the instance count but it'd be nice for artists to be able to use something like argc(@myattrib)or, even better, @myattrib.countinstead.

In the case of multiparm blocks, setting the nested parameter values in the Parameters Interface window to something like @myattrib.#works well out of the box, so that's great, but here again it could be more artist-friendly to have an easier way to setup such values without having to set their defaults through the Parameters Interface window, because it's not a place we should encourage artists to interact with. An idea would be to add a right-click context menu item that'd display the list of nested parameters and that'd allow setting their values with an expression in the same way than we can already do with all other parameters.


I hope this makes sense!

ChristopherC
The first step would be to make sure that setting a string parameter with @myattrib (or an alternative syntax if backwards compatibility needs to be preserved) will expand all its values like Python's join() method does, instead of only outputting the first value as it is currently the case. We do have @myattrib.0 if we only want to access the first value, so having it also available with @myattrib is redundant (in the case of string parameters).

That's possible to add, but it would have to be a new HScript function instead of using the @ syntax. There are backward compatibilty concerns with changing the behavior of @attrib, but I think it's also the case that you'd want the flexbility to configure the delimiter between array entries. E.g “1 2 3” vs “1,2,3”, both of which might be useful depending on what's receiving the attribute data.

Do you think something along the lines of pdgarray(“attribname”, “,”) would work?

In the same way that every shorthand notation in the form of @myattribmaps to an HScript function, I think that it'd make complete sense to have a pdgarray()function, indeed!

I also like the idea of being able to set a custom delimiter but it seems like it might not integrate so well with the current toolset, such as the arg()and argc()HScript functions? And this would require the pdg.Port.evaluate*methods to also support a custom delimiter while making sure that both the implementation and the caller expect the same delimiter. For example, if I were an artist and knew that I could pass an array to a string attribute, how would I know what delimiter the implementation of that node expects? As much as I love flexibility when developing libraries, agreeing on defaults sometimes helps to build conventions and more streamlined workflows. But yes, the drawback is that we wouldn't be able to have an array element containing for example a sentence of space-delimited words. Which is why trying to fill string parameters with arrays will always remain hacky, and should be discouraged in favour of multiparm blocks.

Regarding the lack of @shorthand, I'm sometimes reading discussions of artists trying to figure out how they can access a given data value using a @shorthand instead of calling the equivalent HScript expression in some given edge-case scenarios, so I know that they'd be looking for the same here and I can understand them since it'd be much more artist-friendly/intuitive. Would introducing something like @myattrib.*work?

Absolutely agree with Christopher.
Any chance to avoid additional python expression and follow by shortcut idea (something like that @myattrib.*)?

Faced the same problem

self.evaluateStringArray(work_item), returning

Any chance for this to happen?