In the Scripts portion of my OTL I've added an OnCreated module, and successfully tested loading maya.cmds in my OTL when Houdini Engine creates/instances the OTL in Maya.

My question is, is there a way on the Houdini side to reference the name of the Maya DAG node that gets created when the OTL is instanced? On creation I want to produce a scriptJob that will listen for an attributeChange on the OTL's DAG node, but can't do that unless I know the name of the DAG.

That information isn't passed into the asset. Ideally, assets running in Houdini Engine shouldn't have so much knowledge of the host application. In reality, this isn't quite true. And the fact that the Maya python modules are accessible inside the asset isn't originally intended. I'd recommend not to rely on this too much. I think creating a scriptJob from the asset is interfering a bit too much with Maya. What do you want to achieve with the attributeChange scriptJob?

It's a test, but I wanted to create an arbitrary number of proxy objects that could be driven by control objects, both of which are created in the OTL.

I have a multiParm block that creates a sphere (proxy) and circle(controller) for each block instance, and I want the circle transform to drive the sphere transform, interactively. This works easily enough in Houdini via an attribute reference, but in Maya, because the circle is essentially a baked out version of the geometry in the OTL, no connection exists between the circle and the sphere in the DAG.

What I was trying to do as a workaround is to connect the output circle geometry transform to a parameter (or attribute, as it will become in Maya) on the OTL dag node, and that parameter would drive the internal sphere node. These connections were originally made using the Relationship Editor, manually. Because the multiParm can create an arbitrary number of sphere/circle duos, I wanted to connect these attributes dynamically whenever a pair is created/deleted, and therefore create a scriptJob on creation that would handle these connections.

I know that I could create these controls in Maya using a shelf button or similar, but was hoping to keep it all internal to the OTL, which could detect it's environment and act accordingly, so that they are self managing without needing direct interaction by the user for setup.

My HDA is attached, as an example, also a data flowchart to help illustrate what I'm trying to explain as my methodology.

Alternatively (I thought of this after I posted), instead of creating the circle controls inside of Houdini, then connecting the resulting Maya output back into the OTL, I could create the circles entirely as native Maya geometry, and connect those to the parm block on the OTL.

But this still retains some of the issues described above:

• +There's no “approved” way, as you said, for the OTL to know what the host application is, and change it's behavior accordingly.+The OTL, when running in Maya, has no way of knowing what “self” means in the DAG, so it's difficult to create objects that reference itself.
  
  Ideally, what I'm working towards is a tool that works differently depending on the host application (ie how the user interacts with viewport controls), does not rely on any kind of external setup, and has the same final result. Or maybe I'm trying to get more out of HEngine than it was designed for.

What you want to do does fit into the scope of Houdini Engine. However, it's probably quite tricky to achieve at the moment, especially since you want to dynamically create more controls and proxies.

Like you said, I think the best approach right now is to create the controls on Maya-side. I supposed you could do something like “import maya.cmds” to detect whether the asset is used inside Maya or not. I can see benefits to provide a way to distinguish this, since this doesn't interfere too much with Maya's state.

Regarding getting the DAG node name inside the asset, maybe you could use “ls -selection”? This is pretty dirty, but it could work. This also means the script would only work when it's displayed in the Maya's main attribute editor. In the script, you could then create the controls in Maya, and connected it to “self”.

Of course, we want users to, as much as possible, create assets without knowledge of the environment that the assets will be used in. I think we need to add support for two things in order to do what you want: 1) support controlling editable OBJ nodes, and 2) support dynamically creating OBJ nodes.

Another approach might be to use asset handles. However, asset handles can't grow and shrink dynamically like multiparms. This means you'd be limited to have a fixed number of pre-defined controls though.

Both approaches (editable OBJs and asset handles) are very much in the scope of Houdini Engine. But for now, you probably have to use some kind of Maya script to setup your asset.

Unfortunately, the hdaModule loads before the DAG is created, or at least before the DAG is added to the selection list. I did test and the DAG is added to the selection list after the hdaModule has loaded

I tried using maya.cmds.evalDeferred to circumvent that problem, which does give me the selection I need post DAG creation, but I can't think of a way of getting that back into the HDA, since evalDeferred operates entirely within the Maya environment.

So now I'm having the reverse problem - instead of Houdini not being able to get information from the encapsulating Maya environment, I can't inject information from Maya into the Houdini environment.

Ah, that's right… the actual asset is not necessarily instantiated when the asset is selected. What I was thinking is probably only suitable for button callbacks. :?

Hm, it might be better to use a MEL script to setup the asset at the moment. The MEL script would then manage the control objects completely on Maya side. So you don't need to call into MEL/maya.cmds from inside the asset.