Consistent presentation/rendering of model resources

I agree that it is very good to make it easy for people to display 3D content in a web page. I completely disagree with the methods and processes described in this proposal to make it an HTML element. HTML elements need to be fully defined so that they can be similarly implemented across browsers and reflect what people would see in applications outside of browsers. The process of rendering a high-quality model requires proper handling and rendering of the model's geometry, appearance, animation, and interaction.

My knowledge is in glTF (and glTF binary) so these comments may or may not reflect on the capabilities of USDZ. I will address the topics as separate issues: Appearance and Animation / interactivity; with respect to 3D models in glTF format. Static geometry is pretty straight-forward and not subject to much interpretation.

The really difficult part is appearance. The document states that "it is impractical to define a pixel accurate rendering..." for models. However, this is really important. Khronos has done extensive work in the 3D Commerce Working Group towards pixel accurate rendering across multiple 3D viewers (https://www.khronos.org/3dcommerce/certification/). The accuracy was demanded by retailers so their products would appear visually identical across different web sites. There were so many factors that mattered in producing acceptable renderings that include lighting, rendering calculations (including equation approximations), conversion from GPU to display, and tone mapping.

The component that caused the most issues and difficulties is lighting. A model built for physically-based rendering looks best in a complex lighting environment. This is usually done with image based lighting, but punctual plus area lights will also work. The statement that "A future version ... will describe the lighting model and environment .... Both items will require community collaboration and some consensus." makes the process sound much easier that Khronos found it to be.

Some issues that came from the Certification work. Note that the Certification program did not solve all of these in the initial release.

• Is lighting done as an 8-bit RGB or 16-bit HDR image
• Is lighting done with many point and area lights?
• How does the content creator provide for different lighting?
• How does the user adjust the lighting to match a particular environment?
• What background is used for the model display?
• How is the (floating-point) rendering converted to an 8-bit RGB display?
• How is the rendering adjusted depending on user environment?
• How is the rendering adjusted depending on device (hardware, OS, browser)
• How is time-dependent display degradation handled?

It may be possible to construct an initial release without resolving all of these items.

No files, entry points, or tests are identified in the issue. Start by reviewing the model-element proposal and the glTF rendering concerns, especially lighting and display consistency; done would require an agreed specification for the unresolved rendering behavior, not a scoped code change.