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

USD: Validate all contributions are within the default prim #91

Open
2 tasks done
BigRoy opened this issue Sep 5, 2024 · 0 comments
Open
2 tasks done

USD: Validate all contributions are within the default prim #91

BigRoy opened this issue Sep 5, 2024 · 0 comments
Assignees
Labels
type: enhancement Improvement of existing functionality or minor addition

Comments

@BigRoy
Copy link
Contributor

BigRoy commented Sep 5, 2024

Is there an existing issue for this?

  • I have searched the existing issues.

Please describe the feature you have in mind and explain what the current shortcomings are?

There is currently a validator that will report whether some of your written opinions in the USD file are outside the default primitive.

If ALL are outside, a validator already invalidates for publishing. However, when creating for example a look then generating materials by default will make them in a global /materials but should be in /{folder_name}/materials however material assignments will be to the actual meshes in the correct hierarchy. As such, your look HAS opinions within the default primitive /{folder_name} however has the materials accidentally outside of it.

Reports show that artists miss (or ignore?) the warnings on publishing regarding the prims being outside and just assume that because it came through that the publish will be fine. However, on load there are no materials leaving artists (who just started with USD) confused about this behavior.

How would you imagine the implementation of the feature?

It should be easy for artists to be aware of such a case that is most likely wrong. My proposal is to add an optional validator that by default ONLY allows contributions inside the hierarchy of the default prim, as it should be - and invalidate anything outside of it.

By making it optional we can still allow bypassing or allow workflows that we may not envision yet (e.g. writing multiple hierarchies, some even outside the default prim).

Are there any labels you wish to add?

  • I have added the relevant labels to the enhancement request.

Describe alternatives you've considered:

Better documentation and decent templates - but this is hard, and people will still often start without those? 🤷

Additional context:

No response

@BigRoy BigRoy added the type: enhancement Improvement of existing functionality or minor addition label Sep 5, 2024
@BigRoy BigRoy self-assigned this Sep 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement Improvement of existing functionality or minor addition
Projects
None yet
Development

No branches or pull requests

1 participant