Improve first sentence of front page

[portsmouth]

To not use "uber-shader" but "material model", and to mention physically-based explicitly.

Adjust the first sentence of the spec accordingly. Also, mention the Adobe/Autodesk collaboration only in the Historical Background section, as agreed.

[virtualzavie]

I wouldn't abreviate "specification".

I agree that, as a high-level definition, just referring to OpenPBR as a "material model" is just simpler, but that's without consider possible confusion (is it a problem though?).

[jstone-lucasfilm]

This may differ for others, but in my own mind, the term "uber-shader" brings up an image of artist-facing shading models such as glTF PBR, Standard Surface, and ILM Unified. The term "material model", for me, suggests a complete framework for the expression of both BSDFs and the patterns that connect to them, with MaterialX being one example of such a framework.

[portsmouth]

This may differ for others, but in my own mind, the term "uber-shader" brings up an image of artist-facing shading models such as glTF PBR, Standard Surface, and ILM Unified. The term "material model", for me, suggests a complete framework for the expression of both BSDFs and the patterns that connect to them, with MaterialX being one example of such a framework.

I just find the term "shader" very ambiguous, it has so many different meanings in graphics.

To me a "material model" means a physical model of a specific material structure, which is exactly what we define in OpenPBR. I would say we do this more explicitly even than in MaterialX, since we are quite detailed about all the physical components.

Something like MaterialX, OSL, MDL etc. are more like material "frameworks" or "formalisms", i.e. systems for building arbitrary material models. The word "shader" suggests to me simply programs that generate procedural textures, like the pattern inputs in a node graph.

Obviously, we may have different opinions about the wording then. So let's just try to find a compromise.

[portsmouth]

I wouldn't abreviate "specification".

Yep agreed.

[meshula]

To my mind, a shader is a thing that is a concrete implementation of a shading model; in other words a shader is a shading system specific implementation, in that shading system's unique language (OSL, GLSL, etc) of that shading model. If "material model" is the thing that MaterialX is responsible for, calling this model "OpenPBR Surface Material Model" seems, to me, to emphasize that it is (1) an OpenPBR Surface, (2) expressed as a MaterialX Material Model. So my two cents is that "OpenBR SMM" enhances the messaging about the relationship between MaterialX and OpenPBR, and most clearly expresses what the "product" actually is ~ a materialX graph implementing a particular shading model that can be used to generate shaders for shading systems.

[jstone-lucasfilm]

These are great notes, @meshula, and to me it seems telling that we're regularly falling back to the term "shading model" to refer to the underlying physical model (e.g. glTF PBR, OpenPBR) from which a block of shader code has been derived or generated. This is certainly the term we use within our own production studio to refer to open shading models such as Standard Surface and custom shading models such as ILM Unified.

Could it be that we're already using the ideal term in our current, informal discussion, and that we ought to use the phrase "OpenPBR Surface shading model" in our specification? To me, this seems completely clear, unambiguous, and aligned with industry terminology, but I recognize that not all companies and studios are harmonized in their use of language.

[meshula]

"OpenPBR Surface shading model" works perfectly fine for me!

[portsmouth]

I liked @meshula's suggestion of OpenPBR Surface Material Model. It makes sense that MaterialX is about defining/implementing various different physically-based material models, and OpenPBR Surface describes one specific such physical model that we think is useful.

I'm a bit unclear what a "shading model" is. To me, shading is about the interaction of light with the surface (e.g. when an artist shades, i.e. puts down marks to give the impression of a lit object, he is thinking about both the material being lit and the source of the light). So shading is more about what a renderer does, i.e. the light transport. Whereas OpenPBR is only about the physical material (by describing the optical properties, like BSDFs, and the structure). As @meshula notes, "shader"/"shading" also heavily implies a concrete implementation in some language, and historically has usually been unrelated to an underlying physical material model.

We use the phrase "material model" 7 times in the spec. We use "shading model" twice -- once in the abstract, and once to describe another model. I think we need to be more consistent about this. We also refer to the specification inconsistently as defining a "material model" or a "shader" in various places.

I'd propose we standardize on OpenPBR Surface Material Model, and be consistent about it. I think the term "shader" can be reserved maybe to mean the way the model is usually presented in applications, as an object which contains all the parameters (i.e. "uber-shader") that can be applied to a surface to endow it with the material properties thus producing the desired appearance when "shading", i.e. rendering. (Though some applications call this a material, which makes more sense as well).

[jstone-lucasfilm]

@portsmouth It's worth noting that our press release uses the phrase "shading model", and this language was hammered out in long, detailed discussions between Autodesk, Adobe, and the ASWF:

https://www.aswf.io/blog/academy-software-foundation-announces-openpbr-a-new-subproject-of-materialx/

Although I'd strongly vote for keeping the current phrasing, we can pick up this discussion after today's 0.2 release, and there's no hurry to change this language today.

[portsmouth]

OK, though I assume you'd agree at least we should be consistent in the document? If it's not a material model, perhaps we should replace that phrase everywhere with "shading model" (Is that terminology defined somewhere?).

Agree we can leave it for a later release -- I don't think this impacts the readability of the document very much, though it does make it seems less polished that we use this jargon inconsistently.

[portsmouth]

I noticed that even PBRT seems to use "shader" more or less interchangeably with "material". For them shader/material is just the BSDF of the surface (or rather a set of BSDFs, that are summed to produce the total).

[meshula]

With regards to consistent language, the original source of "shaders" is the Renderman specification where we can read things like

Traditional shaders are introduced by the keywords light, surface, volume, displacement, or imager and are followed by the name of the shader and the statements that comprise its definition. These keywords indicate the type of RenderMan Interface shader that is being defined. The RenderMan Interface uses the shader type to enforce a type match in subsequent calls to RenderMan Interface procedures. For example, it is illegal to declare a shader to be of type light and then instance it using RiSurface.

The arguments to a shader are referred to as its instance variables. All of these variables are required have default values, and are assumed to be uniform unless declared otherwise. Shader instance variables can be changed when a particular shader is instanced from the RenderMan Interface. For example, consider the shader weird:

surface
weird( float a=0.5; varying float b=0.25 )
{
     Ci = color (mod(s,a),  abs(sin(a+b)),  mod(b,t));
}

This surface shader may be referenced through the RenderMan Interface with the RiSurface command. For example,

RiSurface( "weird", RI_NULL );

From the above it's clear that the foundational definition of a shader was a piece of code invoked by a shading system, through a parameterized interface, and a shading model is the thing the shader implements. I would say that the use of "shader" highlighted in PBR is consistent with Renderman's precedent.

In the case of this specification, "shading model" as used a few times in the press release is precise-enough to the degree that it explicitly says "this is a model of something a shader can implement", so "shading model" agrees with the historical meaning. I like that it's within reach to use consistent language with a consistent lineage to today's practice.