You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This applies to both Models and 3D Tiles. For models that use the khr_materials_common extension the same shader construction logic will occur every time.
Instead, the materials going through here can be stringified and act as keys to the generated gltf sections - techniques, shaders, and programs. I imagine gltf 2.0 will benefit from a similar strategy.
Are we sure this is worth it? I suspect it is not. The shaders will still be in the shader cache and this will be almost completely irrelevant and an extra thing to deal with when we add PBR for glTF 2.0 and potentially separate materials for sharing across many tiles in a future version of 3D Tiles.
For #3241
@rahwang
Brought up on the forum: https://groups.google.com/forum/#!topic/cesium-dev/laA723va6gI
This applies to both Models and 3D Tiles. For models that use the khr_materials_common extension the same shader construction logic will occur every time.
Instead, the materials going through here can be stringified and act as keys to the generated gltf sections - techniques, shaders, and programs. I imagine gltf 2.0 will benefit from a similar strategy.
Most of the code changes will actually belong in https://github.com/AnalyticalGraphicsInc/gltf-pipeline since
modelMaterialsCommon
is built from there: https://github.com/AnalyticalGraphicsInc/gltf-pipeline#building-for-cesium-integration.The text was updated successfully, but these errors were encountered: