A visualization system and method for earthquake disaster simulation of urban building complexes

Abstract

The present application relates to the technical field of urban earthquake disaster simulation and provides a visualization system and method for earthquake disaster simulation of urban building complexes. The system includes: an offline data preprocessing and block organization module and a block dynamic data management and scheduling module; a GPU accelerated rendering module, which is used to assign unique identifiers to vertices through global floor index mapping, and finally submit the merged model to the GPU, and collaborate with displacement textures and custom shaders to achieve real-time rendering of building forms; a GPU parallel displacement animation module, which is deeply coupled to the GPU rendering pipeline and is used to solve vertex displacement and color values ​​in real time and inject them into the rendering pipeline; an efficient interaction module, which dynamically updates label content and coordinates to achieve three-dimensional interaction. By encoding massive time-series displacement data into textures and using GPU vertex shaders for parallel calculations, the present application achieves real-time, smooth animation simulation of the earthquake response of all buildings, solving the performance bottleneck of traditional CPU calculation methods.

Description

Technical Field

[0001] The present application relates to the technical field of urban earthquake disaster simulation, and in particular to a visualization system and method for earthquake disaster simulation of urban building complexes. Background Art

[0002] Existing 3D visualization technologies or geographic information systems generally have the following technical bottlenecks when processing ultra-large-scale urban models:

[0003] Rendering and computational bottlenecks. The traditional 3D visualization rendering pipeline follows an object-by-object processing model: for each building in the scene, the CPU not only calculates its dynamic state in each frame (such as displacement and deformation caused by earthquakes), but also generates and submits a separate rendering instruction to the GPU. When the number of buildings reaches hundreds of thousands or even millions, the drawbacks of this model are greatly magnified. The massive amount of frame-by-frame state calculations and the sheer volume of instruction submissions exhausts processor resources, making it impossible to meet real-time rendering requirements, ultimately resulting in severe image lag.

[0004] Memory capacity limitations. Loading all the geometric model data and earthquake response data for a large-scale city into memory or video memory at once would consume enormous system resources. For standard computers and even professional workstations, this would often lead to memory overflow, causing the system to crash or even become inoperable.

[0005] Inefficient interaction. Quickly and accurately picking (i.e., selecting with a mouse click) a specific building within a massive building model and obtaining detailed disaster response information is a technical challenge. Traditional methods of picking by traversing each building individually or using ray tracing are extremely slow when faced with a large number of models, severely impacting the user experience. Summary of the Invention

[0006] In order to help solve the above technical problems, the present application provides a visualization system and method for earthquake disaster simulation of urban building complexes.

[0007] In a first aspect, the present application provides a visualization system for earthquake disaster simulation of urban building complexes, which adopts the following technical solutions:

[0008] A visualization system for simulating earthquake disasters in urban building complexes, wherein the system comprises:

[0009] The offline data preprocessing and block organization module is used to receive raw GIS data and earthquake response data, build a spatial block data structure after cleaning and conversion, generate JSON data blocks containing building geometry information and multi-channel displacement textures, and finally output a metadata file containing data block URL mapping;

[0010] The block dynamic data management and scheduling module uses dual boundary control and cone clipping algorithms based on the user's viewpoint to dynamically load or unload JSON data blocks generated by the offline data preprocessing and block organization modules. It manages network requests through concurrent control queues and stores unloaded data in the LRU cache.

[0011] A GPU-accelerated rendering module is configured to receive the data blocks output by the offline data preprocessing and block organization module, perform geometry merging to generate a single buffered geometry, assign unique identifiers to vertices through a global floor index map, and finally submit the merged model to the GPU to achieve real-time rendering of the building form in collaboration with displacement textures and custom shaders;

[0012] The GPU parallel displacement animation module is deeply coupled to the GPU rendering pipeline. It is used to parallel sample the displacement texture using the vertex global floor index, calculate the vertex displacement and color value in real time, and inject them into the rendering pipeline.

[0013] An efficient interaction module is used to implement ray tracing to solve building instance IDs by instantiating and picking grids, obtain metadata based on pre-built building data mapping tables, maintain the tag pool using DOM reuse technology, and dynamically update tag content and coordinates to achieve 3D interaction.

[0014] Preferably, the GIS data includes building outlines and height information, the JSON file includes at least block indexes, block boundary coordinates and a building list, and the metadata file includes at least a data block URL list and a mapping relationship between scene IDs and displacement texture URLs.

[0015] Preferably, the dual boundary control mechanism includes using differentiated boundary thresholds to construct a loading and unloading judgment system, triggering preloading when the data block expansion bounding box enters the inner boundary, and performing an unloading operation when it completely moves out of the outer boundary, so as to avoid frequent IO operations caused by slight movement of the viewpoint.

[0016] Preferably, the viewing cone clipping algorithm includes constructing a three-dimensional viewing cone based on the camera viewpoint, accurately determining the intersection relationship between the data block and the visible area through spatial geometric calculation, and loading or maintaining the data blocks within the viewing cone.

[0017] In a second aspect, the present application provides a lightweight visualization method for earthquake disaster simulation of urban building complexes based on the system described in any one of the first aspects, which adopts the following technical solutions:

[0018] A lightweight visualization method for earthquake disaster simulation of urban building complexes based on the system as described in any one of the first aspects, wherein the method comprises:

[0019] S1: The offline data preprocessing and block organization module divides the data blocks into preset grid sizes, and generates JSON metadata containing building geometry information and scenario-based displacement texture URLs; generates PNG displacement textures for each earthquake scene, and normalizes the time step displacement values ​​and inter-story displacement angle values ​​of each floor and writes them into the R / G channels respectively;

[0020] S2: Initialize the ChunkManager to load the data chunk list through the block dynamic data management and scheduling module; implement on-demand loading / unloading of data chunks by using a dual boundary control mechanism through camera position change detection; execute loading tasks using concurrent queues and optimize memory usage through LRU caching;

[0021] S3: After verifying the data block through the GPU accelerated rendering module and the GPU parallel displacement animation module, the mesh model is restored from the cache first, a globally unique index is generated for the vertex when constructing a single mesh model, a custom ShaderMaterial is configured and the displacement texture and time parameters are bound, and the animation step is driven by the time controller in the rendering loop to trigger the GPU vertex shader to perform displacement calculations;

[0022] S4: Create a global instantiation picking grid and establish a building identification mapping through the efficient interaction module; implement ray tracing in response to mouse events to obtain instance IDs, query metadata through instance IDs, and call the DOM reuse tag pool to display static metadata and dynamic calculation results.

[0023] Preferably, the S1 includes:

[0024] Implement the spatial segmentation and metadata generation sub-step: divide the urban building data into 200m x 200m grids, and generate a JSON file containing building geometry information and multi-scene metadata for each non-empty data block. The multi-scene metadata maps the displacement texture URL using the scene ID as the key value;

[0025] Execute the displacement texture generation sub-step: Generate a PNG format displacement texture independently for each earthquake scene, build a canvas by calculating the total number of global floors, normalize the time step displacement value and inter-story displacement angle value of each floor according to the predetermined floor index mapping rule, write them into the R / G channel respectively, and finally export them as a displacement texture file.

[0026] Preferably, the S2 includes:

[0027] Initialize the ChunkManager instance and load the chunk URL list;

[0028] The camera position change is detected at a fixed period, and the internal and external dual boundary control mechanism is used to determine the data block loading / unloading status;

[0029] The loading task is executed through the concurrent control queue, and the unloaded grid is stored in the LRU cache pool with a life cycle, realizing on-demand dynamic scheduling and memory optimization of data blocks.

[0030] Preferably, the S3 includes:

[0031] Implement data block loading verification, prioritize restoring valid mesh models from the LRU cache, and asynchronously obtain JSON metadata and corresponding displacement textures of missing data blocks;

[0032] Enable the floor offset mechanism when building a single mesh model, generate a globally unique floorIndex attribute for each vertex, and aggregate building geometry data through the geometry merging tool;

[0033] Configure a custom ShaderMaterial, bind the displacement texture, total number of floors and time step;

[0034] In the main rendering loop, the animation step is driven by the time controller, and the current animation time step (uTimeStep) parameter is updated in real time to trigger the GPU vertex shader to perform displacement calculation and dynamic rendering.

[0035] Preferably, the S4 includes:

[0036] Create a global instantiation picking grid and establish a mapping table between building unique identifiers and instance IDs;

[0037] In response to mouse events, perform ray tracing, convert screen coordinates into three-dimensional rays, intersect with the picking grid, and return the instanceId of the instance that was hit;

[0038] Query the global mapping table through instanceId to obtain building metadata, and perform CPU-side displacement texture sampling to calculate dynamic response values;

[0039] The DOM reuse tag pool update mechanism is called to integrate static metadata with dynamic calculation results, and interactive information tags are accurately positioned and displayed in the three-dimensional scene.

[0040] Preferably, the S4 includes: developing a CPU-side displacement texture sampler:

[0041] Position the corresponding displacement texture according to the unique identifier assigned to each building instance;

[0042] Calculate the texture coordinates corresponding to the current time step;

[0043] Implement bilinear interpolation sampling to obtain normalized displacement values ​​and inter-layer displacement angles;

[0044] Perform inverse normalization calculation: actual displacement = sampling value × maximum allowable displacement value.

[0045] In summary, compared with the existing technology, the system proposed by the present invention has certain beneficial effects: through geometry merging and GPU instanced rendering, rendering batches are reduced to a minimum, achieving real-time smooth rendering and roaming of a million-level building complex, and rapid interactive response. By encoding massive time-series displacement data into textures and using GPU vertex shaders for parallel calculations, real-time, smooth animation simulation of the earthquake response of all buildings is achieved, solving the performance bottleneck of traditional CPU calculation methods. The block dynamic loading and unloading mechanism based on the view cone and double boundaries, combined with the LRU cache strategy with a life cycle, ensures that the system only processes the necessary data within the field of view, allowing the system to run ultra-large-scale city models with limited memory resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 This is a schematic block diagram of an embodiment of a visualization system for simulating earthquake disasters in urban building complexes according to the present application;

[0047] Figure 2 A schematic diagram showing the effect of building cluster response in a large area;

[0048] Figure 3 This is a schematic diagram showing the effect of the response of local area building complexes. DETAILED DESCRIPTION

[0049] The present invention will be further described below with reference to the accompanying drawings. The structure and principle of the present invention will be very clear to those skilled in the art. It should be understood that the specific embodiments described herein are only intended to explain the present invention and are not intended to limit the present invention.

[0050] The following nouns may appear in the text:

[0051] JSON - JavaScript Object Notation, a lightweight data interchange format for structured data transmission

[0052] PNG - Portable Network Graphics, a lossless compressed bitmap image format that supports transparency

[0053] GIS - Geographic Information System, a system for collecting, storing, and managing geospatial data

[0054] Shapefile - Shapefile is a vector data format developed by ESRI that stores the geometric location and attributes of geographic features.

[0055] WGS84 - World Geodetic System 1984, an internationally used geographic coordinate system

[0056] EPSG:3857 - Web Mercator Projection, a commonly used projection coordinate system for Internet maps, defined by the European Petroleum Survey Organization

[0057] Chunk - data block, the basic unit of spatial block storage, specifically 200m×200m geographic block in this article

[0058] Storey - floor, a hierarchical unit in the vertical direction of a building, equivalent to the concept of "floor"

[0059] RGBA - Red Green Blue Alpha (red, green, blue transparency), four-channel color representation, supports color and transparency encoding

[0060] Frustum - View frustum, a frustum of a cone defined by the viewpoint position and field of view parameters in three-dimensional space

[0061] ChunkManager - Chunk manager, the core scheduling component responsible for dynamically loading / unloading geographic data chunks

[0062] LRU - Least Recently Used (Least Recently Used), cache elimination strategy, prioritizes removing the least recently accessed data

[0063] BufferGeometry - Buffer geometry, WebGL optimized geometry data storage structure, improve rendering performance

[0064] Vertex Shader - Vertex shader, a shader program that handles vertex transformations in GPU programming

[0065] Uniforms - Uniform variables, a globally shared parameter storage mechanism in shader programs

[0066] InstancedMesh - Instanced mesh, a WebGL extension that renders multiple geometry instances with a single draw call

[0067] CSS2DObject - CSS2D object, a class in the Three.js library that implements binding between HTML elements and 3D scenes

[0068] DOM - Document Object Model, a programming interface for HTML / XML documents, used for dynamic content manipulation

[0069] URL - Uniform Resource Locator, an Internet standard resource address format that includes protocol, domain name, path, and other information

[0070] ID - Identification, a code used to uniquely identify an entity in the system

[0071] API - Application Programming Interface, a set of specifications and tools for interaction between software systems

[0072] CSV - Comma-Separated Values, a simple tabular data format that stores structured data in plain text

[0073] GPU - Graphics Processing Unit (GPU), a parallel computing unit dedicated to graphics rendering

[0074] CPU - Central Processing Unit (CPU), the core component of a computer that performs general computing tasks

[0075] 3D - Three-Dimensional, a spatial representation with three dimensions: length, width, and height

[0076] HTML - HyperText Markup Language, the standard markup language for building web pages

[0077] CSS - Cascading Style Sheets, a language that describes the presentation style of a web page

[0078] JavaScript - scripting language, the core programming language for web page interaction

[0079] Figure 1 This is a schematic block diagram of an embodiment of a visualization system for simulating earthquake disasters in urban buildings according to the present application. The system includes:

[0080] The offline data preprocessing and block organization module receives raw GIS data and seismic response data, cleans and converts them, constructs a spatial block data structure, generates JSON data blocks containing building geometry information and multi-channel displacement textures, and ultimately outputs a metadata file containing data block URL mappings. The GIS data includes building outlines and height information. The JSON file contains at least a block index, block boundary coordinates, and a building list. The metadata file contains at least a list of data block URLs and a mapping between scene IDs and displacement texture URLs.

[0081] Specifically, the offline data preprocessing and block organization module is responsible for processing and optimizing the raw data before the visualization system runs. It receives raw GIS data (such as building outlines and height information in Shapefile format) and raw earthquake response data as input. The module first cleans and converts the coordinates of the GIS data, and then spatially blocks it according to the preset grid size. Next, the building information within each data block is organized into independent data block JSON files. At the same time, for each earthquake scenario, the module encodes the time-series response data of all buildings into a multi-channel displacement texture PNG file, where different channels store different physical quantities (such as displacement and inter-story displacement angle). Finally, the module generates a metadata file containing the global configuration.

[0082] Before the visualization system runs, this module performs a series of processing on the original data through the back-end script to generate a highly optimized data structure that is directly usable by the front-end.

[0083] Data Source and Preprocessing: The system takes as input a standard GIS data format (Shapefile), which contains information such as the geographic outline and height of each building. The script first cleans the data, removing invalid buildings with small areas, and converts geographic coordinates (such as WGS84) to Web Mercator projection coordinates (EPSG:3857).

[0084] Spatial Blocking and Building Data Organization: The system divides the entire city map into a grid of fixed size (e.g., 200 meters x 200 meters). All buildings are assigned to corresponding data chunks based on their center points. For each data chunk, the system generates a separate Chunk.json file. This file contains the chunk index, chunk boundary coordinates, and a list of buildings. Each item in the list contains information such as a building's unique ID, geometric outline coordinates (bounds), center point (center), and number of floors (storeys).

[0085] Generation and encoding of multi-scenario displacement textures: For each preset earthquake scenario (such as different seismic waves, different magnitudes), the system performs the following operations:

[0086] a. Response data binding: Obtain the time-series response data for each building in the data block under a specific earthquake scenario. This data is a two-dimensional array of shape (number of floors, number of time steps), where each element represents the physical response value of that floor at that moment.

[0087] b. Displacement Texture Encoding: Encodes the response data for all buildings within the entire data block into a displacement texture image in PNG format. The script first calculates the total number of floors (sum_floors) for all buildings within the block. It then creates an image with a height equal to the number of time steps, a width of 1 + sum_floors, and RGBA channels. The image is filled column by column: column 0 represents the ground floor (no displacement); starting with column 1, the time-series response data for each floor of each building is sequentially filled in. Two different physical quantities are encoded into different color channels: the R channel stores the normalized absolute floor displacement; the G channel stores the normalized inter-story displacement angle. The data is linearly mapped to an 8-bit integer range ([0, 255]) for storage in the PNG. This texture image contains all the dynamic information for the data block under this earthquake scenario.

[0088] The block dynamic data management and scheduling module uses dual boundary control and cone clipping algorithms based on the user's viewpoint to dynamically load or unload the JSON data blocks generated by the offline data preprocessing and block organization modules, manage network requests through concurrent control queues, and store unloaded data in the LRU cache. The dual boundary control mechanism includes using differentiated boundary thresholds to build a loading and unloading judgment system. When the data block's extended bounding box enters the inner boundary, preloading is triggered, and unloading is performed when it completely moves out of the outer boundary, which is used to avoid frequent IO operations caused by small movements of the viewpoint. The cone clipping algorithm includes constructing a three-dimensional cone based on the camera's viewpoint, accurately determining the intersection relationship between the data block and the visible area through spatial geometric calculations, and loading or maintaining the data blocks within the cone.

[0089] Specifically, the block-based dynamic data management and scheduling module uses dual-boundary control and a frustum clipping algorithm based on the user's viewpoint (camera) to determine in real time which data blocks need to be loaded or unloaded. For blocks that need to be loaded, it initiates a request through the concurrent control queue to obtain the corresponding data block JSON file and displacement texture PNG file. For blocks that need to be unloaded, their rendering resources are released and placed in the LRU cache. This module is responsible for managing the data lifecycle, ensuring that only user-visible buildings are stored in memory.

[0090] When the system is running, a core data chunk manager (ChunkManager) is responsible for dynamic scheduling based on the frustum of the user's viewpoint (camera).

[0091] Dual Boundary Control: To avoid frequent loading and unloading when the viewpoint moves slightly, the manager uses differentiated dual margins. A smaller inner margin (marginIn, for example, 150 meters) triggers loading, and a larger outer margin (marginOut, for example, 200 meters) triggers unloading. A chunk is unloaded only when its expanded bounding box completely moves outside the outer margin.

[0092] LRU caching mechanism: The mesh of an unloaded chunk is not immediately destroyed. Instead, it is placed in a timestamped cache pool (chunkCache). When the chunk needs to be reloaded, the system first checks the cache. If the cache exists and has not exceeded the preset lifetime (cacheLifetime, for example, 30 seconds), it is restored directly from the cache, avoiding the overhead of network requests and geometry reconstruction. Expired cache items are completely destroyed to free up resources.

[0093] Concurrent Loading Control: To prevent browser or network congestion caused by excessive simultaneous network requests, the manager has a built-in load queue (loadQueue) and a concurrency limit (maxConcurrentLoads, for example, 8). When the concurrent request limit is reached, new load tasks will be queued and intelligently scheduled by the manager.

[0094] The GPU accelerated rendering module is used to receive the data blocks output by the offline data preprocessing and block organization module, perform geometry merging to generate a single buffer geometry, assign unique identifiers to vertices through global floor index mapping, and finally submit the merged model to the GPU to collaborate with the displacement texture and custom shader to achieve real-time rendering of the building form.

[0095] Specifically, the GPU-accelerated rendering module is responsible for efficiently rendering the loaded data blocks. It receives the loaded data blocks from the block dynamic data management and scheduling module. Internally, the module performs geometry merging, assigning each vertex a unique floor identifier using a global floor index map. Finally, the merged single mesh model is submitted to the graphics processing unit (GPU) for rendering.

[0096] This module aims to combine the rendering of hundreds or thousands of buildings within the same data block into a single render call.

[0097] Geometry merging: When a data block is loaded, the system traverses all buildings in the block and merges their 3D geometry data (vertex position, color, etc.) into a single, huge buffer geometry (BufferGeometry) on the CPU side.

[0098] Global floor index mapping: During the geometry merging process, the system creates an additional custom attribute for each vertex—a global floor index (floorIndex). This index is a floating-point number that uniquely identifies the floor to which the vertex belongs. Its generation rule is as follows: the system maintains a runtime floor offset (floorOffset), starting at 1. For the first building in a block (assuming it has N floors), the floorIndex of the vertices on floors 1 to N is assigned values ​​from floorOffset to floorOffset + N - 1, respectively. Subsequently, the floor offset is increased by N. The next building is processed, and so on. In particular, the floorIndex of the vertices on the ground floor (floor 0, no displacement) of all buildings is uniformly set to 0. In this way, all non-ground floors of all buildings in a data block have continuous and unique floor attributes starting from 1.

[0099] The GPU parallel displacement animation module is deeply coupled to the GPU rendering pipeline. It is used to parallel sample the displacement texture using the vertex global floor index, calculate the vertex displacement and color value in real time, and inject them into the rendering pipeline.

[0100] Specifically, the GPU Parallel Displacement Animation module is responsible for achieving real-time dynamic effects for the building complex. This module is tightly coupled with the GPU-accelerated rendering module and runs on the GPU. It receives the displacement texture provided by the Block Dynamic Data Management and Scheduling module, as well as the current animation timestep. In the vertex shader, this module uses the vertex's global floor index and the current timestep to sample the displacement texture, calculate the real-time displacement and dynamic color for all vertices in parallel, and directly apply this to rendering.

[0101] This module completely transfers complex time-series animation calculation tasks to the GPU, achieving large-scale parallel processing.

[0102] Displacement Texture Encoding: During data preprocessing, the dynamic response data of all buildings at all time steps is encoded into a two-dimensional texture image (displacement texture, uDisplacementMap). The U-axis (horizontal axis) of this texture corresponds to the global floor index, and the V-axis (vertical axis) corresponds to the earthquake simulation time step. Each pixel of the texture stores different physical quantities in its different color channels (RGBA).

[0103] Vertex shader real-time displacement calculation: During rendering, this displacement texture is passed to the custom vertex shader as uniform variables (Uniforms) along with uTimeStep, total number of floors (uSumFloors), total number of time steps (uTimeSteps), etc. The shader performs the following operations for each vertex:

[0104] Read the vertex's own floorIndex property.

[0105] If floorIndex is greater than 0 and animation is turned on, the corresponding UV sampling coordinates on the displacement texture are calculated based on floorIndex and uTimeStep.

[0106] Sample the displacement texture and read the normalized displacement values ​​from different channels.

[0107] The displacement value is denormalized and applied to the original coordinates of the vertex in real time to complete the dynamic update of the building form.

[0108] The entire calculation process is executed in parallel on all vertices on the GPU, achieving smooth and lag-free earthquake response animation of ultra-large-scale building complexes.

[0109] An efficient interaction module is used to implement ray tracing to solve building instance IDs by instantiating and picking grids, obtain metadata based on pre-built building data mapping tables, maintain the tag pool using DOM reuse technology, and dynamically update tag content and coordinates to achieve 3D interaction.

[0110] Specifically, the efficient interaction module handles user interactions. When user input (such as mouse movement or clicks) occurs, efficient ray tracing is performed using a globally unique, invisible, single instanced picking grid to quickly identify the building instance ID pointed to by the user. Static metadata for the building is retrieved by querying the building data mapping table. This is then efficiently presented to the user in the form of interactive information tags within the 3D scene using the DOM's reused tag pool.

[0111] Single instanced picking mesh: The system creates a globally unique, invisible instanced mesh (InstancedMesh) and places it in a dedicated picking rendering layer (pickingLayer). For each building loaded into the scene, the system does not create a separate picking object. Instead, it creates a simple proxy geometry instance (such as a cube) for it in this InstancedMesh and scales and positions it to match the original building. At the same time, a global building data mapping table stores the mapping relationship between the building's unique identifier and its instance ID and other metadata (such as the data block to which it belongs, the floor index range floorIndexOffset, etc.). When the user clicks, ray tracing only intersects with this single InstancedMesh, which can quickly return the instanceId of the instance hit, and then use the mapping table to find all the information about the building with O(1) complexity.

[0112] DOM Reuse Label Pool: To avoid performance issues caused by the frequent creation and destruction of DOM elements when displaying building information, this invention implements a label pool (labelPool). During initialization, this pool creates a CSS2DObject and its associated div tag, permanently adding it to the scene. When a label is displayed, the system only updates the inner text content (innerHTML) of this single div and the 3D position of its attached CSS2DObject, setting it to visible. When no longer needed, it is set to invisible (display: 'none'). This reuse mechanism significantly improves the display performance of interactive labels.

[0113] The present application also provides a visualization method for simulating earthquake disasters in urban buildings based on the aforementioned system, the method comprising:

[0114] S1: The offline data preprocessing and block organization module divides the data into blocks according to a preset grid size, generates JSON metadata containing building geometry information and scenario-based displacement texture URLs; generates PNG displacement textures for each earthquake scene, and normalizes the time-step displacement values ​​and inter-story displacement angle values ​​of each floor and writes them into the R / G channels respectively. S1 includes:

[0115] Implement the spatial segmentation and metadata generation sub-step: divide the urban building data into 200m x 200m grids, and generate a JSON file containing building geometry information and multi-scene metadata for each non-empty data block. The multi-scene metadata maps the displacement texture URL using the scene ID as the key value;

[0116] Execute the displacement texture generation sub-step: Generate a PNG format displacement texture independently for each earthquake scene, build a canvas by calculating the total number of global floors, normalize the time step displacement value and inter-story displacement angle value of each floor according to the predetermined floor index mapping rule, write them into the R / G channel respectively, and finally export them as a displacement texture file.

[0117] S2: Initialize the ChunkManager to load the data chunk list through the block dynamic data management and scheduling module; use the double boundary control mechanism to achieve on-demand loading / unloading of data chunks through camera position change detection; use the concurrent queue to execute the loading task and optimize memory usage through LRU cache. S2 includes:

[0118] Initialize the ChunkManager instance and load the chunk URL list;

[0119] The camera position change is detected at a fixed period, and the internal and external dual boundary control mechanism is used to determine the data block loading / unloading status;

[0120] The loading task is executed through the concurrent control queue, and the unloaded grid is stored in the LRU cache pool with a life cycle, realizing on-demand dynamic scheduling and memory optimization of data blocks.

[0121] S3: After verifying the data block through the GPU accelerated rendering module and the GPU parallel displacement animation module, the mesh model is restored from the cache first, a globally unique index is generated for the vertex when constructing a single mesh model, a custom ShaderMaterial is configured and the displacement texture and time parameters are bound, the animation step is driven by the time controller in the rendering loop, and the GPU vertex shader is triggered to perform displacement calculations. S3 includes:

[0122] Implement data block loading verification, prioritize restoring valid mesh models from the LRU cache, and asynchronously obtain JSON metadata and corresponding displacement textures of missing data blocks;

[0123] Enable the floor offset mechanism when building a single mesh model, generate a globally unique floorIndex attribute for each vertex, and aggregate building geometry data through the geometry merging tool;

[0124] Configure a custom ShaderMaterial, bind the displacement texture, total number of floors and time step;

[0125] In the main rendering loop, the animation step is driven by the time controller, and the uTimeStep parameter is updated in real time to trigger the GPU vertex shader to perform displacement calculation and dynamic rendering.

[0126] S4: Create a global instanced picking grid and establish a building identification map through the efficient interaction module; implement ray tracing in response to mouse events to obtain instance IDs, query metadata through instance IDs, and call the DOM reuse tag pool to display static metadata and dynamic calculation results. S4 includes: Developing a CPU-side displacement texture sampler:

[0127] Position the corresponding displacement texture according to the unique identifier assigned to each building instance;

[0128] Calculate the texture coordinates corresponding to the current time step;

[0129] Implement bilinear interpolation sampling to obtain normalized displacement values ​​and inter-layer displacement angles;

[0130] Perform inverse normalization calculation: actual displacement = sampling value × maximum allowable displacement value.

[0131] The S4 includes:

[0132] Create a global instantiation picking grid and establish a mapping table between building unique identifiers and instance IDs;

[0133] In response to mouse events, perform ray tracing, convert screen coordinates into three-dimensional rays, intersect with the picking grid, and return the instanceId of the instance that was hit;

[0134] Query the global mapping table through instanceId to obtain building metadata, and perform CPU-side displacement texture sampling to calculate dynamic response values;

[0135] The DOM reuse tag pool update mechanism is called to integrate static metadata with dynamic calculation results, and interactive information tags are accurately positioned and displayed in the three-dimensional scene.

[0136] The following is a detailed description of each step:

[0137] Step 1: Data preprocessing and organization

[0138] Spatial Blocking and Metadata Generation: The city building data is divided into a 200m x 200m grid, and a JSON file is generated for each non-empty data block. This file contains geometric information (such as outline coordinates and number of floors) for all buildings within the block, as well as multi-scene information. The multi-scene information is an object whose key is the scene ID and whose value is the metadata for that scene, including the corresponding displacement texture URL.

[0139] Displacement Texture Generation: For each earthquake scenario, a displacement texture is generated independently. All buildings are traversed to calculate the global total number of floors. A canvas is created with a width equal to the global total number of floors and a height equal to the number of time steps. Following the global floor index mapping rule described above, the displacement values ​​and inter-story displacement angles for each floor at each time step are normalized and mapped to the R and G channels of the corresponding pixel, respectively. Finally, the canvas is exported as a PNG image.

[0140] Step 2: System operation and dynamic scheduling

[0141] Chunk manager initialization: After the system starts, initialize a ChunkManager instance and load a list containing all data chunk URLs.

[0142] On-demand loading and unloading: The manager detects camera position changes at regular intervals (e.g., 60ms). It determines which data blocks need to be loaded and unloaded based on the internal and external margins (marginIn, marginOut). Loading tasks are queued for execution in the concurrency control queue. Unloaded meshes are stored in the LRU cache.

[0143] Step 3: Rendering and animation implementation process

[0144] Data Block Loading: When a data block is scheduled for loading, the system first checks whether it exists in the LRU cache. If the cache is valid, the 3D mesh model is directly restored. If the cache is not valid or has expired, the system asynchronously retrieves the JSON metadata file corresponding to the data block from the server and, based on the currently active earthquake scene ID, retrieves its unique displacement texture image.

[0145] Single mesh model construction and geometric information injection: The system starts a "building complex from data blocks" construction process. The core functions of this process are:

[0146] First, it iterates over all buildings contained in the data chunk JSON file and generates the 3D geometry data for each building.

[0147] In the process of generating geometry vertices, a key "floor offset" mechanism is enabled. This mechanism maintains a global cumulative counter and generates and assigns a unique floorIndex (global floor index) attribute to each vertex.

[0148] After the geometric data of all independent buildings are collected, a dedicated tool module called "Geometry Merger" will aggregate these scattered geometric data and finally generate a single mesh model that contains all the buildings in the block but is structurally unified.

[0149] Custom Rendering Material and Shader Parameter Configuration: A custom shader material (ShaderMaterial) is created for the merged mesh generated in the previous step. The loaded displacement texture image is then assigned to a uniform variable named uDisplacementMap within the material. Other key parameters, such as the total number of floors in the data block and the total number of animation time steps, are also set to the corresponding uniform variables within the material for use by the GPU in subsequent calculations.

[0150] Animation Looping and Driving: During each frame of the system's main rendering loop, a "time controller" module accurately calculates the time step at which the current animation should play, based on the user-defined playback speed and pause status. This time step value is updated in real time in the rendering materials of all currently visible data blocks, specifically assigned to a uniform variable named uTimeStep. Once the GPU detects a change in this variable value, it automatically performs a new round of displacement and color calculations for all vertices in its internal vertex shader program, completing the final rendering and driving the dynamic changes of the entire scene.

[0151] Step 4: Implementation process of interactive information query

[0152] Creation and Mapping of Pick Proxy Instances: While loading a data-block and constructing its rendering model, the Data-block Manager invokes the "Add Building" function of the Building Pick Manager. Upon receiving the building data, this function does not create a separate pick object. Instead, it creates a geometric proxy instance for the building within a globally unique, invisible InstancedMesh. Simultaneously, a global mapping table within the Pick Manager records the association between the building's unique identifier and its corresponding instance ID within the InstancedMesh.

[0153] Ray Tracing and Target Identification: When the user's mouse moves across the screen, an "intersection detection" function is triggered. This function converts the mouse's 2D screen coordinates into a ray in 3D space and performs efficient ray tracing calculations specifically for the specific instanced mesh hosting all the picking agents. If the ray intersects an instance, the function immediately returns the instanceId of the instance that was hit.

[0154] Information query and visualization:

[0155] The system uses the instanceId obtained in the previous step to quickly query the global mapping table of the building picking manager to obtain all the static metadata of the selected building.

[0156] If you need to display the building's precise dynamic response at the current moment (for example, the exact number of millimeters of displacement of the top floor), the system calls a "displacement value calculation" function. This function calculates the required value by performing pixel-level precise sampling of the displacement texture on the CPU.

[0157] Finally, the system calls a "create or update tag" function in the tag pool, integrates the queried static and dynamic information, updates it into a reusable DOM element, and locates it at the corresponding position of the building in the three-dimensional scene, presenting it to the user in the form of a tag.

[0158] Figure 2 This is a schematic diagram showing the effect of the response of a large-scale regional building complex. Figure 3 This diagram shows the response of a localized building complex. Each grid represents a building structure. The color of the grid vertices represents the structure's inter-story displacement response, and the position of the grid vertices represents the structure's absolute displacement response. Red indicates a larger response value, while green indicates a smaller response value. When the user selects a specific grid, a blue label appears, displaying the building name and the response information for the current time step.

[0159] In summary, compared with the prior art, the technical solution proposed by the present invention has the following significant beneficial effects:

[0160] It breaks through the performance bottleneck of ultra-large-scale scenes: through geometry merging and GPU instanced rendering, rendering batches are reduced to a minimum, achieving real-time smooth rendering and roaming of millions of buildings with fast interactive response.

[0161] Efficient real-time dynamic animation is achieved: by encoding massive time-series displacement data into textures and using GPU vertex shaders for parallel calculations, real-time and smooth animation simulation of the earthquake response of all buildings is achieved, solving the performance bottleneck of traditional CPU calculation methods.

[0162] Significantly reduces memory and video memory usage: A dynamic loading and unloading mechanism for blocks based on the view cone and double boundaries, combined with a lifecycle LRU cache strategy, ensures that the system only processes the necessary data within the field of view, allowing the system to run ultra-large-scale city models with limited memory resources.

[0163] It provides an efficient and accurate interactive experience: the picking solution based on a single instantiated grid achieves millisecond-level fast picking of massive buildings; combined with the DOM reuse tag pool, it provides delay-free information tag display, and the interactive experience is smooth and natural.

[0164] It has good scalability and flexibility: by dynamically replacing displacement textures, it achieves rapid hot switching of multiple earthquake scenes, facilitates comparative analysis under different disaster scenarios, and provides a powerful technical support platform for urban planning, disaster assessment and emergency management.

Claims

1. A visualization system for earthquake disaster simulation of urban building complexes, characterized by: The system comprises: The offline data preprocessing and block organization module is used to receive raw GIS data and earthquake response data, build a spatial block data structure after cleaning and conversion, generate JSON data blocks containing building geometry information and multi-channel displacement textures, and finally output a metadata file containing data block URL mapping; The block dynamic data management and scheduling module uses dual boundary control and cone clipping algorithms based on the user's viewpoint to dynamically load or unload JSON data blocks generated by the offline data preprocessing and block organization modules. It manages network requests through concurrent control queues and stores unloaded data in the LRU cache. A GPU-accelerated rendering module is configured to receive the data blocks output by the offline data preprocessing and block organization module, perform geometry merging to generate a single buffered geometry, assign unique identifiers to vertices through a global floor index map, and finally submit the merged model to the GPU to achieve real-time rendering of the building form in collaboration with displacement textures and custom shaders; The GPU parallel displacement animation module is deeply coupled to the GPU rendering pipeline. It is used to parallel sample the displacement texture using the vertex global floor index, calculate the vertex displacement and color value in real time, and inject them into the rendering pipeline. An efficient interaction module is used to implement ray tracing to solve building instance IDs by instantiating and picking grids, obtain metadata based on pre-built building data mapping tables, maintain the tag pool using DOM reuse technology, and dynamically update tag content and coordinates to achieve 3D interaction.

2. The system according to claim 1, wherein: The offline data preprocessing and block organization module is used to organize the building information in each JSON data block into an independent data block JSON file. The GIS data includes building outline and height information. The JSON file contains at least a block index, block boundary coordinates and a building list. The metadata file contains at least a data block URL list and a mapping relationship between scene ID and displacement texture URL.

3. The system according to claim 1, wherein: The dual boundary control mechanism includes using differentiated boundary thresholds to build a loading and unloading judgment system. When the data block's extended bounding box enters the inner boundary, preloading is triggered, and when it completely moves out of the outer boundary, an unloading operation is performed, which is used to avoid frequent IO operations caused by small movements of the viewpoint.

4. The system according to claim 1, wherein: The viewing cone clipping algorithm includes constructing a three-dimensional viewing cone based on the camera viewpoint, accurately determining the intersection relationship between the data block and the visible area through spatial geometric calculation, and loading or maintaining the data blocks within the viewing cone.

5. A visualization method for earthquake disaster simulation of urban building complexes, characterized by: Using the system according to any one of claims 1 to 4, the method steps are as follows: S1: The offline data preprocessing and block organization module divides the data blocks into preset grid sizes, and generates JSON metadata containing building geometry information and scenario-based displacement texture URLs; generates PNG displacement textures for each earthquake scene, and normalizes the time step displacement values ​​and inter-story displacement angle values ​​of each floor and writes them into the R / G channels respectively; S2: Initialize the ChunkManager to load the data chunk list through the block dynamic data management and scheduling module; implement on-demand loading / unloading of data chunks by using a dual boundary control mechanism through camera position change detection; execute loading tasks using concurrent queues and optimize memory usage through LRU caching; S3: After verifying the data block through the GPU accelerated rendering module and the GPU parallel displacement animation module, the mesh model is restored from the cache first, a globally unique index is generated for the vertex when constructing a single mesh model, a custom ShaderMaterial is configured and the displacement texture and time parameters are bound, and the animation step is driven by the time controller in the rendering loop to trigger the GPU vertex shader to perform displacement calculations; S4: Create a global instantiation picking grid and establish a building identification mapping through the efficient interaction module; implement ray tracing in response to mouse events to obtain instance IDs, query metadata through instance IDs, and call the DOM reuse tag pool to display static metadata and dynamic calculation results.

6. The method according to claim 5, characterized in that Said S1 comprises: Implement the spatial segmentation and metadata generation sub-step: divide the urban building data into 200m x 200m grids, and generate a JSON file containing building geometry information and multi-scene metadata for each non-empty data block. The multi-scene metadata maps the displacement texture URL using the scene ID as the key value; Execute the displacement texture generation sub-step: Generate a PNG format displacement texture independently for each earthquake scene, build a canvas by calculating the total number of global floors, normalize the time step displacement value and inter-story displacement angle value of each floor according to the predetermined floor index mapping rule, write them into the R / G channel respectively, and finally export them as a displacement texture file.

7. The method according to claim 5, characterized in that The S2 includes: Initialize the ChunkManager instance and load the chunk URL list; The camera position change is detected at a fixed period, and the internal and external dual boundary control mechanism is used to determine the data block loading / unloading status; The loading task is executed through the concurrent control queue, and the unloaded grid is stored in the LRU cache pool with a life cycle, realizing on-demand dynamic scheduling and memory optimization of data blocks.

8. The method according to claim 5, characterized in that The S3 includes: Implement data block loading verification, prioritize restoring valid mesh models from the LRU cache, and asynchronously obtain JSON metadata and corresponding displacement textures of missing data blocks; Enable the floor offset mechanism when building a single mesh model, generate a globally unique floorIndex attribute for each vertex, and aggregate building geometry data through the geometry merging tool; Configure a custom ShaderMaterial, bind the displacement texture, total number of floors and time step; In the main rendering loop, the animation step is driven by the time controller, and the uTimeStep parameter is updated in real time to trigger the GPU vertex shader to perform displacement calculation and dynamic rendering.

9. The method according to claim 5, characterized in that The S4 includes: Create a global instantiation picking grid and establish a mapping table between building unique identifiers and instance IDs; In response to mouse events, perform ray tracing, convert screen coordinates into three-dimensional rays, intersect with the picking grid, and return the instanceId of the instance that was hit; Query the global mapping table through instanceId to obtain building metadata, and perform CPU-side displacement texture sampling to calculate dynamic response values; The DOM reuse tag pool update mechanism is called to integrate static metadata with dynamic calculation results, and interactive information tags are accurately positioned and displayed in the three-dimensional scene.

10. The method according to claim 9, characterized in that The S4 includes: Developing a CPU-side displacement texture sampler: Position the corresponding displacement texture according to the unique identifier assigned to each building instance; Calculate the texture coordinates corresponding to the current time step; Implement bilinear interpolation sampling to obtain normalized displacement values ​​and inter-layer displacement angles; Perform inverse normalization calculation: actual displacement = sampling value × maximum allowable displacement value.

Images