Maya: Implementation of Ornatrix family

[moonyuet]

Changelog Description

Implementation of Ornatrix Exports in Maya Ornatrix Rig: Publishing Ornatrix or any Ornatrix related objects. If there are any painted map(s) by user, they are published too and the published maps would be located in the {your publish folder}/resources Ornatrix Cache: Publishing Ornatrix fur stimulation as ornatrix alembic cache. It can be loaded as Arnold StandIn, Vray Proxy and Alembic reference while it can be loaded as the file cache in the Ornatrix-related GuideFromMeshNode.

Additional info

Although Ornatrix cache loader can add HairfromGuideNode into the operator stack, it can only be showed once into the stack editor(due to some api limitation". Users need to select the objects they want to load the file cache in order to add the cached nodes "safely" into the operator stack.

• [x] Load Ornatrix Groom
• [x] Validate Ornatrix content
• [x] Connect Ornatrix Groom

Testing notes:

Ornatrix Rig

1. Create Ornatrix Rig with your geometry which is assigned with ornatrix fur
2. Publish
3. Texture maps and ma scene would be published along with rigsettings which stores all the ornatrix related parameters.
4. Start new scene and load the reference scene of the published ornatrix rig
5. Once you start publisher, the ornatrix cache will be automatically created with the references of the ornatrix rig.
6. If you load the ornatrix cache, it will create group with a mesh shape which includes the GuideFromMeshNode storing the abc file cache.
7. You can also load the ornatrix cache with Arnold StandIn, Vray Proxy and Alembic reference

[ynbot]

Task linked: AY-5677 Feature integration/unit tests

[LiborBatek]

I was able to produce oxrigMain product for Ornatrix Rig successfully as a first step

with resource files (ornatrix maps) too

[LiborBatek]

When loaded into empty workfile as oxrigMain

This is probably not the best as it gets full character hierarchy with also char rig....

We should decide how to approach it (if similarly like with yeti integration or by using Ornatrix Grooms as presets....) not sure whats best atm tho...need to investigate it more

[LiborBatek]

I have briefly tried to use Ornatrix Groom asset as it saves all the setup including the resources as seen here:

Here is the workflow in nutshell...I have just loaded my Character Rig as Ayon Asset and saved my hair groom from it... and later using such preset in freshly loaded character rig (it also works for pointcache if the pose being in the same coords aka rig pose)

https://github.com/ynput/ayon-core/assets/112623825/5a601df8-b031-4cfa-853b-81de6ad747de

The issue is that when I have tried to apply such groom setup on something else than the character rig it got broken if not in the reference pose when connecting...aka when applied on lets say shot anim pointcache so it needs some thinking still how to approach it.

@BigRoy @moonyuet what do you think? I suppose we should follow regular workflow for Ornatrix rather then adopting our Yeti like one (by duplicating and connecting transforms etc on groom meshes and publish those instead for OrnatrixRig product)

We should first think how we approach it and if there any other limitations speaking of the native "preset" of Ornatrix using Groom aka preset as in the video above...

[moonyuet]

@BigRoy @moonyuet what do you think? I suppose we should follow regular workflow for Ornatrix rather then adopting our Yeti like one (by duplicating and connecting transforms etc on groom meshes and publish those instead for OrnatrixRig product)

When I was working on the ornatrix cache loader, there is a function to connect the guide node with alembic cache to the selected mesh and it would be showed in the operator stack editor. But there is some issue when there is no selected mesh, where the operator stack editor can't add the guide node. I am not saying this is not possible, but we need some more time to work on creating nodes and loading the data (which has been stored in all the ornatrix-related_node) for Ornatrix. Or even we no need to have two product type(rig and cache), and just ornatrix. And we can create nodes and loading the data(textures, cached alembic) all at once. And making sure these nodes are all added into operator stack editor

[BigRoy]

Thanks for tagging me - admittedly going based off of the video and the comments I can get an idea of what the issue is but knowing nothing of ornatrix I don't have any tips on how to solve this best.

It sounds like:

1. We want to export an Ornatrix "Rig" which is an ornatrix groom that we want to re-apply to e.g. an animated character.
2. The Groom requires a static rest pose as it gets applied to the mesh so that it can work for deformed meshes.
3. The ornatrix operator stack allows to include a shape node as the rest pose (which can be stored within an Ornatrix preset).

Meaning there's basically an Ornatrix built-in way to solve number 2 OR we decide to make a full rig that itself 'includes' meshes of which one is static and one is maybe the output mesh - which is then somewhat similar to how the yeti rig setups are designed (or at least recommended).

What is the best choice depends hugely on those who want to use it. But I'd say the Yeti way has been very flexible because you can build many hacks into a rig that maybe just a ornatrix preset may not. Yet I've also heard others felt it was "technical to set up". If we could rely fully on Ornatrix "presets" then all we'd need to export is just that preset maybe and hence no maya exports of our own?

But as Kayla stated she did face some issues from the API using the Ornatrix methods - I can't help much with that without having access to Ornatrix with the same setup and debug from there to see where it really fails.

[moonyuet]

Thanks for tagging me - admittedly going based off of the video and the comments I can get an idea of what the issue is but knowing nothing of ornatrix I don't have any tips on how to solve this best.

It sounds like:

1. We want to export an Ornatrix "Rig" which is an ornatrix groom that we want to re-apply to e.g. an animated character.
2. The Groom requires a static rest pose as it gets applied to the mesh so that it can work for deformed meshes.
3. The ornatrix operator stack allows to include a shape node as the rest pose (which can be stored within an Ornatrix preset).

Meaning there's basically an Ornatrix built-in way to solve number 2 OR we decide to make a full rig that itself 'includes' meshes of which one is static and one is maybe the output mesh - which is then somewhat similar to how the yeti rig setups are designed (or at least recommended).

What is the best choice depends hugely on those who want to use it. But I'd say the Yeti way has been very flexible because you can build many hacks into a rig that maybe just a ornatrix preset may not. Yet I've also heard others felt it was "technical to set up". If we could rely fully on Ornatrix "presets" then all we'd need to export is just that preset maybe and hence no maya exports of our own?

But as Kayla stated she did face some issues from the API using the Ornatrix methods - I can't help much with that without having access to Ornatrix with the same setup and debug from there to see where it really fails.

The workflow I can think of now is:

1. Create Instances with the target mesh assigned with the Ornatrix-related nodes, has an validator to check on the Ornatrix's content, export the Ornatrix presets along with other resources(e.g. textures, file cache)
2. Create Instances with target mesh assigned with the Ornatrix-related nodes, has an validator to check on the Ornatrix's content, export maya scene with other resources(e.g. texture, file cache).
3. Create Instances with target mesh assigned with the Ornatrix-related nodes, has an validator to check on the Ornatrix's content, export maya scene with other texture resource. There is still cache family for exporting the alembic cache
4. Create Instances with target mesh assigned with the Ornatrix-related nodes, has an validator to check on the Ornatrix's content, export json file which stores all attributes data of Ornatrix-related nodes along with other resources. When users loaded back to the scene, they need to select the target mesh to load the ornatrix data so that maya can find the target mesh and create the Ornatrix-related nodes connected to it(it also ensures the ornatrix nodes connected to operator stack editor). The attributes of nodes would be synced with the attribute data from the published json

And 1 causes the possible rig broke as we can notice in Libor's testing. Any thoughts? @LiborBatek @BigRoy

I will continue to do more research on the Ornatrix to see what's best for the implementation.

[LiborBatek]

@moonyuet haha Im completely lost in your suggested workflow sry (no offense just me being dumb :) ...I would need practical example.

I can think of diving more into Ornatrix and best practises first (myself) and find out how it should be done when transfering groom from char to char (aka between same char but different scenes)

[moonyuet]

@moonyuet haha Im completely lost in your suggested workflow sry (no offense just me being dumb :) ...I would need practical example.

I can think of diving more into Ornatrix and best practises first (myself) and find out how it should be done when transfering groom from char to char (aka between same char but different scenes)

I agree that we need to do more research on the Ornatrix grooms, like doing more manual test before tweaking on the code.

[LiborBatek]

I have made some more investigation and self education regarding Ornatrix best practices and found out few things...

Speaking of our new publish family oxRig ...we should def. use the native Groom presets as they cover 95 % of all usecases (there is just one unsupported type of setup hair from mesh strips which we do not need to take care of as its not very common - seems more like for converting game ready mesh type haircards to actual hair strands setup)

I have also found out that its even simpler speaking of the native Groom preset as if you apply it without any selection it will bring also the groom geometry!! so it does internally exactly what we do manually speaking of our Yeti rig workflow!

And last reason to use such approach being that Groom preset can be used accross any supported DCC so its ideal for transfering the hair rig inbetween lets say maya and max or c4d ....it should be 100% compatible.

excerpt from user Ornatrix docs and the cmd for using it

OxSaveGroom [-path <string>] [-thumbnail <string>] [-optional]

OxLoadGroom [-path <string>] [-scale <double>] [-detail <double>]

I will attach vid soon to demonstrate how easily it works....

Speaking of our oxCache product it should follow standard yeti workflow we have but using Ornatrix Alembic format it seems there is native support for rendering via Vray as proxy and I expect that the same goes with Arnold etc.

[LiborBatek]

Here is the process...

https://github.com/ynput/ayon-core/assets/112623825/10dc3719-d0f6-4440-a60d-c4e15240c1af

and last step might be to make connection of outmesh and inmesh to connect those ShapeNodes and it could also be done similarly to our xgen and yeti workflows via right click Action as connect geometry too...

It would fit the rest of hair addons and would follow the same practice.

Only question now if there is a way to use such Groom like referenced file or just locally created one or how to approach versioning of such product (again as it is locally created by loading the groom preset) any ideas how we could treat the versioning of oxRig @moonyuet @BigRoy ??

I can imagine to use OxLoadGroom command to create such setup in empty workfile and save the maya scene as a final published oxRig product (see vid mockup below this post) after publishing done ...so we can load such oxRig .ma representation via Loader then and be able to Manage it instead of triggering OxLoadGroom [-path <string>] [-scale <double>] [-detail <double>]

We could produce both mySetup.oxg.zip and mySetup.ma files to publish folder so it could be versatile enough offering two possibilities within Ayon > to "Load Ornatrix Groom" and/or "Reference oxRig" which should bring in classic maya referenced scene with already premade Ornatrix setup inside (ideal for managing versions later on)

[LiborBatek]

Mockup of the possible way...

https://github.com/ynput/ayon-core/assets/112623825/0742388b-7356-4877-a77f-e8034b864d04

"Publishing" of the already created hair setup originating from the native Ornatrix Groom preset and saving it as a maya scene

[moonyuet]

Mockup of the possible way...

Ornatrix_Publish.mp4 "Publishing" of the already created hair setup originating from the native Ornatrix Groom preset and saving it as a maya scene

So for the improvement on the Ornatrix Rig product type. (Just the note for myself.) We need to add the ORNATRIX_GROOMS_DIR for loading groom presets The workflow for Ornatrix Rig is:

1. Create Ornatrix Rig Instance with selected geometry which needed for the fur stimulation
2. Publish the Ornatrix Rig with maya scene and ornatrix groom presets to the publish folder
3. When loading Ornatrix Rig, user can connect the presets by using the action -> connect ornatrix rig with inMesh and outMesh

The versioning -> We might need to clean off the old one and add the new one, but we can do some test later.

[LiborBatek]

Now speaking of oxCache product within AYON as already been said we def should use Ornatrix Alembic format as it offers some advantages (display vs render hair count etc)

There should be exposed settings on the Publish Instance for the user so he can tweak all the format settings it offers - aka configure it to users liking (as there some really important ones - settings for UE etc)

List of available options for Ornatrix Alembic here

Speaking of the AYON Load of oxCache product we should provide multiple Action aka loaders for this product within Ayon Loader:

Load Ornatrix Alembic Load as Vray Proxy - should work perfectly (by far best integration imho) Load as Arnold Standin - been tested and renders well Reference (Abc) as I have did some testing its not good idea to use classic Reference (Abc) or maya native File > Import Alembic - as it was unusable aka completely frozen maya for performance reasons?! we could test it more tho...

[iLLiCiTiT]

Please move PR to https://github.com/ynput/ayon-maya