AcademySoftwareFoundation / OpenPBR

Specification and reference implementation for the OpenPBR Surface shading model
Apache License 2.0
425 stars 18 forks source link

Refactoring MaterialX implementation to align more closely with the spec #92

Closed portsmouth closed 12 months ago

portsmouth commented 12 months ago

Here is an attempt to write the MaterialX implementation in a way which aligns as closely as possible, given the current form of the MaterialX spec, with the formalism in the current OpenPBR spec. To make it easier to digest (since XML is tough to read), I wrote the functional form of it in Latex as screen-shotted below.

The changes i've made roughly amount to:


This still differs in various important respects to the spec:

image

image

image

jstone-lucasfilm commented 12 months ago

Thanks for getting this conversation started, @portsmouth, though I believe we'll want to simplify this down to a set of purely functional changes, leaving any formatting improvements for a future proposal. This will allow us to track the changes to our reference implementation robustly over time, and will allow us to consider new formatting ideas independently, since it's important to maintain the clarity of parallels between OpenPBR and existing shading models such as Autodesk Standard Surface, glTF PBR, and UsdPreviewSurface. It's the clarity of these parallels between models that allows developers to author and maintain shader translation graphs, which will be an important part of future OpenPBR development.

I'm also noticing that this new version no longer renders at all in MaterialX validation applications, and I just get a series of validation warnings and a uniform black output in MaterialXView and MaterialXGraphEditor.

Rather than fixing each of these individually, though, I would recommend starting fresh with the absolute minimum set of functional changes that you'd like to see

If you'd like, you can just propose each individual change as a GitHub Issue, and I can help out with the concrete changes to the reference implementation, validating each one in a MaterialX rendering environment (and posting example renders) to make sure it behaves as we'd like.

portsmouth commented 12 months ago

Fair enough about the formatting changes (I assume you mean e.g. indentation and comments), I'll remove them. I do think they make the XML file a bit easier to read (more clear section headings and structure), but agreed it's best to decouple that from the functional changes. (Things like the names of the nodes though, I think are fair game as it impacts how the correspondence is made between the XML and the spec.)

I'd prefer to do the refactor of the functionality in one PR, otherwise it's going to be too long a process of minor increments. It should be easy enough to figure out why it's not passing the checks, probably just some minor errors. I will shortly push a version with the formatting changes omitted.

Also I was hoping to discuss the various things we are not able to express, as outlined above. If preferred, I can move that over to a GitHub issue though. Though I would like to have all these points engaged with by the MaterialX people. If Niklas has access, perhaps we can get the conversation going. (edited)

portsmouth commented 12 months ago

Closing in order to refactor as more incremental changes.