File Resolver and UDIM

[qvisten]

Hi,

I've started developing a custom file resolver and have a working prototype. Most functionality behaves as expected, but I've run into an issue with UDIM textures—they stop working when routed through the resolver.

My question is: what should the resolver return to ensure UDIMs continue to function correctly in Maya? What does Maya expect from a file resolver in this context?

I've tried several approaches to get it working, but so far, nothing has succeeded. Any insights would be appreciated.

I attached my prototype resolver.

[brentmc]

Hi,

Not my area of expertise but if you are passed a path with a UDIM tag in it what happens if you resolve the path but leave the tag in?

In other words you resolve the directory portion of the URI but leave everything else.

Note that Maya ships with a Python package - maya.app.general.fileTexturePathResolver which seems to be used for resolving UDIM paths to actual texture files. (which is why I am wondering if you tried leaving the UDIM tags in the resolved path)

[victorcm7]

Hi! I'm running into the same issue, and leaving the <UDIM> tag in the path doesn't work either.

For example, if I directly return "C:/Users/vcandela/Desktop/test_texture.<UDIM>.png" at the resolveURI method the file node does not find the udim textures.

However if I run that through maya.app.general.fileTexturePathResolver.findAllFilesForPattern("C:/Users/vcandela/Desktop/test_texture.<UDIM>.png", 0)  as @brentmc suggested it does indeed return the list of udim textures.

Expanding on that, using maya.app.general.fileTexturePathResolver.getFilePatternString(C:/Users/vcandela/Desktop/test_texture.1001.png', useFrameExtension=False, uvTilingMode=3) does return the path with the <UDIM> flag.

Also, setting the path directly instead of using the resolver scheme, with UDIM does indeed work as expected

So I'm gessing that check runs before the resolving?

[victorcm7]

Well I went down the rabbit hole trying to make this work and I don't think it can be done with the current implementation, seems like the MPxFileResolver class is pretty old and hasn't been updated with the UDIM implementation.

I'm going to leave a summary of what I think that is happening, let's hope someone at Autodesk corrects me if I'm wrong:

Case: A file node where we are setting a URI path that we want to resolve via FileResolver with the file node uvTilingMode set to UDIM (Mari)

- First, the File Resolver get's called, and the resolveURI method receives the path, and the mode. This is important because the file node is a Input node, so the method will receive kInput as mode, and will check the return for existance, and here comes the issue.

- If you return a path with the <UDIM> token, the file node will raise an error since that path indeed does not exist, and the resolver will return an empty string because if flags the result as kFailure.

- If on the other hand you return the first found UDIM, e.g. 1001, the resolving will be succesfull BUT, a callback either from the file node or the AETemplate (not sure which one) will attempt to override the path with the <UDIM> token according to maya.app.general.fileTexturePathResolver. However, instead of doing this with the resolved filepath, it seems like it's doing it with the URI path, which does not work either.

One funny thing I found with this is that if you create another file node, and set the resolved path, the texture you had with the UDIM will suddenly find the udim textures, but it will also replace the path in the attribute to the resolved one instead of keeping the URI.

@qvisten The workaround I've found that seems to be working and I think we will be using, is creating a custom node just for the resolver and connecting the output to the fileTextureName attribute in the file node. If you pass the path with <UDIM> it does work as expected. 

[brentmc]

I've asked internally whether anyone can confirm if this is a bug.

Thanks.

[victorcm7]

Hi @brentmc! Did you get any answer back? I'd love to implement this even if it's with a workaround

[brentmc]

Sorry, I haven't yet heard anything back.

I've pinged one of our QAs who was going to try and reproduce the issue. 

[sathya.rajan]

Hi,

I have logged this internally as MAYA-138447 and am currently awaiting feedback from the team. I will report back with a workaround or a possible solution as soon as I have more information on this.

Thank you,

Sathya Rajan.

[victorcm7]

Hi @sathya.rajan! Any news about this? Thanks in advance!

[sathya.rajan]

Hi @victorcm7 

I don't have any updates on this yet, but I will check on it and get back to you as soon as I have more information. Thank you for your patience.

[victorcm7]

Hi @sathya.rajan , I was stopping by to find out if this topic is still being looked at or if it's been shelved, since there's been no news for three months now.

[brentmc]

Hi,

Unfortunately, it doesn't look like there has been any activity or comments on this issue since it was opened.