So texture sets, how do we deal with those?
The thing is from substance painter we get the option to publish a texture set witch is working pretty fine.
We do buy, download a lot of assets or to start with or sometimes they are good enough to use for the background.
Preferred a producer/assistant can just publish the model and the textures themself so artist can pick it up again, but how do we publish texture sets from the publisher.
I swear i’ve seen it coming by in previous discussions, but can’t find/recall where and what the solution was to this problem.
Proffered it sees that if it has base, diffuse, etc in the name its a BaseColor and the same for roughness etc etc.
For now i just let them publish it through substance, but it’s a little time consuming and cumbersome
Using Tray Publisher, Its planned to add its docs. will add it here as soon as they are added.
About Tray Publisher:
Currently, Tray Publisher can’t publish multiple files as a single representation - It can publish single file or sequence.
This is essentially preventing publishing of texture packs/sets.
It’s considered to support publishing multiple files as a single representation.
So, you should create an instance for each channel.
Publishing textures along with Maya Scene.
There is no support at the moment for publishing textures along with Maya Scene.
So, Artists publish before bringing into Maya.
Indeed we now publish the textures trough Substance Painter and that goed really well.
It’s just a bit cumbersome for an artist to use the publisher as standalone now.
But on the other hand, we’ve some extra option to pack roughness and other types to one exr for unreal to keep it more efficient.
When i try to publish a hero version with a custom template it only copy’s the latest in the naming convention, in most cases the normal map.
This is probably due that i want the textures in the same folder, but the resolver can’t handle that.
Which is sort of weird as this only applies to the hero version and not the versioned normal version
So this doesn’t work as a directory template for a Hero version {root[work]}/{project[name]}/{hierarchy}/{folder[name]}/publish/{product[type]}/hero/
But this does {root[work]}/{project[name]}/{hierarchy}/{folder[name]}/publish/{product[type]}/hero/{product[name]}
This is the directory template for the non-hero version {root[work]}/{project[name]}/{hierarchy}/{folder[name]}/publish/{product[type]}/{@version}/
@robert there is also another solution…using Photoshop and Ayon for that
As you have option to output each distinct PS layer as a separate “Image” product.
So preparing your file in a way, that each layer containing separate map (albedo, roughness etc) you can pretty much just hit Publish (with proper settings on the Image publish instance, you can also get Layer naming as a Variant)
And last but not least, you could also use Tray Publisher for PSD by color coded layers (must be set in the PS addon settings on Ayon)…
We also want to publish files that were purchased or provided by our clients.
So the ideal solution would be to use the Tray Publisher, as it can be used by non-artist people (producers) that received the files.
I don’t know if there is the same problem for textures, but currently you can’t do that for 3d assets (fbx and blend files for example), because then you cannot use Ayon’s Load interface to import an asset inside a DCC software, if that asset was published by the Tray Publisher, so the Tray Publisher is useless for this usecase.
There is an open issue for OpenPype, but I don’t know where it was converted to an Ayon issue (as the issue was not resolved).
.
(at least I hope that OpenPype issues are converted to Ayon issues (if not resolved), because otherwise a lot of valuable bug reports would get lost)
Here is a small hint when speaking of Photoshop and possible solution / workaround for ingesting textures sets…
It makes sense to tweak the PS addon settings for “Creators” like this (adding new variant which gets into the naming of published “Image” products (just nice touch)
Also possibly disabling “Create Flatten Image” could be preffered as we will be interested just in layers aka “Texture” variants resulting into each PS layer having product like “Image_Texture_[your_layer_name]” possibly resulting into following scenario:
Note the PS layers and its naming got propagated into Variants (need to be ON when creating publish instance in very first step of publishing images) like this:
Also note, your representations depends on the PS addon settings in Ayon (mine also contains PSD file format…which is not implict and probably unnecessary atm)
As I have mentioned in other community posts in the past, the Tray Publisher was too cumbersome and requires too much manual intervention for us to use for batch publishing of products so I ended up creating a Batch Publisher tool that from a file path tries to guess all the products that you’d want to publish with its type and folder destination and so on and then submits the publish to the farm. Expanding on that toolset, I created a separate Texture Publisher standalone tool that works the same way but only discovers texture type files and tries to infer its input colorspace so we can use this publish plugin we created that converts the input textures to .tx files in AcesCG so we can use them in Arnold without artists having to know much about color transforms (and help them use efficient textures when rendering):
And once published you can see that we also create subset/product groups of the textures by using the last token delimiter _ as the different subset/products:
Note also that we are using product type textures to publish these instead of image as there’s already some hosts that use that type. I think there’s quite a bit of a mix up of product types across hosts and we should do an effort on doing a global clean up on the different types that are supported and stay consistent
The idea would be to then use this same framework to provide frontends for the different DCCs so the discovery doesn’t happen through filepath but texture nodes in the scene… and after those get published, the texture nodes get replaced automatically by the ingested textures.
it is part of my forks of OP and AYON but there’s a significant amount of customizations and “shortcuts” that would require me to do a lot of work to pass the standards of Ynput’s to merge it on their repo and I don’t have the time or resources to do it. But here they are if you want to try integrate it in your own flavors of OP/AYON:
