Publishing Textures and packaging Texture Sets

Discussion / Issue

When publishing a set of textures there can easily be multiple sequences of textures for a single material - and an export from Substance could even export multiple materials.


As an example, a Texture Set from Substance Painter could be:

  • Possibly multiple Materials
  • Possibly multiple textures per material
  • Possibly UDIM tiles

Would that be a single “TexturePackage” subset?
Would that be a “TextureSet” subset per material?
Would that be a “Texture” subset per texture type? (So just the Defaultmaterial_Base_color is one subset, then DefaultMaterial_Height is another)

  • What do we expect to be in the loader?
  • What do we expect to see in the manager?
  • How do we expect site sync to decide what textures to transfer?

My first thoughts

Texture subset per channel

We’ll publish Textures individually per sequence, that is e.g. base_Roughness.<udim>.exr - so with e.g. Substance’s default Redshift template for a material:

// template

We’d get subsets:

// subsets

These are then all their own subsets that can have their own color spaces, etc.
As such - a texture subset would refer to a single ‘channel’ for the material (but does allow a sequence like a UDIM sequence)

Additionally we allow subsets to be ‘subscribed’ or ‘connected’ to another subset. A package like a Texture Set then is a Subset its own which can have its own family, versions and representations. The Loader could then visually group the texture subsets by default under this subset (similar to Grouping).

Something like:

subset["data"]["children"] = ["version-id-1", "version-id-2", "version-id-3"]

This TextureSet subset could then also contain additional files, like a special family + json if it came from e.g. Substance Painter with a parameters JSON file to allow special loaders to load the package into e.g. Maya including the shader parameters or alike.


Additional notes

I think it’s worthwhile to spend some time also simplifying how to manage files for publishing. In particular the Extractors, I’d like to propose explicit functions like e.g.

add_files(instance, files)
add_udim(instance, files)
add_sequence(instance, files)

Instead of the messy quirkiness of deadling with["representations"] and its files in each Extractor which tends to grow complex per Extractor with a lot of duplicated code doing the same thing over and over - leaving a lot of code management over time when we want to change behavior. By exposing that to a function like this we can internally tweak that data structure easier.

These could then each have explicit arguments for color space, frame range, original frame ranges, etc.:

def add_files(instance, files, source_frames, destination_template):

Related issues

Potentially related discussions:

We’ve hit this multiple times, not only one textures but camera data too - like output from tracking software (script file), proxy geometry, camera itself in fbx, camera metadata, lens distortion etc. It is basically grouping of multiple subsets to behave as one interconnected version and with ability for loaders to work with it.

Back to the textures: there was a Miro board where we’ve brainstormed concept of “Package” or “Bundle” that would be related to this, I’ll try to find it and post it here. Texture packages are especially important in Unreal workflow, where you not only need to have them but also they must be supported in combination with Hero version which is challenge on its own. It should be also noted that those usually follow unofficial naming convention - just mentioning it because of the need to consider it in templates.

I agree that if this is coded in a transparent way - that we can just interpret the channels back (which should be easy with proper data structure) but I dont personaly like unreal naming conventions, and outside gaming niche I have rarely seen such exotic sufixes and prefixes. If this is named as so, I can already see supes and artists requesting this to be changed.

The way Substance works and exports and its naming its already more “natural” way to name those files.

I see unreal as a Consumer of a representation which has its own way of dealing with things. I would avoid it dictating rules.
Dont judge me. :lollipop:

yeah, of course - I haven’t meant it as “default” just that it needs to be taken into consideration. That it must be able to support files like this.