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

AlembicFileFormat targets UV data to non-standard primvars attribute #185

Open
nrusch opened this issue Mar 24, 2017 · 7 comments
Open

AlembicFileFormat targets UV data to non-standard primvars attribute #185

nrusch opened this issue Mar 24, 2017 · 7 comments

Comments

@nrusch
Copy link
Contributor

nrusch commented Mar 24, 2017

Description of Issue

When reading Alembic files, the UsdAbcAlembicFileFormat currently applies incoming UV data to the primvars:uv attribute on the created prim, which diverges from USD's convention(?) of storing UVs in primvars:st.

One of the immediate side-effects of this behavior is that, if the resulting prim is then read into Katana, the UV data ends up in the geometry.arbitrary.uv attribute instead of geometry.arbitrary.st, and since KtoA (in its current form) is looking for the latter but not the former, subsequent renders will fail.

An argument could certainly be made that KtoA should be able to use UVs data from geometry.arbitrary.uv as an alternative, but I still think things should be consistent on the USD side as much as possible.

This may be as simple as updating the target attribute name here.

@iceprincefounder
Copy link

Yeah,I got a same problem,and I found that the usd files have the attribute geometry.arbitrary.st but abc files didnt have,If you rename geometry.arbitrary.uvtogeometry.arbitrary.st` in katana,you can get uv information!This attribute should be renamed I think.

@jtran56
Copy link

jtran56 commented Mar 27, 2017

Filed as internal issue #144611.

@NickWu
Copy link

NickWu commented Jul 9, 2018

I was wondering whether this issue is fixed in USD?

@ainaerco
Copy link
Contributor

ainaerco commented Nov 20, 2018

Any update on that? Is it safe to modify USD_ABC_POINTBASED_NAMES as nrusch suggested?

@ababak
Copy link

ababak commented Dec 11, 2019

Any news on this issue?

@spiffmon
Copy link
Member

This is not an issue that we plan to address at Pixar, but we are happy to accept a PR that ensures the unit tests continue to pass.

As to the approach suggested by @nrusch , I would say that unconditionally changing the token value itself might be problematic for some studios... ILM are heavy Alembic/USD users, adding @juliencb2018 for comment. The alternative, slightly more involved approach would be to add a TfEnvSetting that guards the behavior so that each site can configure the behavior - or if you really needed a more literal translation of the abc file, you could disable to uv -> st translation. But we’d leave that decision to the community.

@juliencb2018
Copy link
Contributor

Thanks for the addition and sorry for the delay in replying.
We (ILM) are currently using an OpScript in Katana, and a PxrManifold2D node for our prman preview shaders. I think our plan was to keep it this way, until we fully move to a usd solution for geometry caching. I expect other studios still using Alembic for their leaf level geom caching did implement similar things and would be affected if the uv attribute was simply renamed to st.
Happy to discuss more!

AdamFelt pushed a commit to autodesk-forks/USD that referenced this issue Apr 16, 2024
…/feature/pipeline_adsk

Support build from PR and Ptex
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

8 participants