Hey guys, wanted to see if I could get some recomendations on a particular issue I am having

I have a fantastic sop which perfectly layouts uvs for lightmapping. These uvs I create need to eventually make it to meshes in maya as a second uvset, like so

Maya mesh w 1 uvset. –》h engine digital asset –》 maya mesh with 2 uvsets.

So, my limitations are:

- my mesh in maya has to preserve material assignments and the first uvset

Hengine only output 1 uvset
my meshes coming out of Hengine are sorted differently because I need to input multiple meshes, combine them, then output them separate again via partition

So my approach has been to take the output of the engine node and use transfer attributes in world space to get the new uvset back to the original mesh. This has worked well, but started noticing issues over uvs going to the wrong shell due to problems with transfer attributes

What would really help me

Is if we could output multiple uvsets, as then is just a matter to transfer shaders

Be able to sort the meshes out of the engine in a predictableblender fashion, i.e. via a point and primitive attribute f. I can ensure this on a single mesh, but not on multiple mesh outputs

In lieu of that, I am attempting something using openMaya, but I am wondering if y anyone had any recommendations?

Thank you!

Even if the asset can output multiple UVs, wouldn't it still be difficult to preserve the transfer the materials? It seems like the main problem here is to preserve the order of the geometries. I did a simple test on preserving the order of the meshes. If I combine the meshes in Maya in a specific order, and use connectivity+partition in Engine to separate them out again, the pieces come back out in the same order.

I think the key here is to carefully connect the meshes to polyUnite in Maya. This does feel fragile though, but I think it's worth a try.

oh wow!!! that would be great if it worked predictably. is it because connectivity + partition separates them out in their indexed order? I believe maya's polyUnite also sorts them in a similar fashion as the merge SOP

now, how do you figure out which output piece goes to which input piece though? I am currently able to do so because I have the multiple inputs… but perhaps if I merge then in a foreach in order of inputs they would sort based on the input order much like with the polyUnite?

I agree with you. It does seem to me that it all just goes back to mesh ordering. the material transfer is a slightly easier problem to solve I think, but it is not the true solution

What are your thoughts on being able to sort the geometries in maya based on a point and primitive attribute? one of the advantages in houdini is that this is so much easier to do in there… it would be nice to be able to do the same going out to maya if possible

grayOlorin
oh wow!!! that would be great if it worked predictably. is it because connectivity + partition separates them out in their indexed order? I believe maya's polyUnite also sorts them in a similar fashion as the merge SOP

Yeah, I think that's the case. Of course, there's still the limitation that each Maya mesh node can only have one piece of geometry.

grayOlorin
now, how do you figure out which output piece goes to which input piece though? I am currently able to do so because I have the multiple inputs… but perhaps if I merge then in a foreach in order of inputs they would sort based on the input order much like with the polyUnite?

The output nodes in Maya are named after the Houdini group name. So as long as you name your group in the partition node, like piece$CLASS, then the output nodes should be something like: piece0_*, piece1_*. Those should match the order of the mesh nodes that go into polyUnite.

grayOlorin
What are your thoughts on being able to sort the geometries in maya based on a point and primitive attribute? one of the advantages in houdini is that this is so much easier to do in there… it would be nice to be able to do the same going out to maya if possible

Hm, and you can't use a Sort SOP now because you need to keep the primitive and vertex orders the same? Could you have a separate asset for sorting each piece separately afterwards?

Hm, and you can't use a Sort SOP now because you need to keep the primitive and vertex orders the same?

That is what I thought right? the meshes are split on the host application side, therefore I cannot use the sort sop

Could you have a separate asset for sorting each piece separately afterwards?

but by then I do not have any sense of what the original IDs where right? or where you thinking that I could find that out from the UV inputs and outputs?

After your UV asset, the mesh is split by group into several pieces. You could then apply a sort asset on each piece, so that each piece is sorted separately. Maybe I misunderstood something?

In order to sort the pieces, I need something that tells me how to sort them (i.e. some attribute). In houdini, I can do this using a primitive attribute, but in maya, such things do not exist ): But if I could figure out the order of the outputted assets, I could then have a second input to the sort asset to use the guide piece as a sorting guide (almost like a wrapper to the matchTopology SOP)

I think this at least gives me a few things to try out in your test of splitting the mesh which was polyUnited, did they points and the primitives maintained their original order? or just the points?

grayOlorin
In order to sort the pieces, I need something that tells me how to sort them (i.e. some attribute). In houdini, I can do this using a primitive attribute, but in maya, such things do not exist ): But if I could figure out the order of the outputted assets, I could then have a second input to the sort asset to use the guide piece as a sorting guide (almost like a wrapper to the matchTopology SOP)

Ah, right. It'd be nice to have a way to input/output arbitrary attributes…

grayOlorin
I think this at least gives me a few things to try out in your test of splitting the mesh which was polyUnited, did they points and the primitives maintained their original order? or just the points?

Both the points and primitives maintained the original order.

Hope you can get something working!

O M G it worked!!! this is so epic

My solution was even a little bit different I was able to rely on the ordering of the foreach SOP output (which fetches all my inputs) to be “broken” in the correct ordering. I literally was able to do all the hard work (ensuring proper topology by “transferring” my new UVs VERY CAREFULLY and with surgical precision back to the mesh that came from the foreach

By the time I got into maya, a transferAttributes by component mode did the trick. Awesome!

This incident did remind me (not like I need it ) how amazing houdini is compared to other apps such as maya. There was NO frigging way I was going to get this working the way I did using openMaya. The hengine is also a godsend in regards to data wrangling. Simply amazing.

That's awesome!

Hopefully in the future, we have better support for multiple UVs (and colors) so that you don't have to jump through these hoops…

I look forward to it I will admit that part of my difficulties stemmed from having to convert my meshes to polysoups temporarily which really scrambled the indices, but it is good to know that we can at least rely on this and have Houdini do the heavy work. But the more flexibility we have with the plug in, the more we will be able to do quicker and easier

I do also look forward to more data wrangling via detail attributes. Having information such as input names and then be able to do something to them on sync based on another detail attribute would add a lot of power to this workflow