CesiumJS 技术博客:glTF 模型(Model)加载新架构

发布网友发布时间：2024-05-11 17:49

共1个回答

热心网友时间：2024-05-11 20:52

CesiumJS and glTF's Collaboration: A Journey from 1.0 to 2.0

In 2012, the partnership between CesiumJS and glTF began, marking the foundation for a powerful evolution. The glTF format advanced to version 2.0, seamlessly integrating support for 3DTiles attributes and texture sharing. The CesiumJS team embarked on a mission to revamp their model loading mechanism, with a focus on decoupling load and render, enabling per-vertex data and customizable shaders. This new Model class, born out of necessity, separates loading and parsing, with GltfLoader acting as the intermediary to load glTF files and generate ModelComponents. To optimize memory usage and performance, resources are shared globally through the ResourceCache, significantly recing memory footprint. For instance, the San Diego 3DTiles data set witnessed a remarkable decrease from 564MB to 344MB.

Shader Generation Strategies

"Super Shader" Approach:A single, comprehensive shader file tailored to known algorithms, such as PBR rendering in glTF. This method, exemplified in the code, handles basic diffuse color and occlusion factors.
Dynamically Generated Shaders:Adaptable to unpredictable factors like skinned models with variable joint count, yet requiring careful management to ensure maintainability. processPbrMaterials.js showcases the older implementation.

The new architecture promotes a molar "pipeline stage" design, each stage functioning as a standalone GLSL function, with macro-controlled customization. This molar structure, seen in ModelFS.glsl's main function, mirrors the optimization of "super shaders" while maintaining a fixed pipeline order.

Molar Shader Design in Action

CesiumJS shaders utilize a molar approach, embracing both pre-built "super shaders" and dynamically generated JavaScript. Each material stage follows a standardized format like MaterialStageFS.glsl. Additional stages, such as feature ID handling, generate GLSL code dynamically based on model attributes. This design caters to user requirements, offering expandability and a clear separation between GLSL code and JavaScript logic, stored in dedicated shaders files.

The rendering process involves JavaScript-defined pipeline stages, like XXXPipelineStage, which handle input/output resources like ShaderBuilder, VertexAttributes, uniform maps, and WebGL state variables. By defining GLSL functions in vertex, fragment, or both shaders, developers create DrawCommands that feed CesiumJS's rendering engine. The process encompasses configuring the pipeline, creating resources, executing, and generating ModelDrawCommands, ultimately pushing them into the frameState.

Illustrating the Pipeline: From Simple to Complex

Simple models might have just a few stages, focusing on VertexAttributes, shader transformations, and Material and LightingPipelineStage operations for texture and lighting. More intricate models, such as those utilizing the EXT_mesh_features extension, involve vertex classification and custom visualization through CustomShader.

Custom shaders shine in the MaterialPipelineStage, dynamically generating fragment shaders based on FeatureIds, while CustomShaderPipelineStage allows developers to manipulate materials through a custom fragmentMain() function. The lighting pipeline remains constant.

Integrating glTF and 3DTiles

b3dm and i3dm tiles wrap glTF, incorporating batch and instance transformation tables. Cesium3DTileContent classes cater to each format, with point cloud (pnts) handling independent of glTF. 3DTiles 1.1 supports direct glTF references, enhancing the glTF ecosystem within CesiumJS.

The transition to the Model object in 3DTiles 1.0 marked a simplification, reflecting the introction of the new architecture. My personal journey involved translating and understanding the integration of 3DTiles 1.1 and CesiumJS 2022, along with a deep dive into glTF. This collaboration has propelled the glTF standard forward, particularly with glTF 2.0. The Model architecture unlocks new possibilities, fostering flexibility for future enhancements. Fellow developers have already leveraged this to enhance PBR effects, but there's still much to explore in the domestic scene.