"A Beautiful Game" via the gltf_pbr node #1098
Conversation
|
|
|
Thanks for providing this great reference, @emackey, and I'd be interested in incorporating some of these improvements and observations directly into the MaterialX codebase. Two initial thoughts come to mind:
|
Yes, I think this should become the new GLB file for the Chess Set. One performance implication is that typical real-time systems make [at least] one draw call per mesh, so it's likely that this new version causes typical systems to issue more draw calls than the previous version. But, the memory savings (both file and GPU mem) and added flexibility (to move chess pieces around individually) make this a worthwhile trade, in my opinion.
Yes please. I'm not equipped to debug a MaterialX node graph myself. |
|
Without looking at this too closely yet, some off the top comments:
I am curious about the USD version of this @pablode -- I assume that it's using std surface currently so it shows up with existing render delegates? It would however be good to see how this new version renders in USD. |
|
The transmission is not working because the wrong material is assigned. I think there are two issues at play here:
The materials can still be assigned manually, proving that the glTF PBR works correctly. @emackey nice job with baking the displacement maps in the normal maps! I think it would make sense to also apply this change to the USD version once this PR is merged. |
|
@pablode Awesome, thanks for the investigation and advice. I've pushed an update to the |
|
This looks like great work, thanks @emackey and @pablode! Taking this forward within the MaterialX repository, my recommendation would be to update the canonical GLB for the Open Chess Set to match this latest version, with a corresponding update to the When we ultimately store a glTF PBR version of the chess set in MaterialX, it should likely be an in-place shader translation of the Standard Surface version (e.g. using the |
|
I'll take a look at updating the Standard Surface graph to match what the glTF graph is doing now. But, I do have concerns about downgrading the glTF version to be just an output target for a translation graph. In particular,
|
|
Good points, @emackey, and I completely agree that we don't want to suggest that any shading model is preferred over another in MaterialX. An artist should be able to choose the right shading model for their needs, and there are many situations in which the right choice is glTF PBR. On the other hand, since the Open Chess Set was originally authored in Standard Surface, there are some advantages in maintaining this as the authoritative definition of that asset, with other versions being derived through shader translation. To my mind, the ideal outcome would be for another high-quality asset to be contributed to MaterialX using the glTF PBR shading model, and this asset would then be canonically defined in glTF PBR. No hurry on the update to the geometry for the Open Chess Set, but I do think that your optimizations would be broadly valuable, irrespective of which shading model the user prefers for rendering the asset. |
|
@emackey Here's a quick sketch of the "pure optimization" version of your proposal, where we'd be replacing the canonical geometry for the Open Chess Set with your optimized, refactored version: My sense is that this change would be worthwhile on its own, and a single, optimized geometric definition would make it straightforward to include additional shading models in the future without duplication. What are your thoughts? Would you be interested in writing up a pull request along these lines? |
- Displacement maps from orgininal tutorial baked into normal maps. - Higher JPG quality setting, particularly noticable on the chess board. - Ambient Occlusion maps baked for all chess pieces.
emackey
force-pushed
the
a-beautiful-game
branch
from
1a576c2 to
ab5dd1a
Compare
|
@jstone-lucasfilm Thanks for the SS material mapping. You're welcome to merge just the new geometry, as you prototyped in that commit. I will point out though that the texture set included here is not the canonical one: The original texture set included displacement maps, and much higher quality textures than would make sense to include here. For the glTF version, I had baked the displacement into the normals, and I had re-converted some textures (particularly the large chess board) from the originals to new JPGs with higher quality settings, as I was seeing artifacts on the board. (There still are some, not as many as before). I've pushed a new thing to consider: The new image set has been migrated to the I'd certainly understand if you or other maintainers here wish to decline this kind of change, as it may be too much glTF-ness leaking into a Standard Surface example. But take new screenshots and compare with |
|
This changelist looks really promising, thanks @emackey, and the error messages seen above are related to the shader translation system in MaterialX (not your pull request). My main concern with changing/upgrading the textures is that we have a number of canonical renders of the Open Chess Set in Arnold and Karma CPU/XPU (including a very prominent one on www.materialx.org), and we'd need to consider these renders out-of-date if we modified the canonical versions of the textures for this asset. Upgrading the geometry doesn't create this concern, as in theory it should have no effect on the renders if they were run again today. Perhaps we should take this in stages, upgrading the geometry for now, and then considering how the textures ought to evolve over time. Let me know what your thoughts are. |
|
I'm fine with that too. Your commit here captures that well I think: |
|
Since that optimization work was 100% yours, I'd be happy for you to contribute that change! Let me know, though, if you'd prefer that we make the change on our side instead. |
|
I'll close out this pull request for now, but I believe it remains valuable as a reference for future optimizations and improvements to the Open Chess Set. Thanks, @emackey! |
UPDATE: This branch has been redone, and now contains the updated texture set in a common location. There is a single
chess_set.glbfile that works with both Standard Surface and glTF material versions, interchangeably.The following original description is mostly obsolete now.
I'm opening this PR for comparison purposes. I don't think that folks would actually want "chess_set" and "a_beautiful_game" to co-exist in the examples folder, as users could easily confuse the material set from one with the geometry from the other, causing bad things to render.
This PR contributes a second copy of "A Beautiful Game," the chess set originally from SideFX that was open-sourced by ASWF during SIGGRAPH 2022. This new copy uses the
<gltf_pbr>node, trying to replicate the glTF PBR materials from glTF's own new version, "A Beautiful Game" glTF sample model.There is an issue here with
transmissionon<gltf_pbr>, which could be my error or could be some deeper problem, I'm not sure. The tops of the pawns (Pawn_Top_BandPawn_Top_W) call fortransmissionbut it doesn't look like they have it correctly enabled.a_beautiful_game.glbis ~ 10.3 MB, and its materialgltf_pbr_a_beautiful_game.mtlxreferences ~ 18.1 MB of textures.By comparison,
chess_set.glbis ~ 34 MB, usingstandard_surface_chess_set.mtlxwhich references ~ 15.1 MB of textures.In the existing chess_set version from main, you can see transmission in the tops of the pawns, that is not working somehow in the gltf_pbr version.
Note the models are NOT interchangeable. The new one contributed here has much smaller geometry because I've made use of instancing. The new model contains only one copy of the pawn's mesh data, where the old one has 16 copies, one for each pawn. Likewise for other pieces, all instanced 2 times or 4 times as appropriate. This makes the mesh "playable" in that a host application could move the pieces around as individual nodes. But it changes the node structure and naming system, so the material set needs to be adapted for the new structure.
One more difference, the glTF texture set is slightly larger. I have a somewhat higher quality setting particularly for the chess board itself, and I baked the original displacement maps into the normal maps. In addition, the glTF textures contain ambient occlusion, which is wired into the gltf_pbr node but never used by MaterialXView.
Compare to this screenshot from BabylonJS, a real-time render in WebGL:
Note for example the dark "slot" in the top of the Bishop. The AO map lets Babylon know that not much environmental light gets in that slot, although a direct light source could still illuminate the inside of it if needed. It would be great for MaterialXView to be able to pick up the AO map from gltf_pbr and make use of it for non-path-traced interactive renders.
/cc @kwokcb @proog128 @jstone-lucasfilm