Author Topic: Exposing dynamic parameters from graph instances  (Read 4742 times)

The node graph I'm creating has other graph instances which represent custom built materials.
I need to expose the parameters from each of these instances, to the parent graph.

To do this, I'm iterating through all the parameters of the instanced graph and creating dynamic parameters:
Code: [Select]
dyn_val = aNode.setDynamicParameters
Now on the dynamic value, I need to create a function:
Code: [Select]
dyn_val.createFunctionNode(aFunction)
So far so good, except aFunction requires a FunctionEnum value.
To build this value, I'm attempting to extract the existing type name on the parameter, which will then be concatenated for use with FunctionEnum to retrieve the value:
Code: [Select]
param_type = aParam.getType()
# 16

The problem is that it returns the ParamTypeEnum value rather than the name (INTEGER1, in this case), and there doesn't appear to be a way to get the name.

This process would work fine if you're creating parameters while creating graph instances and explicitly define the types, but it falls apart when attempting to expose existing parameters.

I feel like I'm missing something here.
Is this the correct way of exposing parameters from instances?
Is there reverse mapping for enums?
Last Edit: January 24, 2019, 02:58:42 am

Hi Nev,

This isn't a use case that is covered with examples to the extent I would wish.
The raytracer sample shows how you can create dynamic parameters and refer to other parameters in various ways.
I believe the mapping you are looking for is implicitly defined in the file pysbs/autograph/ag_functions.py in the two dictionaries _sbs_type_to_class, _sbs_widget_to_class showing the relationship between widgets and types.

Let me know if this is enough to prod you in the right direction, otherwise, some sample code that shows where you get stuck would be useful and I'll see if I can give you a more specific response.


Hey David,
I looked through the example you mentioned but I didn't notice anything in there for my specific situation.
However, I did find a way around it after looking through a lot of the source code.
Not sure if it's ideal, but it bypasses the widget/paramtype enums issue when "cloning" the sub-graph parameter to the main graph.

Adding a snippet below for others who might encounter this.

Exposing comp instance node (sub-graph) parameters to main graph:
Code: [Select]
import copy

# Get parameters from your comp instance node (sub-graph).
params = aNode.getCompInstance().mRefGraph.getAllInputsByGroup('myParamGroup')  # Filter params from inputs by group.

# Expose your sub-graph parameters to main graph. Build associated functions.
for param in params:
    # Make param object independent. Prevents influence to sub-graph param it was copied from.
    param = copy.deepcopy(param)

    # Add param object from sub-graph to main graph; essentially cloning the param data.
    pysbs.api_helpers.addObjectToList(aGraph,
                                      'mParamInputs',
                                      param)
   
    # Set parameter to dynamic and create associated function.
    dyn_param = aNode.setDynamicParameter(aParameter=param.mIdentifier)
    dyn_param.setToInputParam(aParentGraph=aNode.getCompInstance().mRefGraph(),
                              aInputParamIdentifier=param.mIdentifier)

Thanks again for the help.
Last Edit: January 25, 2019, 10:25:44 pm