Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UsdUtils.ExtractExternalReferences converts <udim> to 1001 in 23.11 #3173

Open
p0las opened this issue Jul 18, 2024 · 5 comments
Open

UsdUtils.ExtractExternalReferences converts <udim> to 1001 in 23.11 #3173

p0las opened this issue Jul 18, 2024 · 5 comments

Comments

@p0las
Copy link

p0las commented Jul 18, 2024

Description of Issue

The paths returned by UsdUtils.ExtractExternalReferences no longer contain <udim> tag in 23.11

23.02 → gorilla-tex_lookDev_texture_v0001_base_colour.<UDIM>.exr
23.11 → gorilla-tex_lookDev_texture_v0001_base_colour.1001.exr

Steps to Reproduce

given the simple USD file as below:

#usda 1.0
(
    upAxis = "Y"
)

def Scope "mtl"
{
    def Material "material"
    {
        token outputs:surface.connect = </mtl/material/PBRShader.outputs:surface>

        def Shader "PBRShader"
        {
            uniform token info:id = "arnold:standard_surface"
            color3f inputs:base_color.connect = </mtl/material/diffuseTexture.outputs:rgb>
            token outputs:surface
        }

        def Shader "diffuseTexture"
        {
            uniform token info:id = "arnold:image"
            asset inputs:filename = @C:/CODE/pyCharm/pipeline/fin_unittest/TEST_PROJECT_0/_Temp/Creatures/gorilla-tex/lookDev/texture/texture/0001/gorilla-tex_lookDev_texture_v0001_base_colour.<UDIM>.exr@
            color3f outputs:rgb
        }
    }
}

execute UsdUtils.ExtractExternalReferences for it.
in the 23.11 the path returned doesn't match what is stored in the file and is returned as 1001 udim. In the previous versions, the <udim> tag was preserved by the utility.

System Information (OS, Hardware)

windows 10,
USD 23.11

Package Versions

Build Flags

@jesschimein
Copy link
Contributor

Filed as internal issue #USD-9867

@p0las
Copy link
Author

p0las commented Sep 9, 2024

Hi,
it seems that this problem is much worse in 24.05 where udims get expanded into individual frames hitting our servers pretty hard.
here are two runs on one of our production USD files in tow versions of USD (houdini 20.0 vs 20.5)

usd version: (0, 22, 8)
number of paths: 42
INFO:fin.core.debug:TIMEIT. func:'resolve' in '__main__' took: 0.0500 sec
usd version: (0, 24, 5)
number of paths: 332
INFO:fin.core.debug:TIMEIT. func:'resolve' in '__main__' took: 27.0686 sec

this is just a single isolated call. when the render farm hits the servers with this call our pipeline simply stops as the servers cannot cope with the number of file queries.

is there any way to disable it? an environment variable to get to the old functionality? I think udim resolution should be up to the client code to resolve if needed.

@matthewcpp
Copy link
Contributor

Hi @p0las I just wanted to let you know we have a fix for this issue. It should be included in the 25.02 release.

@BigRoy
Copy link

BigRoy commented Oct 29, 2024

@matthewcpp could you describe the 'fixed' behavior? :) Just to be sure what the intended behavior would be.

@matthewcpp
Copy link
Contributor

matthewcpp commented Oct 30, 2024

The fix restores the previous behavior of UsdUtils.ExtractExternalReferences to not resolve UDIM paths in the default case. There will now be an optional parameter which controls whether udim resolution should be performed as part of this operation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants