-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Viewer material variants #15920
Viewer material variants #15920
Conversation
…ssemble the final toolbar with dividers
Expose material variants related APIs from Viewer layer
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed offline
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
Snapshot stored with reference name: Test environment: To test a playground add it to the URL, for example: https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/15920/merge/index.html#WGZLGJ#4600 Links to test babylon tools with this snapshot: https://playground.babylonjs.com/?snapshot=refs/pull/15920/merge To test the snapshot in the playground with a playground ID add it after the snapshot query string: https://playground.babylonjs.com/?snapshot=refs/pull/15920/merge#BCU1XR#0 |
WebGL2 visualization test reporter: |
Visualization tests for WebGPU (Experimental) |
This PR adds support for material variants along with default UI in the new Viewer.
ViewerMaterialVariants.mov
KHR_materials_variants
extension to have a callback option that "returns" a "controller" (available variants + selected variant).KHR_materials_variants
already has both instance and static functions for getting material variants and selecting a material variant, but this would require importing the extension, and we don't want the extension included in the bundle statically (we only want to pay the bundle cost of the extension when it is actually used). This "controller callback" is kind of a new pattern for glTF extensions using the newish options support. Another way to do this would be to have a higher level callback option for when a specific loader plugin is created (analogous toOnPluginActivatedObservable
) and when a specific glTF extension is created (analogous toonExtensionLoadedObservable
) and use the extension instance directly. I don't really like this because to me it seems like a complex API (in the same way the static observables are complex and often a sticking point for users). Another option yet would be to have some kind of extensible output object in the same way options are an extensible input object. For example,AssetContainer
could have anextras
property (or something like that) where the underlyingAssetExtras
type could be extended by loader plugins and glTF extensions. Then you might do something like (const variants = assetContainer.extras.materialVariants
andassetContainer.extras.selectedMaterialVariant = someVariant
). That would be a bigger change though, and I'm not sure how we would make something like this work across the different loader functions. I think it could make sense forloadAssetContainerAsync
, but maybe not the other loader functions. Thoughts @bghgary?KHR_materials_variants
to expose a simple material variants API.