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

Autodesk: Fix issue where ResolveParameter doesn't support type conversion #2519

Conversation

erikaharrison-adsk
Copy link
Contributor

Description of Change(s)

When resolving the parameter for wrapSampler, minSampler, and magSampler, if the value got is not a token, we try to get the value as a string, and construct the token from the string.

Related: Prior approach/discussion in #2473

Fixes Issue(s)

  • N/A
  • I have verified that all unit tests pass with the proposed changes
  • I have submitted a signed Contributor License Agreement

@erikaharrison-adsk erikaharrison-adsk changed the title Fix issue where ResolveParameter doesn't support type conversion Autodesk: Fix issue where ResolveParameter doesn't support type conversion Jun 30, 2023
@jesschimein
Copy link
Contributor

Filed as internal issue #USD-8475

@tcauchois
Copy link
Contributor

Hi Erika,

Given the discussion on #2473, it seemed like we decided to drop this PR? Note that all of the sampler parameters are in the schema and Sdr as tokens, so accepting strings here would be deviating from the USD spec. Is there a reason you can't write these as tokens in the assets? If these are strings in the assets, I'd expect them to fail usd validation; though I don't know if we have coverage for this yet in fixbrokenschemas.

Let me know if I'm missing something! Thanks,
Tom

@PierreWang
Copy link
Contributor

Hi Erika,

Given the discussion on #2473, it seemed like we decided to drop this PR? Note that all of the sampler parameters are in the schema and Sdr as tokens, so accepting strings here would be deviating from the USD spec. Is there a reason you can't write these as tokens in the assets? If these are strings in the assets, I'd expect them to fail usd validation; though I don't know if we have coverage for this yet in fixbrokenschemas.

Let me know if I'm missing something! Thanks, Tom

The problem is that with the current implementation, _ResolveParameter in material.cpp will not correctly resolve the token parameter. For example, the below code will always return empty sampler.
" TfToken wrapSampler = _ResolveParameter(
node, sdrNode, name, TfToken());"

I have tested the simpleShading sample in extras\usd\tutorials. The wrapS, wrapT, and wrapR sampler will all be empty after _ResolveParameter. Maybe I don't get the root cause of the problem, but resolve the parameter as a string will resolve the issue.

@jesschimein
Copy link
Contributor

/AzurePipelines run

Copy link

Pull request contains merge conflicts.

@tcauchois
Copy link
Contributor

Pierre: the script you linked never sets the sampler attributes. Have you modified the script at all? And what are you getting vs expecting from _ResolveParameter, exactly?

Thanks!

@PierreWang
Copy link
Contributor

PierreWang commented Mar 19, 2024

Pierre: the script you linked never sets the sampler attributes. Have you modified the script at all? And what are you getting vs expecting from _ResolveParameter, exactly?

Thanks!

Sorry. It seems that the problem is "_ResolveParameter" will not return correct default value for a token property. For example, for the UsdUVTexture shader, there are default values for "wrapS" and "wrapT", which are saved in shaderDefs.usda. But current implementation can not read it:
// Then fallback to SdrNode. if (sdrNode) { if (const SdrShaderPropertyConstPtr input = sdrNode->GetShaderInput(name)) { const VtValue& value = input->GetDefaultValue(); if (value.IsHolding<T>()) { return value.UncheckedGet<T>(); } } }
Here the value will not hold a token. So it will not go to the line "return value.UncheckedGet();".

You can have a try with the simpleShading sample under extras\usd\tutorials. If you set a breakpoint at _ResolveParameter, you will find that it will not correctly get the default value. But if you call _ResolveParameter with the “string" parameter type, the default value can be correctly fetched.

@jesschimein
Copy link
Contributor

/AzurePipelines run

Copy link

Pull request contains merge conflicts.

@spiffmon
Copy link
Member

Ah! THank you for bearing with us, @PierreWang ! I think that means the correct fix is to change the call to GetDefault() to GetDefaultValueAsSdfType()

@tcauchois
Copy link
Contributor

tcauchois commented Mar 20, 2024

Ok @spiffmon so your recommendation is here:
https://github.com/PixarAnimationStudios/OpenUSD/pull/2519/files#diff-ba83f6b9afea735ef4351df227d7424447be68b0ddc0201a591f1a7c83ef265fR560
... we change "GetDefaultValue" to "GetDefaultValueAsSdfType"?

@PierreWang, can you try that and let us know if it fixes your issue? It should make the rest of this PR unnecessary. If that works, please update the PR and we'll pull it in. Thanks!

@PierreWang
Copy link
Contributor

Ok @spiffmon so your recommendation is here: https://github.com/PixarAnimationStudios/OpenUSD/pull/2519/files#diff-ba83f6b9afea735ef4351df227d7424447be68b0ddc0201a591f1a7c83ef265fR560 ... we change "GetDefaultValue" to "GetDefaultValueAsSdfType"?

@PierreWang, can you try that and let us know if it fixes your issue? It should make the rest of this PR unnecessary. If that works, please update the PR and we'll pull it in. Thanks!

Great, this will resolve the problem. I will update this branch and use "GetDefaultValueAsSdfType" fix instead what I do now.

@jesschimein
Copy link
Contributor

/AzurePipelines run

@erikaharrison-adsk
Copy link
Contributor Author

PR updated with suggested change.

@jesschimein
Copy link
Contributor

/AzurePipelines run

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@pixar-oss pixar-oss merged commit 4cb0cb1 into PixarAnimationStudios:dev Apr 20, 2024
5 checks passed
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

Successfully merging this pull request may close these issues.

7 participants