-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Comments
Yeah,I got a same problem,and I found that the usd files have the attribute |
Filed as internal issue #144611. |
I was wondering whether this issue is fixed in USD? |
Any update on that? Is it safe to modify USD_ABC_POINTBASED_NAMES as nrusch suggested? |
Any news on this issue? |
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. |
Thanks for the addition and sorry for the delay in replying. |
…/feature/pipeline_adsk Support build from PR and Ptex
Description of Issue
When reading Alembic files, the
UsdAbcAlembicFileFormat
currently applies incoming UV data to theprimvars:uv
attribute on the created prim, which diverges from USD's convention(?) of storing UVs inprimvars: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 ofgeometry.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.
The text was updated successfully, but these errors were encountered: