Hey there,

I'm trying to find a way to properly name the particle object coming from the Engine.
Doesn't matter what I do it always comes as “Ungrouped_01”.

Is it a bug or am I doing something wrong?

My goal is to be able to create separate groups of particles so when they are being generated by the Engine they are separated into different particle systems.
Is it possible?


Thanks
Alex

It's not a bug unfortunately. The splitting was only being done for primitives (polygons), which we're actually trying to move away from.

I recently added Maya sets support for meshes. I'm planning to look into particles soon. Would putting particles into Maya sets help your use case?

Otherwise, the best thing to do probably is to group them first, split into two separate objects, and blast away the non-selected groups. It's a bit inconvenient, but it should give you what you want. See the attached asset.

Hi Andrew,

I'm using the particles that are generated from the engine with our own instancer.
Right now the instancer is looking for a specific particle name. The moment you introduce two particle systems with the same name it get's confused.
Also, the engine itself gives an error and is behaving strange when there are two particle systems with the same name.
// Error: file: /mnt/software/maya/linux/maya2014ext1sp2/scripts/startup/initHUDScripts.mel line 501: More than one object matches name: Ungrouped_0Shape //

Sure, I can create the engine and then rename the particle objects, but then, if for example I reload the Engine asset the name goes back to default. Also, if the input has changed same thing.

I could write a script which will track down the groups and rename the particle objects accordingly, but that's a pretty ugly way of dealing with this. We want the OTL to provide us with the proper names of the objects.

Also, there is another issue with your example. My OTLs are in SOP context. I need to be able to input geometry from Maya. Is there a way to do it on the object level with direct connection?


Thanks a lot for your help!
Alex

Afeigin
I'm using the particles that are generated from the engine with our own instancer.
Right now the instancer is looking for a specific particle name. The moment you introduce two particle systems with the same name it get's confused.
Also, the engine itself gives an error and is behaving strange when there are two particle systems with the same name.
// Error: file: /mnt/software/maya/linux/maya2014ext1sp2/scripts/startup/initHUDScripts.mel line 501: More than one object matches name: Ungrouped_0Shape //

I don't think that's an error from the Maya plug-in. It's probably another issue in Maya for not handling nodes with the same name.

Afeigin
Sure, I can create the engine and then rename the particle objects, but then, if for example I reload the Engine asset the name goes back to default. Also, if the input has changed same thing.

I could write a script which will track down the groups and rename the particle objects accordingly, but that's a pretty ugly way of dealing with this. We want the OTL to provide us with the proper names of the objects.

Actually, if you turn off “Split Geos By Group”, the particle name would be named after the SOP node, which gives you some control over the name. So you could make the name unique within the asset. But if you have multiple instances of the same asset, you'd still run into duplicate name issues.

Hm, maybe I can try ensuring the nParticle names are globally unique? But that's not pretty either…

Is simply having globally unique node sufficient for you? Or do you actually need a custom/controllable name for the node?

Afeigin
Also, there is another issue with your example. My OTLs are in SOP context. I need to be able to input geometry from Maya. Is there a way to do it on the object level with direct connection?

Yup, it's possible to create a OBJ asset, and have input geometry. This is done by having adding SOP path parameters to the asset. Engine then treats these SOP path parameters as inputs. These SOP path parameters are usually used in an Object Merge node. This is also typically how OBJ assets are set up in Houdini to take input geometry. See the attached asset for an example.

Thanks for the quick response Andrew!

I need a controllable name so each instance of the Engine node will output a different particle. I also need to automate it so we integrate it better into the pipeline and have tools which will assemble the setup automatically.

If I can make the name of the particle pick up the name of the SOP node then I can write a python script which will rename the node according to let's say a string attribute exposed as a parameter. right?

If I take off “Split Geos by Group” off, the particle is named with the name of the asset name plus “1_0”.
Why would you need the extra numbers if the engine only outputs a single particle shape anyways?

Actually, what you said about naming the particle with the SOP node name makes more sense to me. Or any other way you can give us which will define what the output name of the particle should be.

Thanks a lot!

Strange, in my OTL the name of the particle is the name of the asset while in your example it picks up the name of the SOP.
Trying to figure out why your works and mine doesn't..

When the asset is in SOP context the name of the particle is the name of the asset while when the asset is an Object the name is picked up from the SOP node name the display flag is on.

It's quite confusing and not consistent. I think it'll be better if the name of the SOP node is used in both cases.

Thanks
Alex

Afeigin
I need a controllable name so each instance of the Engine node will output a different particle. I also need to automate it so we integrate it better into the pipeline and have tools which will assemble the setup automatically.

If I can make the name of the particle pick up the name of the SOP node then I can write a python script which will rename the node according to let's say a string attribute exposed as a parameter. right?

Even with a controllable name, the sync process would destroy any custom setup that you may have. I wonder if a post-sync callback script would be a better solution. You can then do perform any custom setup that you may have.

If I take off “Split Geos by Group” off, the particle is named with the name of the asset name plus “1_0”.
Why would you need the extra numbers if the engine only outputs a single particle shape anyways?

The “_0” is the internal name that Engine uses to identify its parts. As soon as multiple parts appear, thene you'll have “_1”, “_2”,… I thought about making it a special case when there's only one part, and remove that suffix. But for assets that output varying number of parts, it may make be more predictable and consistent to leave it in even when there's only a single part.

Strange, in my OTL the name of the particle is the name of the asset while in your example it picks up the name of the SOP.
Trying to figure out why your works and mine doesn't..

That's probably because your asset is a SOP asset. When the “split geos” option is off, a name is still needed to identify the part, so the SOP name is used.

My asset is indeed in SOP level.
For now I'm using a script which changes the name of the particle after the asset is created.
One thing that is definitely an issue for me is the fact that the entire setup is being rebuilt when I change my inputs. That's a bummer because I have to go in and rename the particle node again.

Is it possible not to reset everything when the input changes?

Thanks Andrew!

Afeigin
When the asset is in SOP context the name of the particle is the name of the asset while when the asset is an Object the name is picked up from the SOP node name the display flag is on.

It's quite confusing and not consistent. I think it'll be better if the name of the SOP node is used in both cases.

The part name is actually named after “the display SOP under the OBJ”. So in the SOP asset case, a OBJ node is created and the SOP asset is instantiated inside. This means the SOP asset itself is the display SOP. So it is a consistent behavior, though the reason is not intuitive. I can see what you mean though.

Is it possible not to reset everything when the input changes?

That sync is actually triggered as a convenience when you change the input using the AE. In a lot of cases, when the input is changed, the output would change so much that the nodes would require a sync. That's why a sync was added as a last step after changing the input.

What about adding an option to not do a sync after changing the input? That can definitely be done.

When you said integrate it with the rest of your tools, do those tools actually rely on the node's name? It's not possible to parse the output name, and then pass the name to those tools?

Perhaps another way is to add a custom detail attribute, like “maya_output_name”. And the sync process will name the output nodes according to that name?

What about adding an option to not do a sync after changing the input? That can definitely be done.

Having an option not to sync will definitely work in my case! Thanks!!

When you said integrate it with the rest of your tools, do those tools actually rely on the node's name? It's not possible to parse the output name, and then pass the name to those tools?

The tools do rely on the node's name.
If it was a connection it would have been worse because the connection is lost every time the Engine syncs.
If I load the same OTL twice let's say, the name of the particle node is the same and that doesn't work.

Perhaps another way is to add a custom detail attribute, like “maya_output_name”. And the sync process will name the output nodes according to that name?

This will definitely work. Question is how do I make the OTL pass that name to the output node?


Thanks!

Afeigin
This will definitely work. Question is how do I make the OTL pass that name to the output node?

The idea is to have the sync processes watch out for this detail attribute on the output geometry. If this detail attribute exists, the Maya plugin will name the output node using this detail attribute. And how this name is generated is completely up to you. For example, set through an asset parameter, or generated by expression inside the asset. Though this wouldn't work well if your output geometry become multiple parts (_0, _1,…), because all those parts would share the same detail attribute.

you're right, it won't work if your output is multiple objects.

The name needs to come from the OTL network itself somehow.
Like, naming the group or changing the name of the displayed SOP node based on the “name” attribute.
If I write some python code in the OTL UI and trigger it with the change of the attribute will that work?

Thanks!

Afeigin
you're right, it won't work if your output is multiple objects.

The name needs to come from the OTL network itself somehow.
Like, naming the group or changing the name of the displayed SOP node based on the “name” attribute.

