Spec version metadata about openpbr HOT 5 OPEN

On Mon, 28 Aug 2023 at 06:05, Jamie Portsmouth ***@***.***> wrote: 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 of the material model), 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 describe the information needed that should be packaged with the parameters. 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. — Reply to this email directly, view it on GitHub <#83 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOYQXMDF6XZBRRNMCBOLVTXXOD7PANCNFSM6AAAAAA3ZESZHQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

I’m in two minds over whether you even want to specify the colour space on the material itself for anything other than texture parameters. You’re assuming that the material description will always be transmitted in MtlX and/or UsdShade right? I’m not too familiar with how MtlX handles this: does it just provide colour space information as a hint or will it also do the conversion to your desired rendering space for you? USD is supposed to do that for you in some future version using Hydra 2.0, at which point colour space metadata on material parameters is redundant at best, and a point of conflict/failure at worst. I feel pretty strongly that normal map conventions need to be specified. The OGL/DX thing for normal maps is a constant issue in real assets and not providing an explicit means to specify it (eg a “flip green” parameter) will just lead to stuff breaking. On Mon, 28 Aug 2023 at 06:05, Jamie Portsmouth ***@***.***> wrote: > 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 of the material model), 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 describe the information needed that should > be packaged with the parameters. > > 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. > > — > Reply to this email directly, view it on GitHub > <#83 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAOYQXMDF6XZBRRNMCBOLVTXXOD7PANCNFSM6AAAAAA3ZESZHQ> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >