A Cesium and ThreeJS integrated system and its construction method

Abstract

This invention belongs to the field of engine software technology and discloses a fusion engine and construction method for Cesium and ThreeJS. This method loads a low-level WebGL interface, a spatiotemporal data layer above the WebGL interface, a 3D scene management layer above the spatiotemporal data layer, and a digital twin layer above the 3D scene management layer. This completes the digitization of the natural environment, infrastructure, physical equipment, and dynamic target entities, and provides interaction interfaces for various entities. This invention uses a combination of Cesium and ThreeJS to implement a Cesium-based ThreeJS renderer, implementing some ThreeJS interfaces within Cesium. This achieves support for high-concurrency, large-volume geographic data loading and display, and also achieves ThreeJS-level model rendering effects.

Description

Technical Field

[0001] This invention belongs to the field of engine software technology, and in particular relates to a fusion engine of Cesium and ThreeJS and its construction method. Background Technology

[0002] Currently, common WebGL-based engine technologies include Cesium, ThreeJS, and Babylon.js. Cesium is used for geographic information, while ThreeJS is used for game engines, with both being integrated. CesiumJS is an open-source and free 3D map development framework, and ThreeJS is also an open-source and free 3D rendering framework. Both are web front-end 3D visualization frameworks based on WebGL technology and developed using JavaScript, and are widely used both domestically and internationally. Cesium visualization primarily uses geospatial data, such as satellite imagery, terrain, and city-level 3D models. The data volume and spatial range are very large, and the accuracy requirements are even higher. Therefore, its core advantages are high performance, high accuracy, and standardized specifications. These standardized specifications are reflected in its adherence to industry standards and its leading role in developing 3D Tiles standards.

[0003] Advantages: Powerful geographic data visualization capabilities; a complete web-based geographic information system; supports 3D visualization of time-series dynamic data; includes geographic environmental elements such as solar, atmospheric, and cloud / fog data; supports loading of 3D models, terrain, and imagery. Supports models exceeding 3TB and oblique photogrammetry OSGB data.

[0004] Disadvantages: Limited support for model data formats, only glTF and 3dTiles formats are supported; flexible manipulation and dynamic assignment of individual nodes in the model are not possible. Rendering effects are simple. Only one material is supported (PBR).

[0005] The goal of ThreeJS is to build an easy-to-use, lightweight, cross-browser universal 3D rendering framework. Its core data consists of 3D objects and 3D models. It has unique advantages in visual presentation, scene organization, 3D object management, animation, and scalability. Combined with its physics engine, it has great application prospects in large-screen 3D display, games, simulation, and other fields.

[0006] Advantages: Powerful game engine rendering and visualization capabilities; creation and loading of 3D models in multiple file formats; support for rendering of various materials and textures such as PBR, Physical, Basic, and Standard; creation of complex 3D scenes and lighting effects; implementation of 3D physics simulation and collision detection; implementation of complex animations and particle effects; support for rich model node management and flexible interaction capabilities.

[0007] Disadvantages: It cannot support the loading and management of massive model data; it does not have geographic information system capabilities; and its ability to load large models is far inferior to that of a GIS system.

[0008] Babylon.js, a game engine based on WebGL launched by Microsoft in 2014, is similar to ThreeJS in performance due to its short development time. In the transportation industry, digital twin implementation involves not only the scheduling of massive amounts of "static" data, but also an exponential increase in the number of "moving" objects in the scene. Data updates are more frequent, the granularity of updated components is finer, and users have higher requirements for the visual effects of the 3D scene. Cesium's capabilities in this area are clearly insufficient.

[0009] ThreeJS, a lightweight WebGL wrapper library, employs a scene graph rendering model and manages all elements through an Object3D hierarchical structure. Its core advantages lie in its flexible material system and rich extension ecosystem, allowing developers to finely control the rendering pipeline and achieve various effects, from particle effects to complex animations. Cesium, on the other hand, is a benchmark for geospatial 3D engines, building a complete GIS framework based on GLSL shaders. Its proprietary Cesium3DTileset enables efficient rendering of large-scale 3D geographic data, and its built-in ellipsoidal mathematics library supports accurate calculations in the WGS84 coordinate system. Typical applications cover geospatial fields such as digital twin cities and transportation. Summary of the Invention

[0010] To overcome the technical problems existing in the related technologies, this paper specifically involves the integration engine and construction method of Cesium and ThreeJS.

[0011] The technical solution is as follows: a fusion engine for Cesium and ThreeJS, comprising:

[0012] The underlying WebGL interface is used to provide a graphics rendering working environment for GIS engine renderers and game-level engine renderers;

[0013] The spatiotemporal data layer, located above the WebGL interface, is based on the GIS engine Cesium and completes the loading, scheduling, and management of terrain tiles, satellite imagery, and vector data; spatial feature identification and picking mechanisms; spatial feature query mechanisms; and time series data visualization, analysis, and processing.

[0014] The 3D scene management layer, located above the spatiotemporal data layer, is based on the lightweight game-grade engine ThreeJS. It is responsible for 3D graphics, 3D model rendering and instantiation rendering, as well as the management of post-production special effects.

[0015] The digital twin layer, located above the 3D scene management layer, is used to digitize the natural environment, infrastructure, physical equipment, and dynamic target entities, and provides interaction interfaces for various entities.

[0016] Furthermore, in the WebGL interface, the GIS engine renderer and the game-level engine renderer encapsulate vertices, indexes, textures, rendering states, shaders, and drawing instructions for the spatiotemporal data layer and the 3D scene management layer, respectively, providing spatiotemporal data processing and graphics rendering.

[0017] The spatiotemporal data layer is also used to provide the mathematical libraries, geometric libraries, and algorithm libraries required by the geographic information system.

[0018] In the 3D scene management layer, the 3D scene is overlaid with the GIS scene, and the rendering cameras of the 3D scene and the GIS scene are synchronized. The 3D scene is organized and managed using a scene node tree data structure. All 3D objects can access specific node transformation parameters. For the rendered 3D objects, specific geometry and materials are accessed, and vertex positions, colors, node positions and material-related attributes can be modified as needed.

[0019] Another objective of this invention is to provide a method for constructing a fusion engine of Cesium and ThreeJS, comprising:

[0020] S1 loads the underlying WebGL interface, providing a graphics rendering working environment for GIS engine renderers and game-level engine renderers;

[0021] S2 loads the spatiotemporal data layer located above the WebGL interface. Using the Cesium GIS engine, it completes the loading, scheduling, and management of terrain tiles, satellite imagery, and vector data; spatial feature identification and picking mechanisms; spatial feature query mechanisms; and time series data visualization analysis and processing.

[0022] S3 loads the 3D scene management layer located above the spatiotemporal data layer. It utilizes the lightweight game-grade engine ThreeJS to complete 3D graphics, 3D model rendering and instantiation rendering, as well as the management of post-production special effects.

[0023] S4 loads the digital twin layer located above the 3D scene management layer, completing the digitization of the natural environment, infrastructure, physical equipment, and dynamic target entities, and providing interaction interfaces for various entities.

[0024] Furthermore, in step S2, terrain tile loading uses Cesium's EllipsoidTerrainProvider and CesiumTerrainProvider classes, and is executed after CesiumTerrainProvider optimization:

[0025] (1) Set the maximum range of the terrain rectangle; (2) Set the terrain data source viewer.terrainProvider; (3) Request terrain tiles in the rendering loop; (4) Calculate the rectangular range of the tile to be requested, tileRectangle; (5) Determine whether the terrain range rectangle and the tile range tileRectangle intersect; if they intersect, send a request and complete the loading of terrain tiles; if they do not intersect, do not send a request and return undefined, and the current tile elevation is 0.

[0026] In step S2, satellite image loading includes image tile loading. The ImageryProvider interface of Cesium is used to complete the Cesium image tile data source based on the OGC specifications of WMS, TMS, and WMTS, and the Cesium image tile data source class is further encapsulated by extending the image tile layer.

[0027] Vector data loading includes: using a two-dimensional vector loading method to complete vector dynamic slicing and drawing by tile range through an image tile interface;

[0028] The 3D vector loading method is divided into 3D annotation and 3D white model modes according to the feature type. The 3D white model mode is to stretch vector surface features into a 3D white model and display it separately using 3D graphics rendering. The 3D annotation point data and attribute text are displayed on a 3D globe in the form of 3D solid text, and the text is always perpendicular to the screen.

[0029] In step S2, the 3D scene management layer synchronizes the camera and unifies the rendering loop, so that the 3D scene based on ThreeJS and the GIS scene based on Cesium are integrated. The 3D graphics are composed of geometry and materials. The geometry is composed of vertex attributes and indexes. The 3D model is composed of one or more 3D graphics. Multiple graphics are merged into a group. A 3D graphics group is a 3D model node. The 3D model nodes are further grouped to obtain new 3D model nodes.

[0030] Instantiated rendering includes: drawing multiple instances of the same 3D graphic in a single rendering, and drawing the same 3D graphic to different positions in three-dimensional space after translation, rotation, and scaling transformations;

[0031] After instantiation and rendering, additional instantiation animations are needed to allow for independent control of model animations for different instances; post-processing effects management is accomplished using Cesium's post-processing effects library.

[0032] In step S4, infrastructure digitization includes static infrastructure and dynamic infrastructure; static infrastructure, including basic roads, is a typical example of static infrastructure. Dynamic infrastructure includes facilities along roads whose shape, appearance, or state is synchronized with objects in the real world.

[0033] The basic road digitization includes basic road loading, constructing a road state model, loading a basic road elevation model that combines a mathematical model and 3D graphics created based on the road boundary line, and providing road elevation sampling methods and road boundary query methods;

[0034] The digitization of facilities along the route includes: using a single 3D model to represent the same type of equipment, and rendering it using a 3D model instantiation rendering interface; the status of facilities and equipment along the route is represented by instance transformation parameters, instantiation animation, and post-processing highlighting methods; instance transformation parameters include changing the size, rotation attitude, and small-range offset states of the equipment; instantiation animation represents the operating status of the equipment; post-processing highlighting methods include overlaying colors to change the appearance of the equipment;

[0035] Digitalization of the natural environment includes: water simulation based on Cesium water surface material and ThreeJS Water class; meteorological condition simulation based on particle effects, simulating phenomena such as sunny, rainy, snowy, foggy weather, and changes in light over time.

[0036] In step S4, the digitization of the dynamic target entity includes:

[0037] The motion trajectory of dynamic targets is digitized. The InstanceAminationCollection and InstanceAnimation classes and the motion trajectory management represent the graphical objects of dynamic targets. The latest trajectory point coordinates are obtained from the trajectory management object frame by frame, and the graphical positioning parameters are updated.

[0038] Moving target tracking: The camera's field of view follows the moving target according to the motion angle. The camera tracking control, CameraTrackController, is used to track the target. The current position and rotation transformation parameters of the moving target are obtained in real time and passed to the camera tracking control to complete the moving target tracking.

[0039] This invention utilizes a combination of Cesium and ThreeJS to implement a Cesium-based ThreeJS renderer, implementing some ThreeJS interfaces within Cesium. This achieves support for loading and displaying high-concurrency, large-volume geographic data, while simultaneously realizing ThreeJS-level model rendering effects. Specific effects are as follows:

[0040] (1) Achieve dual-drive operation of GIS engine and game-level engine to fully meet different user scenarios.

[0041] (2) Based on the GIS engine Cesium, it realizes the management of spatial data such as terrain, image, and vector, supports the loading and scheduling of massive terrain tiles, image tiles, and vector tiles, and provides local terrain filling and excavation and spatial element management functions;

[0042] (3) 3D graphics rendering based on a game-level engine, including the rendering of basic 3D graphics and 3D models. Basic 3D graphics rendering is the basic module of the digital twin engine. Spatial data such as 3D models, terrain, and vectors can be converted into basic 3D graphics for rendering. 3D model rendering is the foundation of digital twin applications. The digital twin of an entity can be constructed based on a 3D model. The state of the entity can be expressed through changes in parameters such as the shape, appearance, position, and posture of the 3D model.

[0043] (4) Implement instantiated rendering to provide a higher-performance rendering method for a large number of entities with similar shapes and appearances, so as to make full use of limited computer hardware and network resources. At the same time, instantiated rendering also needs to provide a mapping path between entities and rendering instances to ensure that the real-time state of entities can be expressed through parameters such as shape, appearance, position, and posture of the graphic instance;

[0044] (5) Implement commonly used post-processing effects such as lighting, outlining, anti-aliasing, and ambient occlusion (AO) to emphasize and highlight entities in specific states, thereby improving the rendering quality of 3D scenes.

[0045] (6) Provide rich and highly scalable digital interfaces. Digitalization of the natural environment, including water body simulation and meteorological condition simulation (sunny, rainy, snowy, foggy, etc.); digitalization of infrastructure, including the digitalization of infrastructure equipment such as roads and roadside facilities; digital management of dynamic targets, including movement trajectory, target tracking, etc.

[0046] (7) Provides rich secondary development interfaces, comprehensive development examples, and complete secondary development help documentation. Secondary development can meet the personalized needs of various industries and businesses such as highways, parks, cities, and building complexes. Attached Figure Description

[0047] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure;

[0048] Figure 1 This is a diagram illustrating the overall architecture of the Cesium and ThreeJS fusion engine provided in this embodiment of the invention.

[0049] Figure 2 This is a flowchart of terrain tile loading provided in an embodiment of the present invention;

[0050] Figure 3 This is a flowchart of local terrain filling and excavation provided in an embodiment of the present invention;

[0051] Figure 4 This is a 3D graphics creation diagram provided in the embodiments of the present invention;

[0052] Figure 5 This is a flowchart of the 3D graphics rendering process provided in an embodiment of the present invention;

[0053] Figure 6 This is a 3D model structure diagram provided in the embodiments of the present invention;

[0054] Figure 7 This is a flowchart of the 3D model rendering process provided in an embodiment of the present invention;

[0055] Figure 8 This is a basic road loading flowchart provided in an embodiment of the present invention;

[0056] Figure 9 This is a road state model diagram provided in an embodiment of the present invention;

[0057] Figure 10 This is a flowchart of the device data loading process provided in an embodiment of the present invention;

[0058] Figure 11 This is a flowchart of the device deployment process provided in an embodiment of the present invention;

[0059] Figure 12 This is a flowchart of a realistic water surface simulation provided in an embodiment of the present invention;

[0060] Figure 13 This is a basic flowchart of meteorological simulation provided in the embodiments of the present invention;

[0061] Figure 14 This is an instantiation effect diagram of the three-dimensional model provided by the present invention;

[0062] Figure 15 This is a rendering performance diagram before processing according to the present invention;

[0063] Figure 16 This is a rendering performance effect diagram after processing according to the present invention;

[0064] Figure 17 This is a high-precision road model of the present invention obscured by terrain.

[0065] Figure 18 This is a terrain-obscured image of the high-precision tunnel entrance / exit model of this invention.

[0066] Figure 19 This is a display effect diagram before the fusion process of the present invention;

[0067] Figure 20 This is a display effect diagram after the fusion processing of the present invention;

[0068] Figure 21 This invention designs terrain renderings in the application example of converting terrain models to DEMs.

[0069] Figure 22 This invention provides a low-precision terrain rendering example for the terrain model to DEM conversion application.

[0070] Figure 23 The example shown here is a fusion diagram of the converted DEM and low-precision terrain, which is used to illustrate the application of the terrain model to DEM conversion method of this invention. Detailed Implementation

[0071] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Many specific details are set forth in the following description to provide a thorough understanding of the present invention. However, the present invention can be practiced in many other ways different from those described herein, and those skilled in the art can make similar modifications without departing from the spirit of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0072] Example 1: In the Cesium and ThreeJS fusion engine provided in this embodiment of the invention, Digital Twin fully utilizes data such as physical models, sensor updates, and operational history to integrate simulation processes involving multiple disciplines, multiple physical quantities, multiple scales, and multiple probabilities, completing mapping in virtual space to reflect the entire life cycle of the corresponding physical equipment.

[0073] This invention's digital twin deep fusion engine serves as the technological foundation for digital twin applications. Its core capabilities are 3D graphics rendering and spatial data management, providing a basic platform for the construction, presentation, and interaction of digital twins, and offering technical support for the digital management of entities such as the natural environment and infrastructure equipment. The engine development should achieve the following goals: enabling dual-drive operation of a GIS engine and a game-level engine to fully meet different user scenarios. The GIS engine adopts the mainstream Web 3D GIS engine Cesium, characterized by high precision and high performance, while the game-level engine adopts the lightweight WebGL engine ThreeJS, which boasts high rendering capabilities.

[0074] Based on the GIS engine Cesium, it enables the management of spatial data such as terrain, imagery, and vector data, supports the loading and scheduling of massive terrain tiles, image tiles, and vector tiles, and provides local terrain filling and excavation and spatial element management functions.

[0075] 3D graphics rendering is implemented using the game-grade engine ThreeJS, including the rendering of basic 3D graphics and 3D models. Basic 3D graphics rendering is the foundational module of the digital twin engine; spatial data such as 3D models, terrain, and vectors can all be converted into basic 3D graphics for rendering. 3D model rendering is the basis of digital twin applications; a digital twin of an entity can be built based on a 3D model, and the state of the entity can be expressed through changes in parameters such as the shape, appearance, position, and posture of the 3D model.

[0076] Instantiated rendering provides a higher-performance rendering method for a large number of entities with similar shapes and appearances, making full use of limited computer hardware and network resources. Simultaneously, instantiated rendering also needs to provide a mapping between entities and rendered instances, ensuring that the real-time state of entities can be expressed through parameters such as the shape, appearance, position, and pose of the graphical instances.

[0077] It enables commonly used post-processing effects such as lighting, outlining, anti-aliasing, and ambient occlusion (AO) to emphasize and highlight entities in specific states, thereby improving the rendering quality of 3D scenes.

[0078] It provides rich and highly scalable digital interfaces. Digitalization of the natural environment includes water body simulation and meteorological condition simulation (sunny, rainy, snowy, foggy, etc.); digitalization of infrastructure includes the digitization of roads, roadside facilities, and other infrastructure equipment; and digital management of dynamic targets includes movement trajectories and target tracking.

[0079] It provides a wealth of secondary development interfaces, comprehensive development examples, and complete secondary development help documentation. Secondary development can meet the customized needs of various industries and business operations, including highways, industrial parks, cities, and building complexes.

[0080] like Figure 1 The diagram shows the overall architecture of the Cesium and ThreeJS fusion engine provided in this embodiment of the invention. The digital twin engine fusion engine categorizes and layers data for loading, rendering, and scheduling management. Based on the data overlay layers, the engine's functionality can be divided into four layers from bottom to top: the WebGL graphics rendering interface layer, the spatiotemporal data layer, the 3D scene management layer, and the digital twin layer.

[0081] The underlying WebGL interface is used to provide a graphics rendering working environment for GIS engine renderers and game-level engine renderers;

[0082] The spatiotemporal data layer, located above the WebGL interface, is based on the GIS engine Cesium and completes the loading, scheduling, and management of terrain tiles, satellite imagery, and vector data; spatial feature identification and picking mechanisms; spatial feature query mechanisms; and time series data visualization, analysis, and processing.

[0083] The 3D scene management layer, located above the spatiotemporal data layer, is based on the lightweight game-grade engine ThreeJS. It is responsible for 3D graphics, 3D model rendering and instantiation rendering, as well as the management of post-production special effects.

[0084] The digital twin layer, located above the 3D scene management layer, is used to digitize the natural environment, infrastructure, physical equipment, and dynamic target entities, and provides interaction interfaces for various entities.

[0085] For example, the underlying layer is the WebGL interface (WebGL graphics rendering interface layer), which is the working environment for the GIS engine renderer and the game-level engine renderer. The GIS engine renderer and the game-level engine renderer encapsulate vertices, indexes, textures, rendering states, shaders, and drawing instructions from the perspectives of spatiotemporal data management and 3D scene management, respectively, providing high-precision, high-performance spatiotemporal data processing capabilities and powerful graphics rendering capabilities.

[0086] The spatiotemporal data layer, based on the high-precision, high-performance GIS engine Cesium, enables the loading, scheduling, and management of massive terrain, satellite imagery, and vector data; spatial feature identification and picking mechanisms; spatial feature query mechanisms; and time-series data visualization, analysis, and processing. The spatiotemporal data layer serves as the spatial foundation of the entire digital twin system, providing the mathematical, geometric, and algorithm libraries required by the geographic information system.

[0087] The 3D scene management layer, based on the lightweight game-grade engine ThreeJS, implements basic 3D graphics, 3D model rendering and instantiation rendering, overlay of 3D scenes with GIS scenes, synchronization of rendering cameras for the two scenes, and organization and management of 3D objects. The 3D scene is organized and managed using a scene node tree data structure. All 3D objects can precisely access specific node transformation parameters. For renderable 3D objects (such as points, lines, and meshes), specific geometry and materials should also be accessible, allowing modification of vertex positions, colors, node positions, and material-related properties as needed. Furthermore, 3D scene management includes post-production effects management, encapsulating post-production effects interfaces based on the underlying renderer, providing commonly used post-processing effects such as lighting, strokes, anti-aliasing, and ambient occlusion (AO).

[0088] The digital twin layer is the top layer of the engine and the layer closest to industry applications and user interfaces. Based on the underlying spatiotemporal data management and 3D scene organization and management modules, it realizes the digitization of entities such as natural environment, infrastructure, physical equipment, and dynamic targets, and provides digital twin construction mechanisms and presentation and interaction interfaces for various entities.

[0089] As demonstrated by the above embodiments, this invention, in addition to achieving basic game engine rendering and high data throughput capabilities, also eliminates the hardware requirement of a GPU server, significantly reducing project costs. This has a substantial effect on cost reduction and efficiency improvement for enterprises. This invention is the first of its kind both domestically and internationally. It represents a deep integration based on previous simple fusion, achieving a significant improvement in stability, speed, and rendering quality. This invention focuses on achieving a high degree of unity between low cost and high performance in engine implementation. It effectively resolves the contradiction between pursuing low investment and high performance across various rendering engines. Historically, the rendering performance of single WebGL-based GIS systems has not been particularly well-regarded. This invention, by integrating a game engine into a GIS system, significantly improves the rendering effect.

[0090] Example 2: This invention provides a method for building a fusion engine of Cesium and ThreeJS, comprising:

[0091] S1 loads the underlying WebGL interface, providing a graphics rendering working environment for GIS engine renderers and game-level engine renderers;

[0092] S2 loads the upper-level spatiotemporal data layer located in the WebGL interface. Utilizing the Cesium GIS engine, it completes the loading, scheduling, and management of terrain tiles, satellite imagery, and vector data; spatial feature identification and picking mechanisms; spatial feature query mechanisms; and time-series data visualization and analysis processing. For example, time-series data visualization and analysis processing includes: real-time processing of variable features that change over time, in addition to spatial features, and sending them to the rendering pipeline for rendering output.

[0093] S3 loads the 3D scene management layer located above the spatiotemporal data layer. It utilizes the lightweight game-grade engine ThreeJS to complete 3D graphics, 3D model rendering and instantiation rendering, as well as the management of post-production special effects.

[0094] S4 loads the digital twin layer located above the 3D scene management layer, completing the digitization of the natural environment, infrastructure, physical equipment, and dynamic target entities, and providing interaction interfaces for various entities.

[0095] For example, in step S2, terrain tile loading uses Cesium's EllipsoidTerrainProvider and CesiumTerrainProvider classes, and is executed after CesiumTerrainProvider optimization:

[0096] (1) Set the maximum range of the terrain rectangle; (2) Set the terrain data source viewer.terrainProvider; (3) Request terrain tiles in the rendering loop; (4) Calculate the rectangular range of the tile to be requested, tileRectangle; (5) Determine whether the terrain range rectangle and the tile range tileRectangle intersect; if they intersect, send a request and complete the loading of terrain tiles; if they do not intersect, do not send a request and return undefined, and the current tile elevation is 0.

[0097] In step S2, satellite image loading includes image tile loading. The ImageryProvider interface of Cesium is used to complete the Cesium image tile data source based on the OGC specifications of WMS, TMS, and WMTS, and the Cesium image tile data source class is further encapsulated by extending the image tile layer.

[0098] Vector data loading includes: using a two-dimensional vector loading method to complete dynamic vector tiling and drawing by tile range through the image tile interface; using a three-dimensional vector loading method, which is divided into three-dimensional annotation and three-dimensional white model methods according to feature type; the three-dimensional white model method is to stretch vector surface features into a three-dimensional white model and display it separately using three-dimensional graphics rendering; three-dimensional annotation point data and attribute text are displayed on a three-dimensional globe in the form of three-dimensional solid text, with the text always perpendicular to the screen.

[0099] In step S2, the 3D scene management layer synchronizes the camera and unifies the rendering loop, so that the 3D scene based on ThreeJS and the GIS scene based on Cesium are integrated. The 3D graphics are composed of geometry and materials. The geometry is composed of vertex attributes and indexes. The 3D model is composed of one or more 3D graphics. Multiple graphics are merged into a group. A 3D graphics group is a 3D model node. The 3D model nodes are further grouped to obtain new 3D model nodes.

[0100] Instantiated rendering includes: drawing multiple instances of the same 3D graphic in a single rendering; drawing the same 3D graphic to different positions in 3D space after translation, rotation, and scaling transformations; after instantiation rendering, additional instantiation animation is required to independently control the model animation of different instances; post-processing effects management is completed based on Cesium's post-processing effects library.

[0101] In step S4, infrastructure digitization includes static infrastructure and dynamic infrastructure; static infrastructure, including basic roads, is a typical example of static infrastructure. Dynamic infrastructure includes facilities along roads whose shape, appearance, or state is synchronized with objects in the real world.

[0102] The basic road digitization includes basic road loading, constructing a road state model, loading a basic road elevation model that combines a mathematical model and 3D graphics created based on the road boundary line, and providing road elevation sampling methods and road boundary query methods;

[0103] The digitization of facilities along the route includes: using a single 3D model to represent the same type of equipment, and rendering it using a 3D model instantiation rendering interface; the status of facilities and equipment along the route is represented by instance transformation parameters, instantiation animation, and post-processing highlighting methods; instance transformation parameters include changing the size, rotation attitude, and small-range offset states of the equipment; instantiation animation represents the operating status of the equipment; post-processing highlighting methods include overlaying colors to change the appearance of the equipment;

[0104] Digitalization of the natural environment includes: water body simulation based on Cesium water surface material and ThreeJS Water class; and meteorological condition simulation based on particle effects, simulating sunny, rainy, snowy, and foggy weather phenomena.

[0105] In step S4, the digitization of the dynamic target entity includes: digitizing the dynamic target's motion trajectory by using the InstanceAminationCollection and InstanceAnimation classes and a motion trajectory management object to represent the dynamic target, obtaining the latest trajectory point coordinates from the trajectory management object frame by frame, and updating the graphic positioning parameters; and tracking the moving target by keeping the camera's field of view following the moving target's movement according to the motion angle, using the encapsulated camera tracking control CameraTrackController class to track the target, obtaining the moving target's current position and rotation transformation parameters in real time, and passing them to the camera tracking control to complete the moving target tracking.

[0106] Example 3, as another specific embodiment of the present invention, provides a method for constructing a fusion engine of Cesium and ThreeJS, specifically including the following:

[0107] For example, the Cesium and ThreeJS fusion engine runtime environment provided in this embodiment of the invention includes:

[0108] 1.1 PC Environment. With the iterative upgrades of computer hardware, WebGL technology is now widely supported on PCs. However, 3D rendering is still greatly affected by hardware such as graphics card configuration and memory. In order to obtain a better experience, this invention is developed and tested based on the following PC configuration and environment, as shown in Table 1.

[0109] Table 1 Development and Testing

[0110]

[0111] 1.2 Mobile Environment. Mainstream mobile phones and tablets from major brands, including Android, iOS, and HarmonyOS, all support WebGL technology. The engine can run on most mobile devices, but performance varies significantly depending on device configuration, operating system, and browser. To achieve a better user experience, this invention was developed and tested based on the following mobile device configurations and environments, which also serve as the basis for recommending configurations to end users (see Table 2).

[0112] Table 2 Recommended Configuration for End Users

[0113]

[0114] 2. Spatial data management.

[0115] 2.1 Terrain Tile Loading. Terrain tile loading is implemented using Cesium's EllipsoidTerrainProvider and CesiumTerrainProvider classes. EllipsoidTerrainProvider is in terrain-free mode, meaning all tiles have an elevation of 0, and no data needs to be retrieved from the server. CesiumTerrainProvider is in terrain-supported mode, where terrain tiles need to be pre-generated using tools and provided as a data source from the server.

[0116] 2.1.1 Optimization of CesiumTerrainProvider. By default, CesiumTerrainProvider requires requesting global terrain tile data. When the data source does not cover the entire globe, a large number of invalid requests will be sent. Therefore, the engine needs to optimize this part. The optimized terrain loading process is as follows: (1) Set the maximum terrain range rectangle; (2) Set the terrain data source viewer.terrainProvider; (3) Request terrain tiles in the rendering loop; calculate the rectangular range tileRectangle of the tile to be requested; (4) Determine whether the terrain range rectangle and the tile range tileRectangle intersect. If they intersect, a request is sent to complete the terrain tile loading; if they do not intersect, no request is made and undefined is returned, and the current tile elevation is 0.

[0117] 2.1.2 Terrain tile loading process as follows Figure 2 As shown.

[0118] 2.2 Image Tile Loading. Image tile loading primarily utilizes the Cesium ImageryProvider interface. Cesium implements image tile data source classes conforming to OGC specifications such as WMS, TMS, and WMTS. To facilitate layer management and provide mask data for terrain clipping, this invention requires further encapsulation based on the Cesium image tile data source class, extending the image tile layer.

[0119] 2.2.1 Image tile layer.

[0120] ImageTileLayer is a general image tile layer that allows you to set key parameters such as the image tile data source, whether it is a terrain clipping mask layer, and whether it is a terrain flattening mask layer. It is used to load image tiles of OGC specifications such as WMS, TMS, and WMTS. It provides three commonly used operation methods: load, reload, and unload.

[0121] TiandituLayer is a Tianditu image tile layer that automatically configures layer names, styles, and other parameters, enabling convenient and quick creation of image tile layers for loading satellite image tile and vector tile data that conforms to domestic policies, regulations, and standards. Three subclasses are derived from this class: Satellite Imagery (TiandituImgLayer), Vector Imagery (TiandituVecLayer), and Terrain Shading Map (TiandituTerLayer).

[0122] GeoGridLayer is a geographic grid tile layer used to create latitude and longitude grids. The clipping area can be set through the clipperLayer property, and clipping can be performed using vector data.

[0123] 2.3 Loading vector data.

[0124] Vector data can be loaded in two ways: 2D and 3D. The 2D vector loading method uses an image tile interface to dynamically slice vectors and draw them according to tile ranges. The graphics interface used for drawing is canvas, and the drawing result is returned to the data source class (ImageryProvier), entering the terrain tile scheduling module to become one of the terrain tile maps, resulting in a ground-hugging effect. The 3D vector loading method can be further divided into 3D annotation and 3D white model methods according to feature type. The 3D white model method involves stretching vector polygon features into a 3D white model, which is then displayed separately using 3D graphics rendering. 3D annotation displays point data and attribute text as 3D text on a 3D globe. The text is always perpendicular to the screen and does not exhibit perspective distortion due to changes in the 3D perspective.

[0125] 2.3.1 Vector layers.

[0126] Label3dLayer is a 3D annotation layer class used to load vector point data. It sets the annotation style (ILabel3dStyle) through style filtering methods, including parameters such as text attributes, point style, and text style. Vector2dLayer is a 2D vector layer used to create ground-hugging vector tile layers, supporting points, lines, and polygons. Vector3dLayer is a 3D vector layer used to create vector white model layers, allowing setting parameters such as stretch attributes, stretch coefficients, materials, and whether UV values ​​are rounded. It supports vector polygon features.

[0127] 2.4 Local terrain filling and excavation.

[0128] 2.4.1 Function: Based on the mask image tile layer, the terrain within a specified area is cropped or flattened to achieve terrain excavation. Areas with a mask layer opacity greater than 0 represent the interior, while areas with 0 opacity represent the exterior. After terrain excavation, a pre-made 3D model of the terrain at a higher longitude or other infrastructure is loaded onto the Earth to fill the terrain. For interactive processing of the terrain excavation and filling areas, when clicking on points in the 3D scene, the obtained height should be the actual height of the filled model, not the height of the terrain before cropping.

[0129] 2.4.2 Flowchart of local terrain filling and cutting as follows Figure 3 As shown.

[0130] 2.5 Spatial Element Management. A spatial element is a data record consisting of a two- or three-dimensional graphic or spatial extent with certain characteristics, along with the associated business attributes. The specific shape, extent, and practical meaning of a spatial element are primarily defined by the business application system. The digital twin engine constructs a spatial element query mechanism from the ground up, along with its applicable basic data structures and function interfaces, providing basic methods for defining and querying spatial elements. Spatial element queries, based on the spatial dimension of the graphic and extent of the spatial element, can be divided into two-dimensional element queries and three-dimensional element queries.

[0131] 2.5.1 Two-dimensional element query.

[0132] Two-dimensional feature query refers to the process of returning the two-dimensional features and their attribute information at the mouse position when the mouse clicks on an image tile or vector tile layer. This is implemented through Cesium's data source interface, ImageryProvider, and conforms to OGC specifications. The Cesium.ImageryProvider feature query method interface is as follows: `pickFeatures(x,y,level,longitude,latitude)`. The engine's extended data source class implements this method, providing two-dimensional feature query functionality. Inputs `x`, `y`, and `level` are the tile numbers where the mouse picks the target point, and `longitude` and `latitude` are the latitude and longitude of the target point. The return result is an asynchronous Promise, and the result of this asynchronous process is a `Cesium.ImageryLayerFeatureInfo` array, which is the list of query result features.

[0133] 2.5.2 3D Feature Query.

[0134] 3D feature query refers to the process of returning 3D graphics, 3D model parts, and other objects and their associated attribute information when the mouse clicks on a 3D layer. The engine provides two 3D feature query mechanisms: a GPU-based query method and a ray-based query method.

[0135] (1) A query method based on GPU picking requires all 3D graphics to create a unique picking ID and be marked with a unique color value. When picking, the color of the picking ID is used for rendering, and the 3D feature and its attribute information at the mouse position can be retrieved by matching the picking ID. This method is suitable for scenarios where a 3D graphic stores multiple features.

[0136] (2) Raycast-based query method: This method requires the 3D graphics to implement raycasting. When querying, a ray is constructed using the mouse position and camera parameters, and this ray is used to perform an intersection operation with the 3D geometry. If an intersection occurs, the intersection point information is returned (including the intersection point coordinates, the 3D geometry to which it belongs, the triangular face it belongs to, and the distance from the intersection point to the ray's origin). Raycasting may return multiple intersection points; by sorting and filtering these intersection points, the 3D feature and its attribute information can be obtained. This method satisfies the scenario where a 3D graphic stores only one 3D feature.

[0137] 2.5.3 Visualization of spatial elements.

[0138] Two-dimensional feature visualization utilizes terrain, imagery, and vector graphics to highlight and emphasize the spatial extent of two-dimensional features using ground-hugging polygons. Three-dimensional feature visualization employs post-processing effects to highlight 3D features retrieved via GPU; for 3D features retrieved via raycasting, appearance attributes such as material color and texture are altered for emphasis.

[0139] 3. 3D Scene Management. 3D scene management is implemented based on ThreeJS. It leverages the node-based scene organization advantages of ThreeJS, and through camera synchronization and unified rendering loop, it integrates the ThreeJS-based 3D scene with the Cesium-based GIS scene to jointly drive the operation of the digital twin system.

[0140] 3.1 Camera Synchronization. A 3D scene spatial reference system is established, with the scene center geographic coordinates as the origin. North, east, and directions perpendicular to the Earth's ellipsoid upwards are defined as positive directions. A local reference system (ENU) is established, providing a transformation matrix from the local coordinates of the entire scene to the GIS spatial world coordinates. Synchronization between the 3D scene camera and the GIS scene camera is achieved based on this transformation matrix. Detailed interface definitions are as follows:

[0141] / * Local reference frame (ENU) class, consisting of a matrix and its inverse matrix * /

[0142] class ReferenceFrame{

[0143] matrix: Cesium.Matrix4; / / Transformation matrix from local coordinates to world coordinates

[0144] inverseMatrix: Cesium.Matrix4; / / Transformation matrix from world coordinates to local coordinates

[0145] }

[0146] The engine implements the camera conversion utility class CameraUtils, which provides a set of utility functions for converting between ThreeJS cameras and Cesium cameras:

[0147] toPerspectiveCamera3js, converting Cesium's perspective camera to ThreeJS's perspective camera;

[0148] toOrthographicCamera3js, Cesium's parallel camera to ThreeJS's parallel camera;

[0149] From PerspectiveCamera3js, converting a ThreeJS perspective camera to a Cesium perspective camera;

[0150] from OrthographicCamera3js, a parallel camera from ThreeJS to Cesium.

[0151] The detailed interface is as follows:

[0152] class CameraUtils {

[0153] / * Convert Cesium's perspective camera to ThreeJS's perspective camera * /

[0154] static toPerspectiveCamera3js(

[0155] camera: Cesium.Camera, / / Enter Cesium's perspective camera

[0156] camera3js?: THREE.PerspectiveCamera, / / Outputs a ThreeJS perspective camera

[0157] referenceFrame?: ReferenceFrame / / local reference system (ENU)

[0158] ): THREE.PerspectiveCamera; / / Returns the ThreeJS perspective camera

[0159] / * Converting Cesium's parallel camera to a ThreeJS parallel camera * /

[0160] static toOrthographicCamera3js(

[0161] camera: Cesium.Camera, / / Enter Cesium's parallel camera

[0162] camera3js?: THREE.OrthographicCamera, / / Outputs a parallel camera in ThreeJS.

[0163] referenceFrame?: ReferenceFrame / / local reference system (ENU)

[0164] ): THREE.OrthographicCamera; Returns the parallel camera in ThreeJS.

[0165] / * Convert ThreeJS's perspective camera to Cesium's perspective camera * /

[0166] static fromPerspectiveCamera3js(

[0167] camera3js: THREE.PerspectiveCamera, / / Input ThreeJS perspective camera

[0168] scene: Cesium.Scene, / / Cesium scene

[0169] referenceFrame?: ReferenceFrame, / / local reference system (ENU)

[0170] Camera?: Cesium.Camera / / Outputs a Cesium perspective camera

[0171] ): Cesium.Camera; / / Returns the perspective camera of Cesium.

[0172] / * Parallel camera conversion from ThreeJS to Cesium * /

[0173] static fromOrthographicCamera3js(

[0174] camera3js: THREE.OrthographicCamera, / / Input a parallel camera in ThreeJS

[0175] scene: Cesium.Scene, / / Cesium scene

[0176] referenceFrame?: ReferenceFrame, / / local reference system (ENU)

[0177] camera?: Cesium.Camera / / Outputs a parallel camera for Cesium.

[0178] ): Cesium.Camera; / / Returns the parallel camera of Cesium.

[0179] }

[0180] 3.2 3D graphics rendering.

[0181] 3.2.1 3D Graphics Classification and Creation. Basic 3D graphics include points (Points class), lines (Line class), and meshes (Mesh class). Points and lines are typically used to represent abstract concepts such as locations, boundaries, and routes, which do not have corresponding actual objects in reality. Meshes are typically used to represent real-world objects with actual shapes and appearances, such as roads and surveillance equipment; they can also be used to represent abstract concepts such as electronic fences. In a 3D scene, 3D graphics inherit from the 3D object class (Object3D). The 3D object class encapsulates a series of attributes and methods needed for node-based scene organization, such as matrix transformations, node addition, and removal. 3D graphics consist of geometry and materials. Geometry consists of vertex attributes and indices. The specific creation process is as follows: Figure 4 The 3D graphic creation diagram shown.

[0182] 3.2.2 such as Figure 5 The 3D graphics rendering process is shown below.

[0183] 3.3 3D model rendering.

[0184] 3.3.1 3D Model Structure. A 3D model consists of one or more 3D graphics. Multiple graphics can be merged into a group, and a group of 3D graphics is called a model node. Model nodes can be further grouped to obtain new model nodes, and so on, defining groupings in a nested manner to obtain a tree-like 3D model data structure. A 3D model has one and only one root node, such as... Figure 6 The 3D model structure diagram is shown below.

[0185] Accordingly, 3D models in formats such as CHECC, FBX, and GLTF can be parsed into instances of core ThreeJS classes such as Object3D, Mesh, Points, and Line, and the rendering of the 3D model can be converted into the rendering of 3D graphics within the 3D model.

[0186] 3.3.2 Constructing a 3D model parsing interface.

[0187] 3.3.3 such as Figure 7 The rendering process of the 3D model is shown.

[0188] 3.4 Instantiation rendering.

[0189] 3.4.1 Function: In the real world, there are a large number of objects with highly similar or even almost identical shapes and appearances, such as streetlights, bridge piers, and highway guardrail posts. Rendering a large number of similar or identical 3D graphics in a digital twin system drastically increases the computation time and resources required, leading to a rapid decline in rendering performance.

[0190] Instantiated rendering refers to drawing multiple instances of the same 3D graphic in a single rendering process. This involves transforming the same 3D graphic through translation, rotation, scaling, and other methods, and then drawing it to different positions in 3D space, so that the scene "looks" the same as if multiple 3D graphics had been rendered.

[0191] Key technologies for instantiated rendering:

[0192] (1) Data sharing. Multiple rendering instances share the vertex, index, material, and texture map data of a 3D graphics, and each of the multiple rendering instances can independently represent a digital twin;

[0193] (2) Shared rendering batches. Multiple rendering instances are completed in the same drawing command, and only one rendering batch is used in the rendering loop.

[0194] By employing these two key technologies, we can avoid the repeated storage of 3D graphics data and the repeated transfer of 3D graphics data from the CPU to the GPU, thereby reducing memory usage and the time required to render 3D graphics per frame, saving resources, and improving rendering performance.

[0195] 3.4.2 Interface Construction. 3D graphics instances primarily maintain two parameters: the model transformation matrix (modelMatrix) and the GPU pick ID (pickId). The model transformation matrix contains three transformation parameters: translation, rotation, and scaling of the instance; the GPU pick ID serves as the underlying unique identifier for 3D features and is used for 3D feature lookup.

[0196] A model instance is an instantiation parameter shared by all 3D graphics in a 3D model, enabling the overall instantiation of the model. That is, the entire model represents an entity, and a model instance represents a digital twin. The model instance further breaks down the model transformation matrix into three positioning parameters maintained separately: translation, rotation, and scale. To facilitate geospatial positioning, a geographic location attribute (position) is set.

[0197] 3.5 Instantiation Animation. After the 3D model is instantiated, all instances play the animation together. In specific requirements, this invention aims to ensure that the animations of different instances are independently controlled; for example, wind turbines in different locations may rotate in different directions. To handle this requirement, an instance animation attribute is added to the model instances. The detailed interface for instance animation is as follows:

[0198] class ModelInstanceAnimation {

[0199] constructor(name: string); / / name is the name of the bound model node

[0200] readonly matrixWorld: THREE.Matrix4; / / Transformation matrix synthesized using transformation parameters

[0201] readonly node: THREE.Object3D; / / Animation binding node

[0202] readonly position: THREE.Vector3; / / translation

[0203] readonly rotation: THREE.Euler; / / Rotation (Euler angles)

[0204] readonly scale: THREE.Vector3; / / Scaling factor

[0205] readonly quaternion: THREE.Quaternion; / / Quaternion rotation

[0206] readonly matrixWorldNeedsUpdate: boolean; / / Notify the model instance to update the transformation matrix

[0207] update(frameState:Cesium.FrameState): void; / / Update animation

[0208] }

[0209] 3.6 Post-processing effects: The post-processing effects are implemented based on the Cesium post-processing effects library. The Cesium official documentation was consulted during coding.

[0210] 4. Digitalization of infrastructure.

[0211] Infrastructure digitization is mainly divided into two categories: static and dynamic. Static infrastructure refers to facilities in a digital twin system whose shape, appearance, and state are relatively fixed, do not change, or change very infrequently; basic roads are a typical example of static infrastructure. Dynamic infrastructure refers to facilities whose shape, appearance, or state frequently needs to be synchronized with objects in the real world; roadside facilities are a typical example of dynamic infrastructure. For dynamic facilities whose positions frequently change, synchronized trajectories and target tracking are required; this functionality is implemented separately in the dynamic target digitization module.

[0212] 4.1 Digitalization of basic roads.

[0213] 4.1.1 Basic Road Loading. Basic road data loading includes loading the basic road 3D model and loading feature line data such as road boundary lines, center lines, lane lines, and station numbers. The basic road loading process is as follows: Figure 8 .

[0214] 4.1.2 Construct a road state model, such as Figure 9 As shown.

[0215] 4.1.3 Basic Road Elevation Model. The basic road elevation model is a combination of a mathematical model created based on road boundary lines and 3D graphics, providing an efficient method for road elevation sampling and road boundary querying. The 3D graphics do not need to be displayed; they are only used to perform mathematical calculations in place of a detailed visual 3D model. Detailed interfaces are as follows.

[0216] / * Road parameters * /

[0217] interface RoadParams {

[0218] name: string / / Road name

[0219] origin: Cesium.Cartesian3 / / Origin coordinates

[0220] edges: Cesium.Cartesian3[][] / / Boundary lines

[0221] center: Cesium.Cartesian3[] / / Center line

[0222] }

[0223] / * Road elevation model * /

[0224] export default class RoadModel {

[0225] roadList: RoadParams[] / / List of roads

[0226] root: THREE.Object3D / / Root node of the road elevation model

[0227] rectangle: Cesium.Rectangle / / Boundaries of the road

[0228] / / Determine if a specified point is within the boundaries of the road.

[0229] bboxContains(point: Cesium.Cartographic | number[]): Boolean

[0230] / / Elevation sampling, calculates the elevation of a given point projected onto the road surface.

[0231] sampleHeight(positions: Cesium.Cartographic[]): void

[0232] / / Calculate the point closest to the road centerline from a given point

[0233] nearestPoint(srcPosition: Cesium.Cartesian3): Cesium.Cartesian3

[0234] }

[0235] 4.2 Digitalization of Facilities Along the Route. Given the limited variety and large quantity of facilities and equipment along the route, a single 3D model can be used to represent the same type of equipment, rendered using a model instantiation rendering interface. The status of facilities and equipment along the route can be represented through instance transformation parameters, instantiation animations, and post-processing highlight effects. Instance transformation parameters can change the size, rotation, and small-range offset of the equipment; instantiation animations can represent the equipment's operating status; post-processing effects can overlay colors to change the appearance of the equipment, highlighting changes in appearance or a specific operating state. When representing the status of facilities and equipment through post-processing effects, group control can be performed based on the GPU-picked ID of the model instance; for example, streetlights and tunnel lights can be controlled by grouping them by road segment.

[0236] 4.2.1 Device data structure.

[0237] Equipment data is divided into equipment type and equipment information. Equipment type data stores the equipment type name, associated 3D model file, and model-related configuration parameters. The specific data structure is as follows (JSON format):

[0238] {

[0239] "modelId": string, / / model ID

[0240] "name": string, / / Model name

[0241] "eqSystem": string, / / Name of the device system / model group to which it belongs

[0242] "modelFile": string, / / URL of the model file

[0243] "translucent": boolean, / / Whether to enable translucent blending

[0244] "nodeInstancing": boolean, / / Whether to randomly select model child nodes and bind them to instances

[0245] "castShadow": boolean, / / Whether to cast a shadow

[0246] "receiveShadow": boolean, / / Whether to receive shadows

[0247] "underground": boolean, / / Whether it is an underground model

[0248] "editable": boolean, / / Whether parameters can be modified on the device deployment page.

[0249] / / Set the name of the model node to be instantiated, so that the device model can be instantiated by component.

[0250] "eqComponents": string [],

[0251] "defaultView": { / / Default view parameters for the device model.

[0252] "heading": number, / / azimuth angle

[0253] "pitch": number, / / pitch angle

[0254] "range": number / / offset distance

[0255] }

[0256] }

[0257] Device information data is typically defined by the digital twin application system. Here, only the information fields necessary for the engine to render the device are defined, such as the model ID associated with the model in the device type data, and the device model positioning parameters. The specific data structure is as follows (JSON format):

[0258] {

[0259] "modelId": string, / / Model ID, associated with the model ID in the device type data.

[0260] "eqId": string, / / Device ID

[0261] "eqName": string, / / Device name

[0262] / / Equipment station number and equipment model parameter fields, at least one of them must be provided. eqModel has the highest priority.

[0263] "eqStake": string,

[0264] / / Model positioning parameters, including model ID, position, translation, rotation, and scaling parameters, which can be stored as a string.

[0265] "eqModel": {

[0266] / / Reference geographic coordinates for model placement, used to establish the ENU reference system for calculating transformation parameters.

[0267] "position": {

[0268] "longitude": number, / / longitude, unit is degrees (°).

[0269] "latitude": number, / / longitude, in degrees (°).

[0270] "height": number, / / Altitude, in degrees (°).

[0271] },

[0272] "scale": number, / / Overall scaling factor of the model

[0273] "translation": { / / Translation, based on local coordinates}

[0274] "x": number, / / x component

[0275] "y": number, / / y component,

[0276] "z": number / / z component

[0277] },

[0278] "rotation": { / / Overall rotation angle of the model (Euler angles), all in radians (Rad)

[0279] "x": number, / / radians of rotation about the x-axis

[0280] "y": number, / / radians of rotation around the y-axis

[0281] "z": number, / / radians of rotation about the z-axis

[0282] "order": string, / / Rotation order

[0283] }

[0284] },

[0285] "eqRunState": string, / / Device running status

[0286] "eqGroup": string, / / Required field, device group

[0287] "eqSection": string, / / Optional field, representing the road segment.

[0288] "eqDirection": string, / / Optional field, driving direction

[0289] }

[0290] 4.2.2 Device Data Loading. The device data loading module, InstancingModelManager, based on the aforementioned data structure, implements the loading of device 3D models and the management of device model instances. The device data loading process is as follows: Figure 10 ;

[0291] 4.2.3 Equipment deployment process as follows Figure 11 .

[0292] 5. Digitalization of the natural environment.

[0293] 5.1 Water Simulation. There are two methods for water simulation: one based on the Cesium water surface material and the other based on the ThreeJS Water class. The Cesium water surface material provides basic water surface rendering effects, such as ripples and highlights. This method is simple to implement, does not render reflections, has high performance, and can simulate very large water surfaces, such as the global ocean. The ThreeJS Water class provides realistic water surface rendering effects, allowing selection of reflections and refraction effects. It has lower performance and is suitable for simulating small water surfaces, such as reservoirs and rivers.

[0294] 5.1.1 The process of realistic water surface simulation is as follows: Figure 12 .

[0295] 5.1.2 Realistic Water Surface Interface. Based on the characteristics of geographic space, the ThreeJS Water class is modified to implement GeoWater, enabling realistic water surfaces to be displayed as an ellipsoid of the Earth, rather than just a truncated ellipsoid. The specific interface definition is as follows.

[0296] / * Water surface structure parameters * /

[0297] interface GeoWaterOptions {

[0298] textureWidth?: number; / / Width of the reflection texture

[0299] textureHeight?: number; / / Height of the reflection texture

[0300] clipBias?: number; / / Clipping offset

[0301] alpha?: number; / / Transparency

[0302] waterNormals?: THREE.Texture; / / Water surface normal texture

[0303] sunDirection?: THREE.Vector3; / / Sunlight direction

[0304] sunColor?: THREE.Color | string | number; / / Sunlight color

[0305] waterColor?: THREE.Color | string | number; / / Basic color of the water surface

[0306] distortionScale?: number; / / Distortion coefficient of water surface ripples

[0307] height?: number; / / Water surface elevation

[0308] perPositionHeight?: Boolean / / Indicates whether each vertex of the water surface geometry has its own height.

[0309] }

[0310] / * Geographically based water surface grid class * /

[0311] export class GeoWater extends THREE.Mesh {

[0312] constructor(

[0313] geometry: THREE.BufferGeometry, / / Water surface geometry

[0314] options: GeoWaterOptions / / Water surface parameters );

[0316] height: number; / / Water surface elevation

[0317] }

[0318] 5.2 Meteorological condition simulation.

[0319] 5.2.1 Simulation Process. The engine provides particle-effect-based weather condition simulation, capable of simulating weather phenomena such as sunny, rainy, snowy, and foggy conditions. Simultaneously, it automatically adjusts scene lighting and sky background parameters for each weather phenomenon to enhance the atmosphere of the simulation. The basic weather simulation process is as follows: Figure 13 .

[0320] 5.2.2 Meteorological effects interface.

[0321] class WeatherEffect {

[0322] snow(): void / / Snowing

[0323] rain(): void / / Rain

[0324] sunny(): void / / Sunny

[0325] fog(): void / / Dense fog

[0326] }

[0327] 6. Digitization of Dynamic Target Entities. In a digital twin scenario, dynamic targets can be represented using points, labels, icons, 3D model instances, or a combination of these representations.

[0328] 6.1 Motion Trajectory. The motion trajectory of the dynamic target is synchronized in real time via WebSocket. There may be a significant time gap between the transmission of two trajectory points, requiring the engine to automatically perform smooth interpolation. The `InstanceAminationCollection` and `InstanceAnimation` classes are responsible for motion trajectory management. They represent the graphical object of the dynamic target, obtaining the latest trajectory point coordinates from the trajectory management object frame by frame and updating the graphical positioning parameters. Detailed interfaces are as follows.

[0329] / * Animation / trajectory of a moving target instance; receives, stores, and manages the motion trajectory of an instance. * /

[0330] class InstanceAmination {

[0331] constructor(instance: ModelInstance)

[0332] instance: ModelInstance / / instance of the moving target model

[0333] track: { / / historical trajectory}

[0334] times: [],

[0335] points: [],

[0336] speeds: []

[0337] }

[0338] / / Given a point in time, calculate the current position and direction of motion of the moving target (represented by the direction toward the target).

[0339] sample(time, position: Cartesian3, target: Cartesian3): boolean

[0340] update(time): void / / Updates the position of moving targets frame by frame, providing smooth interpolation functionality.

[0341] appendTrack(time, position, speed): void / / Adds the track point to the historical track.

[0342] }

[0343] / * A collection of moving target instance animation / trajectory management objects, updating the managed objects in the collection frame by frame * /

[0344] classInstanceAminationCollection {

[0345] animations: InstanceAmination[] / / Collection of animation / track management objects

[0346] enabled: Boolean / / Whether to enable animation (real-time update of the target's position)

[0347] add(instanceAnimation: ModelInstance): InstanceAmination / / Add a new instance

[0348] remove(instanceId: string | ModelInstance): Boolean / / Remove the instance

[0349] getByInstanceId(instanceId: string): InstanceAmination / / Get instance

[0350] / / Update the trajectory of an instance

[0351] updateInstance(instanceId:string,position:Cartesian3,time:number): void

[0352] / / Each frame is automatically called internally by the system to complete the animation function.

[0353] update(frameState: Cesium.FrameState): void

[0354] }

[0355] 6.2 Target Tracking. Moving target tracking enables the camera to maintain its field of view and follow the moving target at a certain angle. The engine encapsulates the CameraTrackController class, providing the core functionality for target tracking. During target tracking, the current position, rotation, and other transformation parameters of the moving target are acquired in real time and passed to the camera tracking control to complete the tracking.

[0356] / ** Camera tracking view offset parameters * /

[0357] interface LookAtOffset {

[0358] range: number

[0359] pitch: number

[0360] heading: number

[0361] x: number

[0362] y: number

[0363] z: number

[0364] }

[0365] / ** Camera tracking control * /

[0366] export default class CameraTrackController {

[0367] constructor(camera: Cesium.Camera, / / GIS scene camera)

[0368] duration?: number, / / The time difference between two viewpoint adjustments, in seconds (s)

[0369] offset?: LookAtOffset / / Tracking view offset )

[0371] setView( / / Set the latest tracking point and its direction of motion)

[0372] position: THREE.Vec3,

[0373] target: THREE.Vec3

[0374] void

[0375] update(time: number): void / / Update tracking rotation parameters frame by frame

[0376] static lookAt( / / Adjust camera angle once)

[0377] camera: Cesium.Camera

[0378] eyePosition: THREE.Vec3,

[0379] velocity: THREE.Vec3,

[0380] params: LookAtOffset

[0381] void

[0382] static lookAtTransform( / / Single adjustment of the camera viewpoint, direction specified by the model transformation matrix)

[0383] camera: Cesium.Camera

[0384] localTransform: Cesium.Matrix4,

[0385] params: LookAtOffset

[0386] void

[0387] }

[0388] In addition to the scheduling of massive amounts of "static" data, the digital twin implementation in the transportation industry also involves an order-of-magnitude increase in "moving" objects in the scene, a higher data update frequency, finer granularity of updated components, and higher requirements for the visual effects of the user's 3D scene. Cesium's capabilities in this regard are clearly insufficient.

[0389] ThreeJS, a lightweight WebGL wrapper library, employs a scene graph rendering model and manages all elements through an Object3D hierarchical structure. Its core advantages lie in its flexible material system and rich extension ecosystem, allowing developers to finely control the rendering pipeline and achieve various effects, from particle effects to complex animations. Cesium, on the other hand, is a benchmark for geospatial 3D engines, building a complete GIS framework based on GLSL shaders. Its unique Cesium3DTileset enables efficient rendering of large-scale 3D geographic data, and its built-in ellipsoidal mathematics library supports accurate calculations in the WGS84 coordinate system. Typical applications cover geospatial fields such as digital twin cities and aerospace mission planning. This invention uses a combination of Cesium and ThreeJS to implement a Cesium-based ThreeJS renderer, implementing some ThreeJS interfaces within Cesium. By leveraging the strengths of Cesium and mitigating its weaknesses, it supports high-concurrency, large-volume geographic data loading and display, while also achieving ThreeJS-level model rendering effects.

[0390] Cesium implements a set of interfaces and rendering mechanisms similar to ThreeJS's Mesh and Material, and supports some ThreeJS objects.

[0391] As can be seen from the above embodiments, the main content implemented includes spatial data management, which includes terrain tile loading. Terrain tile loading is implemented using Cesium's EllipsoidTerrainProvider and CesiumTerrainProvider classes. EllipsoidTerrainProvider is in terrain-free mode, meaning all tiles have an elevation of 0, and no data needs to be obtained from the server. CesiumTerrainProvider is in terrain-supported mode, where terrain tiles need to be pre-generated using tools and the data source is provided by the server.

[0392] CesiumTerrainProvider optimization: By default, CesiumTerrainProvider requires requests for global terrain tile data. When the data source does not cover the entire globe, it sends a large number of invalid requests. Therefore, the engine needs to optimize this part. The optimized terrain loading process is as follows:

[0393] (1) Set the maximum terrain area rectangle;

[0394] (2) Set the terrain data source viewer.terrainProvider;

[0395] (3) Request terrain tiles in the rendering loop;

[0396] (4) Calculate the rectangular range of the tile to be requested, tileRectangle;

[0397] (5) Determine whether the terrain range rectangle and the tile range tileRectangle intersect. If they intersect, send a request to complete the terrain tile loading; if they do not intersect, do not send a request and return undefined, with all current tile elevations set to 0.

[0398] To further illustrate the effects of the embodiments of the present invention, the following experiments were conducted.

[0399] 1. Model Instantiation Processing. Model instantiation processing is based on the Checc3D Engine digital twin engine, which converts CHECC format 3D model files (file extension .checc) into instantiation files. Specifically:

[0400] Components with similar shapes and appearances, and in large quantities (such as guardrail posts and streetlights) in 3D models of transportation systems like roads and tunnels, are instantiated and stored. These can then be instantiated and rendered using Checc3D Engine, reducing model file size, minimizing rendering batches, and improving rendering performance. Figure 14 Image showing the instantiation effect of the 3D model (all guardrail posts are rendered using only one batch).

[0401] Experimental results comparison: The comparison results of model information before and after processing show that after instantiation, the model file size decreased from 604MB to 218MB; the number of rendering batches decreased from 31611 to 451, and the 451 rendering batches included 71 instantiation rendering batches.

[0402] To verify the effect of the instantiation process, Checc3D Engine was used to load two model files before and after the instantiation process, and the rendering frame rates of the two were compared. Figure 15Performance screenshots before rendering, such as Figure 16 Post-processing rendering performance screenshots Figure 15 , Figure 16 The red box in the middle represents the real-time rendering frame rate (unit: FPS, frames per second); it can be seen that the present invention effectively improves rendering performance and the instantiation process is completed.

[0403] 2. Terrain Fusion Experiment. The model and terrain fusion process is based on the digital twin engine Checc3D Engine and the Web 3D GIS framework CesiumJS. It reconstructs the terrain within a given vector area using a Node.js environment, and performs flattening and clipping operations on the reconstructed terrain using high-precision road and tunnel 3D models, solving the problem of high-precision road and tunnel 3D models being occluded by terrain in digital twin scenarios. For example... Figure 17 High-precision road model image obscured by terrain; Figure 18 A high-precision model of a tunnel entrance / exit obscured by terrain.

[0404] Use Checc3D Engine to load and display the BIM model and the integrated model, and verify the integration effect, such as... Figure 19 The effect before fusion processing is shown in the image. Figure 20 The result after merging is shown in the image.

[0405] 3. Model Conversion. The conversion of the design terrain model to DEM is based on the digital twin engine Checc3D Engine and the Web 3D GIS framework CesiumJS. It realizes the conversion of high-precision design terrain 3D model files into DEM (Digital Elevation Model) data files in the Node.js environment, so as to further produce terrain tile data.

[0406] like Figure 21 In the example of converting a terrain model to a DEM, a terrain rendering is designed, such as... Figure 22 In the example of designing a terrain model to DEM conversion application, a low-precision terrain rendering is shown, such as... Figure 23 Example of terrain model to DEM conversion application: fusion of the converted DEM with low-precision terrain.

[0407] The input is a high-precision design terrain model file, supporting FBX format and Checc3D Engine's proprietary CHECC format. The output format is ENVI, and terrain tiles can be produced using GDAL-based tiling tools.

[0408] 4. Management and Control Platform Application. Through this integrated engine, the management and control system realizes seven modules: [Operational Indicators], [Environmental Data], [Congestion Index and Trip Index], [Traffic Volume Between Road Sections], [Percentage of Congested Mileage in Road Sections], [Monitoring Events], and [Traffic Weather Warnings]. It can monitor road conditions and data from various aspects such as weather, traffic conditions, and event messages.

[0409] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any modifications, equivalent substitutions and improvements made by those skilled in the art within the scope of the technology disclosed in the present invention and within the spirit and principles of the present invention should be covered within the scope of protection of the present invention.

Claims

1. A fusion system of Cesium and ThreeJS, characterized in that, The system includes: The underlying WebGL interface provides a graphics rendering working environment for GIS engine renderers and game-level engine renderers; The spatiotemporal data layer, located above the WebGL interface and based on the GIS engine Cesium, handles the loading, scheduling, and management of terrain tiles, satellite imagery, and vector data; spatial feature identification and picking mechanisms; spatial feature query mechanisms; and time-series data visualization and analysis. Based on the high-precision, high-performance GIS engine Cesium, the spatiotemporal data layer enables the loading, scheduling, and management of massive amounts of terrain, satellite imagery, and vector data; spatial feature identification and picking mechanisms; spatial feature query mechanisms; and time-series data visualization and analysis. The spatiotemporal data layer serves as the spatial foundation of the entire digital twin system, providing the mathematical libraries, geometric libraries, and algorithm libraries required by the geographic information system. The 3D scene management layer, located above the spatiotemporal data layer, is based on the lightweight game-grade engine ThreeJS. It manages 3D graphics, 3D model rendering and instantiation rendering, as well as post-production effects. The 3D scene management layer, based on the lightweight game-grade engine ThreeJS, implements basic 3D graphics, 3D model rendering and instantiation rendering, overlay of 3D scenes with GIS scenes, synchronization of rendering cameras between the two scenes, and organization and management of 3D objects. Specifically, the 3D scene uses a scene node tree data structure for organization and management. All 3D objects have precise access to specific node transformation parameters. For renderable 3D objects, they have access to specific geometry and materials, and vertex positions, colors, node positions, and material-related attributes can be modified as needed. Furthermore, 3D scene management also includes post-production effects management, encapsulating post-production effects interfaces based on the underlying renderer, providing post-processing effects such as lighting, strokes, anti-aliasing, and ambient occlusion. The digital twin layer, located above the 3D scene management layer, is used to digitize the natural environment, infrastructure, physical equipment, and dynamic target entities, and provides interaction interfaces for various entities. The digital twin layer is the top layer of the engine and the layer closest to industry applications and user interfaces. Based on the underlying spatiotemporal data management and 3D scene organization and management modules, it realizes the digitization of the natural environment, infrastructure, physical equipment, and dynamic targets, and provides digital twin construction mechanisms and presentation and interaction interfaces for various entities.

2. The Cesium and ThreeJS fusion system according to claim 1, characterized in that, In the WebGL interface, the GIS engine renderer and the game-level engine renderer encapsulate vertices, indexes, textures, rendering states, shaders, and drawing instructions for the spatiotemporal data layer and the 3D scene management layer, respectively, providing spatiotemporal data processing and graphics rendering.

3. The Cesium and ThreeJS fusion system according to claim 2, characterized in that, The spatiotemporal data layer is used to provide the mathematical libraries, geometric libraries, and algorithm libraries required by the geographic information system.

4. The Cesium and ThreeJS fusion system according to claim 2, characterized in that, In the 3D scene management layer, the 3D scene is overlaid with the GIS scene, and the rendering cameras of the 3D scene and the GIS scene are synchronized. The 3D scene is organized and managed using a scene node tree data structure. All 3D objects can access specific node transformation parameters. For rendered 3D objects, specific geometry and materials can be accessed, and vertex positions, colors, node positions and material-related attributes can be modified as needed.

5. A method for constructing a fusion system of Cesium and ThreeJS, characterized in that, This construction method is used to build a fusion system of Cesium and ThreeJS as described in any one of claims 1-4, and the construction method includes the following steps: S1 loads the underlying WebGL interface, providing a graphics rendering working environment for GIS engine renderers and game-level engine renderers; S2 loads the spatiotemporal data layer located above the WebGL interface. Using the Cesium GIS engine, it completes the loading, scheduling, and management of terrain tiles, satellite imagery, and vector data; spatial feature identification and picking mechanisms; spatial feature query mechanisms; and time series data visualization analysis and processing. S3 loads the 3D scene management layer located above the spatiotemporal data layer, and uses the lightweight game-grade engine ThreeJS to complete the rendering and instantiation of 3D graphics and 3D models, as well as the management of post-production effects. S4 loads the digital twin layer located above the 3D scene management layer, completes the digitization of the natural environment, infrastructure, physical equipment, and dynamic target entities, and provides interactive interfaces for various entities; In step S2, the loading of terrain tiles uses Cesium's EllipsoidTerrainProvider and CesiumTerrainProvider classes. After optimizing CesiumTerrainProvider, the following steps are performed. (1) Set the maximum terrain area rectangle; (2) Set the terrain data source viewer.terrainProvider; (3) Request terrain tiles in the rendering loop; (4) Calculate the rectangular range of the tile to be requested, tileRectangle; (5) Determine whether the terrain range rectangle and the tile range tileRectangle intersect; if they intersect, send a request to complete the terrain tile loading; if they do not intersect, do not send a request and return undefined, and the current tile elevation is 0. In step S2, the loading of satellite imagery includes image tile loading. The ImageryProvider interface of Cesium is used to complete the Cesium image tile data source based on the OGC specifications of WMS, TMS, and WMTS, and the Cesium image tile data source class is encapsulated by extending the image tile layer. The loading of vector data includes: using a two-dimensional vector loading method to complete dynamic vector tiling and drawing by tile range through the image tile interface; using a three-dimensional vector loading method, which is divided into three-dimensional annotation and three-dimensional white model methods according to feature type; the three-dimensional white model method is to stretch vector surface features into a three-dimensional white model and display it separately using three-dimensional graphics rendering; the three-dimensional annotation point data and attribute text are displayed on a three-dimensional globe in the form of three-dimensional solid text, with the text always perpendicular to the screen.

6. The method for constructing a Cesium and ThreeJS integrated system according to claim 5, characterized in that, In step S2, the 3D scene management layer synchronizes the camera and unifies the rendering loop, so that the ThreeJS-based 3D scene and the Cesium-based GIS scene are integrated. 3D graphics consist of geometry and materials, and geometry consists of vertex attributes and indices; A 3D model consists of one or more 3D graphics. Multiple graphics are merged into a group, and a 3D graphic group is a 3D model node. 3D model nodes are further grouped to obtain new 3D model nodes. Instantiated rendering includes: drawing multiple instances of the same 3D graphic in a single rendering, and drawing the same 3D graphic to different positions in three-dimensional space after translation, rotation, and scaling transformations; After instantiation and rendering, it is necessary to add instantiation animation to independently control the model animation for different instances; The management of post-production effects is based on Cesium's post-processing effects library.

7. The method for constructing a Cesium and ThreeJS integrated system according to claim 5, characterized in that, In step S4, the digitization of infrastructure includes: static infrastructure and dynamic infrastructure; static infrastructure includes the static infrastructure of basic roads; dynamic infrastructure includes facilities along roads whose shape, appearance or state is synchronized with objects in the real world. Basic road digitization includes loading basic roads, constructing a road state model, loading a basic road elevation model that combines a mathematical model created based on road boundary lines and 3D graphics, and providing road elevation sampling methods and road boundary query methods. The digitization of facilities along the route includes: using a single 3D model to represent the same type of equipment, and rendering it using a 3D model instantiation rendering interface; the status of facilities and equipment along the route is represented by instance transformation parameters, instantiation animation, and post-processing highlighting methods; instance transformation parameters include changing the size, rotation attitude, and small-range offset status of the equipment; instantiation animation represents the operating status of the equipment; post-processing highlighting methods include overlaying colors to change the appearance of the equipment; The digitization of the natural environment includes: Water simulation based on Cesium water surface material and ThreeJS Water class; Meteorological condition simulation based on particle effects, simulating sunny, rainy, snowy, and foggy weather phenomena.

8. The method for constructing a Cesium and ThreeJS integrated system according to claim 5, characterized in that, In step S4, the digitization of the dynamic target entity includes: The motion trajectory of dynamic targets is digitized. The InstanceAminationCollection and InstanceAnimation classes and the motion trajectory management represent the graphical objects of dynamic targets. The latest trajectory point coordinates are obtained from the trajectory management object frame by frame, and the graphical positioning parameters are updated. Moving target tracking: The camera's field of view follows the moving target according to the motion angle. The camera tracking control, CameraTrackController, is used to track the target. The current position and rotation transformation parameters of the moving target are obtained in real time and passed to the camera tracking control to complete the moving target tracking.

Images