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

Spec version metadata #83

Open
anderslanglands opened this issue Aug 22, 2023 · 5 comments
Open

Spec version metadata #83

anderslanglands opened this issue Aug 22, 2023 · 5 comments
Assignees

Comments

@anderslanglands
Copy link

anderslanglands commented Aug 22, 2023

In section 2.5, the spec lists a series of metadata to help compatibility. Ought the spec version be part of this? Or is there some other way to inspect which version of the spec a particular instance of an OpenPBR shader is?

In addition, from reading it's not clear what the different metadata being mentioned are, or where they are applied? Would be great to specify all this explicitly.

@portsmouth
Copy link
Contributor

portsmouth commented Aug 27, 2023

I think it would make sense for the metadata to include the version.

The section about metadata is a bit tentative. It doesn't seem appropriate to make such metadata (e.g. the assumed color space of the parameters) part of the material model itself, as it would require introducing string or enum parameters into the model.

The assumption seemed to be that way the shader parameters are packaged/contained for exchange is outside of the scope of the spec, and so perhaps it suffices to verbally/loosely describe the extra metadata/information needed that should be packaged with the parameters. I assume this has been done to some extent for the Standard Surface model.

For example how the N/T/B of the shading frame are actually defined (e.g. a normal map and all its parameters in some specific convention we don't dictate), can presumably be made reasonably unambiguous, but it's beyond the scope of the current spec to do that apart from pointing out that the asset management should set up the metadata to make it unambiguous.

Perhaps though we need to try to be more specific and actually have named pieces of metadata, with specified datatypes etc. I'm not sure.

@anderslanglands
Copy link
Author

anderslanglands commented Aug 27, 2023 via email

@anderslanglands
Copy link
Author

anderslanglands commented Aug 27, 2023 via email

@portsmouth
Copy link
Contributor

See #74 (comment) for my take on the normal map specification issue.

@AdrienHerubel AdrienHerubel self-assigned this Sep 14, 2023
@portsmouth
Copy link
Contributor

We did add "The version of the specification implemented" to the suggested metadata.

The normal map conventions would be quite involved to properly specify (I think). So it would be for a later release, if we do it at all (it could be that this is outside of the scope of the spec permanently though).

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

3 participants