Well, the node name itself is not enough. That has the same issue as a detail attribute. The concept of a “part” was created because one SOP node can output a mixed of geometry types (a mix of volumes, meshes, curves, etc.). However, most other applications can't really handle this, and they would want to separate this mix. So Houdini Engine divides them into something called “parts”. And each “part” would be exactly one type of geometry (a volume, a mesh, or cuves). As a result, one SOP node can potentially output multiple parts, which is why there are the “_0” and “_1” suffixes. And so all the parts from the same SOP's output would share the same detail attribute.

The idea of using the “name” attribute has come up internally before, which may work nicely for controlling the output node (i.e. part) name. However, we might not be able to get to this done in time for you to use.

Afeigin
If I write some python code in the OTL UI and trigger it with the change of the attribute will that work?

You mean having the script inside the Houdini asset, and have it poke at the Maya world? The name of the Maya asset node isn't available inside the asset, so it'd be tricky for the script to find the corresponding Maya node. While this is technically possible, we try to keep the two worlds as isolated as possible. (This isn't working out so well in practice, but we try…)

awong
I wonder if a post-sync callback script would be a better solution. You can then do perform any custom setup that you may have.

I mentioned the possibility of having a post-sync script. Could that also work?

A post sync script could work also.
I'll try poking around, I'm sure I'll figure out something.

Introducing an option not to sync the asset when the input changes, that's not too hard to implement right?

The Engine tool is designed to let the user adjust parameters and inputs all the time.
I am giving them a script which creates the entire setup with all the proper connections and I don't want them to worry about syncing the asset and changing the names of the outputs.


Also, I know a lot of people have been bothering you with this, but I was wondering if you can share your thoughts regarding making the ramps work in Maya. Will it happen any time soon?


Thanks Andrew!

Afeigin
Introducing an option not to sync the asset when the input changes, that's not too hard to implement right?

It's not difficult to implement, but I want to make sure this would actually solve your problem. I can go ahead and add it as an option.

But if you want to try disabling it manually right now, you could modify (or override) the AEhoudiniAssetTemplate.mel. In the setInput() function, there are several calls to houdiniEngine_syncAssetOutput. You could comment them out to disable the sync behavior when users click on “Set to Selection”.

Afeigin
The Engine tool is designed to let the user adjust parameters and inputs all the time.
I am giving them a script which creates the entire setup with all the proper connections and I don't want them to worry about syncing the asset and changing the names of the outputs.

It's worth clarifying that when I say sync happens when “input change”, I mean when a different node is connected to the input (i.e. connectAttr). If the connection stays the same, and only geometry data is changing, this won't trigger a sync, and nodes won't be deleted and created.

So once your scripts setup all the connections, will the users actually plug in different input nodes occasionally? If that that doesn't happen, then the sync wouldn't kick in, and your nodes won't be “reset”.

Afeigin
Also, I know a lot of people have been bothering you with this, but I was wondering if you can share your thoughts regarding making the ramps work in Maya. Will it happen any time soon?

I was actually about half way through adding ramp support a few weeks ago. But then I got interruped by some other issues. I've been trying to get back to ramp… Let me see if I can get something done this week… :?

It's not difficult to implement, but I want to make sure this would actually solve your problem. I can go ahead and add it as an option.
But if you want to try disabling it manually right now, you could modify (or override) the AEhoudiniAssetTemplate.mel. In the setInput() function, there are several calls to houdiniEngine_syncAssetOutput. You could comment them out to disable the sync behavior when users click on “Set to Selection”.

Ok, I'll give it a try see if it solves the issue for me.

So once your scripts setup all the connections, will the users actually plug in different input nodes occasionally? If that that doesn't happen, then the sync wouldn't kick in, and your nodes won't be “reset”.

Users will actually switch inputs constantly.
Right now I'm working on a grass OTL and users use proximity to objects to adjust different parameters. They constantly add/remove different objects, or use the same setup in a different area with different geo inputs.

I was actually about half way through adding ramp support a few weeks ago. But then I got interruped by some other issues. I've been trying to get back to ramp… Let me see if I can get something done this week… Confused

You guys are magicians!! Thank you Andrew!

Hey Andrew,

I'm using a button to callback a python script which renames the display node within the asset so the output changes. It works fine in Houdini but not in Maya.
The callback function is definitely running however for whatever reason it refuses to recognize the new node name. Syncing/reloading the asset doesn't work as it sticks to the original name.


Any thoughts?

Thanks!

That's probably because Engine never expected these kind of changes, so it doesn't re-fetch the node name.

Let me try to add the option to disable sync (when input changes) today. Hopefully that will help with your node name issue.