[Maya] - Publish selection or defined layer

[vNicolini]

Is your feature request related to a problem? Please describe.
Unable to export selection only or defined layer.
It is needed to be able to separately export subd and low poly caches.
High poly/subd being destined for texturing whilst the low poly/non-subd is being passed on to the other departments. Subd should "only" occurs at rendertime whenever possible to maximize memory efficiency, interactivity and storage.

Describe the solution you'd like
Being able to publish selected shapes or layer.

Describe alternatives you've considered
What Prism Pipeline do offer is that you can create selection sets that then are passed to the exporter, allowing you to have both the low and high poly in the same file and being exported separately if wanted/needed.

Cheers,
VNI

[masqu3rad3]

I believe this should be part of the USD asset/shot workflow.
The method that you described and what Prism is using can be achieved easily with a custom extractor. However I honestly think that would only be a poor LOD implementation.
The better way to do that is to author a proper USD. This way the LODs can be in deferred state until they requested with the logic.

Selection only export can be done as a custom method but I am a little bit against that idea because of the repeatability.

I believe until there is a solid workflow, the better way would be to keep them in separate work stalks (or maybe tasks)

[vNicolini]

I'm not using USD, i tend to stay far away from it actually.
For a personal use it's plainly overkill/overcomplicated imo. I prefer to stick to the good old Alembic workflow in most instances.

If i get it right, what you suggest is to have a completely separated workfile (and task) to export/publish subd/high-poly caches ?

[masqu3rad3]

To be fair, I am staying away from USD as well for my personal stuff. I am essentially a rigger and rigging land is where the USD implementation is weakest. I am sure there are very good examples of using it but I didn't see any so far.

If i get it right, what you suggest is to have a completely separated workfile (and task) to export/publish subd/high-poly caches ?
This depends on your workflow and how you intend to switch between two meshes.

One way would be making a custom extractor (and ingestors for other DCCs)
It can look for a specific group name, a custom attribute or selection sets as you suggested. The rule can be defined with a custom metadata too.
Essentially collect lower density meshes - export and do the same for the higher density. All in same extractor. But again this will be something very specific and probably different for everyone.

Other way would be simply making a separate work file branch for each LOD. I can understand that is not ideal especially if you are doing something procedural. There will probably be an unnecessary branching. But if you are for example producing the lower density one from the higher density it might be not that bad.

I think the actual problem, which applies for any of these workflows (also includes the 'exporting selection only' approach) ingesting them and switching between. If you ingest both of them at the same time, it won't make sense as it won't optimize anything at all. And I guess switching them manually may be a potentiall pain in the back.

[vNicolini]

This depends on your workflow and how you intend to switch between two meshes.

In my workflow (and what i've dealt with in shows too to my knowledge) the high-poly/subd mesh is "only" ever used for texturing (and maybe CFX?).
For layout, FX, lookdev and lighting/rendering the low-poly is loaded in and the subdivision is handled by the renderer at rendertime.
Which allows to keep the interactivity fairly high whilst maintaining a fairly low memory and I/O footprint when working.

[masqu3rad3]

ah okay, subdivision is something different than what I am talking about is actually.
I was referring to a bit more complex proxy approach. In my example, always the high resolution mesh gets rendered or extracted but regardles of the step the user can visualize the lower density mesh for better interactivity.

[vNicolini]

Oh yeah i see what you mean by the proxy approach!
Well ... a proxy in this instance would add a third geometry level which would "only" make sense on "very" complex low-poly/un-subd meshes...

In USD you'd have a very low poly mesh primitive with a "proxy" purpose and the "high poly" un-subD mesh primitive with the "rendering" purpose, on which subdivision at rendertime would still occur.

Hopefully that makes sense :D

[masqu3rad3]

yes, that was what I was referring for. In rigging, we have also another level.. A separate 'lower' rig which has less poly count and often stripped functionility for higher frame rates.
All these combined, it can quickly get out of control