Texture Publishing and Loading

[mottosso]

Goal

Validate and automatically store textures from software used to create it.

Discussion

What software does this include? Photoshop, Mudbox, Mari? If it is an option to make one of these the central place from which to publish textures, then we could make concentrate the implementation effort around a single mechanism. For example, everyone could work in Photoshop, but would ultimately publish through Mari, or vice versa.

Motivation

If textures are published as other assets can they be loaded as such an therefore tracked consistently?

Loaded textures could take the form of file nodes with pre-set paths. Shot building could then build these paths given the pre-defined root template variable. Solving the problem of texture paths on a network.

It would also enable a texture library alongside a potentially shader library.

[mkolar]

Another consideration is the complexity that texture publishing very quickly reaches.

Say we have a character with 10 different body parts, each needing it's own texture set and each texture set contains diffuse, spec, roughness, displacement and opacity (could be way more than that) quickly we are talking 50 files to shade the character (if we don't consider UDIMS). Now how do we version these?

Version per:

• asset?
• texture set (body part)?
• texture?

very often we only need to update one particular texture (specular on head), so it sounds like versioning per texture might make the most sense, however the amount of subsets will become humongous. Not to mention we often have variants of texture that need to be tracked like main, bloody, burned etc. my head always spins just thinkinig about the amount of files and their organisation.

[mkolar]

What software does this include? Photoshop, Mudbox, Mari? If it is an option to make one of these the central place from which to publish textures, then we could make concentrate the implementation effort around a single mechanism.

That could be difficult to pin down. Ideally though, it would be a 3d software where artist can see them applied (plus thinking of publishing a full character of textures from photoshop makes me a bit sick :) ). Mari is a good fit, but far from being a standard among smaller studios, Mudbox is dying but many still use it. Substance is getting a lot of love lately too. All of them suitable, but none as much of a standard as maya is for example.

What I'm trying to get to is that in my opinion Maya is actually the best option for texture publishing. Already implemented, easy to track file nodes and their connections to shaders. Makes sure artist sees textures in context.

That being said, for many people texturing and lookev are one and the same task and could therefore be published at the same time. If we ever solve the chicken and egg problem of needing to know the final texture path before it's published (to use it in shader), but don't know it until it's published...

[mottosso]

What I'm trying to get to is that in my opinion Maya is actually the best option for texture publishing. Already implemented, easy to track file nodes and their connections to shaders. Makes sure artist sees textures in context.

Makes sense to me. The only thing I've noticed that could be a problem is when the artist expects both textures and assets with textures applied to be published from within the same working file. (Looking at you @BigRoy).

When Maya is used merely as a "viewer" and publisher of textures, I think what you're saying makes a lot of sense, and would simplify implementation as we'd bypass Photoshop and all of it's kinks and utilise what we've already got with Maya. Win-win.

That being said, for many people texturing and lookev are one and the same task and could therefore be published at the same time.

The motivation @BigRoy gave me (welcome to correct me) as to why textures and lookdev couldn't be separated as I described above was that artists typically publish textures in tandem with lookdev, and that it happens so often that the act of jumping between the two becomes at bottleneck.

My answer and stance on that was that we'd work on facilitating the jump, be it via GUIs or commands of sorts. Anything that would make the jump less of a bottleneck, so that we could keep the conceptual purity of independent publishing of textures and lookdev and facilitate more complex and interesting things on-top of that solid foundation.

[BigRoy]

for many people texturing and lookev are one and the same task and could therefore be published at the same time.

Yes, this is the tricky bit in our situation here. Our artists that do the look development most of the time also produce the textures, it's even the same "task": lookdev doesn't separate in a shader task and a texture task.

The textures initially get adapted so frequently by the lookdev artist that it's convoluted (and slow) to continuously publish the textures each time they just want tot test their lookdev shaders. This testing is before even the shader/textures are up to a usable point. (For example, if you'd just want to quickly test a texture on a wall.) With the scenario where the only way to apply a texture is to load it as a published file, always!, this means any image would have to be published even before it could be tested/used by the lookdev artist. Also producing many "meaningless" publishes.

Currently our textures are just versioned with the full lookdev and I'd love it to be much smarter (versioned per texture) but I haven't been able to figure out a production workflow where it doesn't introduce more stress for the artists.

Unfortunately I haven't been able to find a workflow that could work well enough for our needs, so we are still stuck with publishing the full "lookdev" as one blob (with all its textures).

[BigRoy]

To clarify some more, the biggest cons were:

1. The transfer time for each texture just to test the file.
2. Having many published texture versions that even to the original artist who was creating them are considered useless. If they just wanted to quickly test a huge number of different textures.

Number 1. introduced the biggest hurdle for just "doing this quickly inbetween" at some point because of the transfer time for the textures. Using hardlinking (or is it symlinking?) this would be instant, plus also reduce sizes on the server. I believe this then would become a non-issue.

Number 2, this is something that just belongs to the nature of the task. It's like sliding the color value ever so slightly to test the differences. This is also precisely the thing you want to interupt as little as possible.