Visualization system and method for urban building group earthquake disaster simulation

Abstract

The invention relates to the technical field of urban earthquake disaster simulation, and provides a visualization system and method for urban building group earthquake disaster simulation, and the system comprises an offline data preprocessing and block organization module and a block dynamic data management and scheduling module. The GPU acceleration rendering module is used for mapping a global floor index to a vertex to endow the vertex with a unique identifier, and finally submitting the combined model to a GPU, and cooperating with a displacement texture and a user-defined shader to realize real-time rendering of a building form; the GPU parallel displacement picture moving module is deeply coupled to the GPU rendering pipeline and is used for resolving the vertex displacement and the color value in real time and injecting the vertex displacement and the color value into the rendering pipeline; and the efficient interaction module dynamically updates label contents and coordinates to realize three-dimensional interaction. According to the method, massive time sequence displacement data are coded into textures, and parallel calculation is performed by using the GPU vertex shader, so that real-time and smooth animation simulation of earthquake responses of all buildings is realized, and the performance bottleneck of a traditional CPU calculation mode is solved.

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: 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.

[0003] 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.

[0004] 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

[0005] 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.

[0006] 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: A visualization system for simulating earthquake disasters in urban building complexes, wherein 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 chunked dynamic data management and scheduling module dynamically loads or unloads JSON data chunks generated by the offline data preprocessing and chunking organization module based on the user's viewpoint, using double boundary control and frustum culling algorithms, manages network requests through a concurrent control queue, and stores the unloaded data in the LRU cache; The GPU-accelerated rendering module is used to receive the data chunks output by the offline data preprocessing and chunking organization module, perform geometry merging to generate a single buffered geometry, assign unique identifiers to vertices through global floor indexing, and finally submit the merged model to the GPU to achieve real-time rendering of the building form in cooperation with displacement textures and custom shaders; The GPU parallel displacement animation module is deeply coupled to the GPU rendering pipeline and is used to perform parallel sampling of displacement textures using the vertex global floor index, and solve the vertex displacement and color values in real time and inject them into the rendering pipeline; The efficient interaction module is used to perform ray tracing to solve the building instance ID by instantiating a pick-up grid, obtain metadata by combining a pre-built building data mapping table, maintain a tag pool using DOM reuse technology, and dynamically update the tag content and coordinates to achieve 3D interaction.

[0007] Preferably, the GIS data includes building outline and height information, the JSON file includes at least block index, block boundary coordinates and building list, and the metadata file includes at least a list of data block URLs and the mapping relationship between the scene ID and the displacement texture URL.

[0008] Preferably, the double boundary control mechanism includes constructing a loading and unloading decision system using differential boundary thresholds. When the extended bounding box of the data block enters the inner boundary, preloading is triggered, and when it completely moves out of the outer boundary, the unloading operation is performed to avoid frequent IO operations caused by small viewpoint movements.

[0009] Preferably, the frustum culling algorithm includes constructing a three-dimensional frustum based on the camera viewpoint, accurately determining the intersection relationship between the data block and the visible area through spatial geometric calculations, and performing loading or retention processing on the data blocks within the frustum.

[0010] In a second aspect, the present application provides a lightweight visualization method for earthquake disaster simulation of urban building groups based on the system described in any one of the foregoing first aspects, adopting the following technical solutions: A lightweight visualization method for earthquake disaster simulation of urban building groups based on the system described in any one of the foregoing first aspects, wherein the method includes: S1: Divide data blocks according to a preset grid size through the offline data preprocessing and chunk organization module, and generate JSON metadata containing building geometric information and URL of the scene-based displacement texture; generate PNG displacement textures for each earthquake scene, and normalize the displacement values at each time step and the inter-story drift angle values of each floor and write them into the R / G channels respectively; S2: Initialize the ChunkManager through the chunk dynamic data management and scheduling module to load the data block list; detect the change of the camera position, and adopt a dual-boundary control mechanism to achieve on-demand loading / unloading of data blocks; use a concurrent queue to execute the loading task, and optimize the memory usage through an LRU cache; S3: After verifying the data block through the GPU accelerated rendering module and the GPU parallel displacement animation module, preferentially restore the mesh model from the cache. When constructing a single mesh model, generate a globally unique index for the vertices, configure a custom ShaderMaterial material and bind the displacement texture and time parameters. In the rendering loop, drive the animation step through a time controller to trigger the GPU vertex shader to execute displacement calculations; S4: Create a globally instantiated picking mesh through the efficient interaction module and establish a building identification mapping; implement ray tracing in response to a mouse event to obtain the instance ID, query the metadata through the instance ID, and call the DOM reuse tag pool to display the static metadata and dynamic calculation results.

[0011] Preferably, the S1 includes: Implement the spatial chunking and metadata generation sub-step: Divide the urban building data according to a 200m×200m grid, and generate a JSON file containing building geometric information and multi-scene metadata for each non-empty data block. The multi-scene metadata maps the displacement texture URL with the scene ID as the key value; Execute the displacement texture generation sub-step: Independently generate displacement textures in PNG format for each earthquake scene, construct a canvas by calculating the total number of global floors, and normalize the displacement values at each time step and the inter-story drift angle values of each floor according to the predetermined floor index mapping rule and write them into the R / G channels respectively, and finally export them as displacement texture files.

[0012] Preferably, the S2 includes: Initialize the ChunkManager instance and load the data block URL list; Detect the change of the camera position at a fixed period, and adopt an internal and external dual-boundary control mechanism to determine the loading / unloading state of the data block; Execute the loading task through a concurrent control queue, and store the unloaded meshes in an LRU cache pool with a life cycle to achieve on-demand dynamic scheduling and memory optimization of the data block.

[0013] Preferably, the S3 includes: Implement data block loading verification, preferentially recover valid grid models from the LRU cache, and asynchronously obtain JSON metadata of missing data blocks and corresponding displacement textures; Enable the floor offset mechanism when constructing a single grid model, generate a globally unique floorIndex attribute for each vertex, and aggregate building geometric data through the geometry merging tool; Configure the custom ShaderMaterial material, bind the displacement texture, total number of floors, and time step; In the main rendering loop, drive the animation step through the time controller, and update the current animation time step (uTimeStep) parameter in real time to trigger the GPU vertex shader to perform displacement calculation and dynamic rendering.

[0014] Preferably, the S4 includes: Create a globally instantiated picking grid, and establish a mapping table between the building unique identifier and the instance ID; Implement ray tracing in response to the mouse event, convert the screen coordinates into a three-dimensional ray and intersect with the picking grid, and return the instanceId of the hit instance; Query the global mapping table through the instanceId to obtain the building metadata, and execute the CPU-side displacement texture sampling calculation to dynamically respond to the value; Call the DOM reuse label pool update mechanism, integrate the static metadata and the dynamic calculation results, and accurately position and display the interactive information label in the three-dimensional scene.

[0015] Preferably, the S4 includes: Develop a CPU-side displacement texture sampler: Locate 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 the normalized displacement value and the interlayer displacement angle; Execute the denormalization calculation: actual displacement = sampling value × maximum allowable displacement value.

[0016] In summary, compared with the prior art, the system proposed by the present invention has certain beneficial effects: through geometry merging and GPU instance rendering, the rendering batches are minimized, and real-time smooth rendering and roaming of a million-level building complex are achieved, with rapid interaction response. By encoding massive time-series displacement data as textures and using the GPU vertex shader for parallel computing, real-time and smooth animation simulation of the seismic responses of all buildings is realized, solving the performance bottleneck of the traditional CPU calculation method. Based on the frustum and double-boundary block dynamic loading and unloading mechanism, combined with the LRU cache strategy with a lifecycle, it is ensured that the system only processes the necessary data within the field of view, enabling the system to run a super-large-scale urban model with limited memory resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 FIG. is a schematic block diagram of an embodiment of a visualization system for earthquake disaster simulation of urban building groups according to the present application; Figure 2 FIG. is a schematic diagram showing the display effect of the response of building groups in a large - scale area; Figure 3 FIG. is a schematic diagram showing the display effect of the response of building groups in a local area. DETAILED DESCRIPTION OF THE EMBODIMENTS

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

[0019] The following nouns may appear in the text: JSON - JavaScript Object Notation, a lightweight data interchange format for structured data transmission PNG - Portable Network Graphics, a lossless compressed bitmap image format that supports transparency GIS - Geographic Information System, a system for collecting, storing, and managing geospatial data Shapefile - a vector data format developed by ESRI that stores the geometric location and attributes of geographic features WGS84 - World Geodetic System 1984, an internationally common geographic coordinate system EPSG:3857 - Web Mercator Projection, a commonly used projection coordinate system for Internet maps, defined by the European Petroleum Survey Group Chunk - a data block, the basic unit of spatial block storage, specifically referring to a 200m×200m geographic block in this article storey - a floor, a hierarchical unit in the vertical direction of a building, equivalent to the "floor" concept RGBA - Red Green Blue Alpha, a four - channel color representation method that supports color and transparency encoding Frustum - The frustum, a frustum cone region defined by the viewpoint position and field of view parameters in three-dimensional space ChunkManager - The data chunk manager, the core scheduling component responsible for dynamically loading / unloading geographical data chunks LRU - Least Recently Used, a cache eviction policy that preferentially removes the data that has not been accessed for the longest time BufferGeometry - Buffer geometry, a geometric data storage structure optimized for WebGL to improve rendering performance [[ID=⑧]]Vertex Shader - The vertex shader, a shader program in GPU programming that processes vertex transformations Uniforms - Uniform variables, a parameter storage mechanism that is globally shared in shader programs InstancedMesh - The instanced mesh, a WebGL extension function that renders multiple geometric instances through a single draw call CSS2DObject - The CSS2D object, a class in the Three.js library that implements the binding of HTML elements to the 3D scene DOM - Document Object Model, the programming interface for HTML / XML documents, used for dynamic content operations URL - Uniform Resource Locator, the Internet standard resource address format, containing information such as protocol, domain name, and path ID - Identification, the encoding used to uniquely identify entities in the system API - Application Programming Interface, a collection of specifications and tools for interaction between software systems CSV - Comma-Separated Values, a simple tabular data format that stores structured data in plain text GPU - Graphics Processing Unit, a parallel computing unit specialized for graphics rendering CPU - Central Processing Unit, the core component of a computer that executes general computing tasks 3D - Three-Dimensional, a spatial representation with three dimensions: length, width, and height HTML - HyperText Markup Language (Hypertext Markup Language), the standard markup language for building web pages CSS - Cascading Style Sheets (Cascading Style Sheets), a language for describing the presentation style of web pages JavaScript - A scripting language, the core programming language for web page interaction Figure 1 FIG. 7 is a schematic block diagram of an embodiment of a visualization system for earthquake disaster simulation for urban building clusters according to the present application. The system includes: An offline data preprocessing and chunk organization module, configured to receive original GIS data and earthquake response data, construct a spatial chunk data structure after cleaning and conversion, generate JSON data chunks containing building geometric information and multi-channel displacement textures, and finally output a metadata file containing a data chunk URL mapping. The GIS data includes building contour and height information, the JSON file includes at least a chunk index, chunk boundary coordinates, and a building list, and the metadata file includes at least a data chunk URL list and a mapping relationship between a scene ID and a displacement texture URL.

[0020] Specifically, the offline data preprocessing and chunk organization module is responsible for processing and optimizing the original data before the visualization system runs. It receives the original GIS data (such as building contour and height information in Shapefile format) and the original earthquake response data as inputs. The module first cleans and performs coordinate conversion on the GIS data, and then spatially chunks it according to a preset grid size. Then, the building information within each data chunk is organized into an independent data chunk JSON file. At the same time, for each earthquake scene, 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 drift ratio). Finally, the module generates a metadata file containing global configurations.

[0021] Before the visualization system runs, this module performs a series of processing on the original data through backend scripts to generate a data structure that is directly available and highly optimized for the front end.

[0022] Data source and preprocessing: The system takes standard GIS data format (Shapefile) as input, and this data includes information such as the geographical contour and height of each building. The script first cleans the data, removes invalid buildings with too small an area, and uniformly converts the geographical coordinates (such as WGS84) to Web Mercator projection coordinates (EPSG:3857).

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

[0024] Generation and Encoding of Multi-Scene Displacement Textures: For each preset earthquake scenario (such as different seismic waves and magnitudes), the system performs the following operations: a. Response Data Binding: Obtain the time-series response data of each building in the data chunk under a specific earthquake scenario, which is a two-dimensional array with the shape (number of storeys, number of time steps), where each element represents the physical response value of that floor at that moment.

[0025] b. Displacement Texture Encoding: Encode the response data of all buildings in the entire data chunk into a PNG-format displacement texture image. The script first calculates the total number of floors sum_floors of all buildings in the chunk. Then, it creates an image with a height of the number of time steps, a width of 1 + sum_floors, and RGBA channels. Fill the image column by column: The 0th column is the ground floor (no displacement); starting from the 1st column, fill in the time-series response data of each floor of each building in sequence. 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 drift angle. The data is linearly mapped to the 8-bit integer range ([0, 255]) for storage in the PNG. This texture image contains all the dynamic information of the data chunk under this earthquake scenario.

[0026] The Block Dynamic Data Management and Scheduling Module dynamically loads or unloads the JSON data chunks generated by the offline data preprocessing and chunk organization module based on the user's viewpoint using a dual-boundary control and frustum culling algorithm, manages network requests through a concurrent control queue, and unloads data into the LRU cache. The dual-boundary control mechanism includes constructing a loading and unloading determination system using differential boundary thresholds. When the extended bounding box of the data chunk enters the inner boundary, preloading is triggered, and when it completely moves out of the outer boundary, the unloading operation is executed to avoid frequent IO operations caused by small viewpoint movements. The frustum culling algorithm includes constructing a three-dimensional frustum based on the camera viewpoint, accurately determining the intersection relationship between the data chunk and the visible area through spatial geometric calculations, and loading or maintaining the data chunks within the frustum.

[0027] Specifically, the chunk dynamic data management and scheduling module, based on the user's viewpoint (camera) information and the double boundary control and frustum culling algorithms, determines in real time which data chunks need to be loaded or unloaded. For the data chunks that need to be loaded, it initiates a request through the concurrent control queue to obtain the corresponding data chunk JSON file and displacement texture PNG file. For the data chunks that need to be unloaded, their rendering resources will be released and put into the LRU cache. This module is responsible for managing the lifecycle of the data, ensuring that only the buildings visible to the user exist in memory.

[0028] 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).

[0029] Double boundary control: To avoid frequent loading and unloading when the viewpoint moves slightly, the manager uses a differentiated double boundary. A smaller inner boundary (marginIn, e.g., 150 meters) is used to trigger loading, and a larger outer boundary (marginOut, e.g., 200 meters) is used to trigger unloading. Only when the extended bounding box of the data chunk completely moves outside the outer boundary will it be unloaded.

[0030] LRU cache mechanism: The mesh model of the unloaded data chunk is not immediately destroyed but is put into a cache pool (chunkCache) with a timestamp. When the data chunk needs to be reloaded, the system first checks the cache. If the cache exists and has not exceeded the preset lifecycle (cacheLifetime, e.g., 30 seconds), it will be directly restored from the cache, avoiding the overhead of network requests and geometry reconstruction. Expired cache entries will be completely destroyed to release resources.

[0031] Concurrent loading control: To prevent excessive network requests from causing browser or network congestion, the manager has a built-in load queue (loadQueue) and a concurrent limit (maxConcurrentLoads, e.g., 8). When the concurrent requests reach the upper limit, new loading tasks will enter the queue and wait to be intelligently scheduled and executed by the manager.

[0032] The GPU accelerated rendering module is used to receive the data chunks output by the offline data preprocessing and chunk organization module, execute geometry merging to generate a single buffered geometry, assign unique identifiers to the vertices through the global floor index mapping, and finally submit the merged model to the GPU to achieve real-time rendering of the building form in cooperation with the displacement texture and custom shaders.

[0033] Specifically, the GPU-accelerated rendering module is responsible for efficiently rendering the loaded data blocks. It receives the data of the loaded data blocks from the chunk dynamic data management and scheduling module. Inside the module, geometry merging is performed, and a unique floor identifier is assigned to each vertex through the global floor index mapping. Finally, the merged single mesh model is submitted to the Graphics Processing Unit (GPU) for rendering.

[0034] This module aims to merge the rendering tasks of hundreds or thousands of buildings within the same data block into a single rendering call instruction.

[0035] Geometry merging: When a data block is loaded, the system traverses all the buildings within the block and merges their three-dimensional geometry data (vertex positions, colors, etc.) into a single, huge buffered geometry (BufferGeometry) on the CPU side.

[0036] Global floor index mapping: During the process of merging geometries, the system creates an additional custom attribute - the global floor index (floorIndex) for each vertex. This index is a floating-point number used to uniquely identify the floor to which the vertex belongs. Its generation rule is as follows: The system maintains a runtime floor offset (floor offset), starting from 1. For the first building within the block (assuming it has N floors), the floorIndex of the vertices on its floors from 1 to N are sequentially assigned values from the floor offset to the floor offset + N - 1. Subsequently, the floor offset is increased by N. Then, 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, the non-ground floors of all buildings within a data block have continuous and unique floor attributes starting from 1.

[0037] The GPU parallel displacement animation module is deeply coupled to the GPU rendering pipeline and is used to perform parallel sampling of displacement textures using the vertex global floor index, and to calculate and inject the vertex displacement and color values into the rendering pipeline in real time.

[0038] Specifically, the GPU parallel displacement animation module is responsible for implementing the real-time dynamic effects of 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 chunk dynamic data management and scheduling module, as well as the current animation time step. In the vertex shader, this module samples the displacement texture using the global floor index of the vertex and the current time step, and calculates the real-time displacements and dynamic colors of all vertices in parallel, and directly applies them to the rendering.

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

[0040] Displacement Texture Encoding: In the data preprocessing stage, 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 aforementioned global floor index, and the V-axis (vertical axis) corresponds to the time steps of the seismic simulation. Different color channels (RGBA) of each pixel in the texture are used to store different physical quantities.

[0041] Vertex Shader Real-time Displacement Calculation: During rendering, this displacement texture, along with uTimeStep, the total number of floors (uSumFloors), the total number of time steps (uTimeSteps), etc., is passed as uniform variables to a custom vertex shader. The shader performs the following operations for each vertex: Read the floorIndex attribute carried by the vertex.

[0042] If floorIndex is greater than 0 and the animation is enabled, calculate the corresponding UV sampling coordinates on the displacement texture based on floorIndex and uTimeStep.

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

[0044] Denormalize the displacement value and apply it to the original coordinates of the vertex in real time to complete the dynamic update of the building form.

[0045] The entire calculation process is executed in parallel for all vertices on the GPU, achieving a smooth and stutter-free seismic response animation for a super-large-scale building complex.

[0046] Efficient Interaction Module: It is used to implement ray tracing to solve the building instance ID by instantiating a picking grid, obtain metadata by combining with a pre-built building data mapping table, maintain a tag pool using DOM reuse technology, and dynamically update the tag content and coordinates to achieve three-dimensional interaction.

[0047] Specifically, the efficient interaction module is responsible for handling user interaction operations. When a user input (such as mouse movement or click) occurs, an efficient ray tracing is performed using a globally unique and invisible single-instantiated picking grid to quickly identify the building instance ID pointed to by the user. The static metadata of the building is obtained by querying the building data mapping table. It is efficiently displayed to the user in the form of interactive information tags in the three-dimensional scene through the DOM reuse tag pool.

[0048] Single instantiated picking mesh: The system creates a globally unique and invisible InstancedMesh and places it in a dedicated picking layer. For each building loaded in the scene, instead of creating independent picking objects, the system creates a simple proxy geometry instance (such as a cube) for it in this InstancedMesh, scales and positions it to match the original building. At the same time, in a global building data mapping table, the mapping relationship between the building unique identifier and its instance ID and other metadata (such as the associated chunk key, floor index range, etc.) is stored. When the user clicks, ray tracing only intersects with this single InstancedMesh, and the instanceId of the hit instance can be quickly returned, and all the information of the building can be found through the mapping table with O(1) complexity.

[0049] DOM reuse label pool: To avoid performance issues caused by frequently creating and destroying DOM elements when displaying building information, the present invention implements a label pool. This pool creates a CSS2DObject and its associated div label during initialization and permanently adds them to the scene. When a label needs to be displayed, the system only updates the internal text content (innerHTML) of this single div and the 3D spatial position of the attached CSS2DObject, and sets it to visible. When it is not needed to be displayed, it is set to invisible (display: 'none'). This reuse mechanism greatly improves the display performance of interactive labels.

[0050] This application also provides a visualization method for earthquake disaster simulation of urban building groups based on the foregoing system, and the method includes: S1: The offline data preprocessing and chunk organization module divides data chunks according to a preset grid size to generate JSON metadata containing building geometric information and URL of the scene displacement texture; for each earthquake scene, a PNG displacement texture is generated, and the displacement values and inter-story drift angle values of each floor time step are normalized and written into the R / G channels respectively. The S1 includes: Implement the spatial chunking and metadata generation sub-step: Divide the urban building data according to a 200m×200m grid, and generate a JSON file containing building geometric information and multi-scene metadata for each non-empty data chunk. The multi-scene metadata maps the displacement texture URL with the scene ID as the key value; Execute the displacement texture generation sub-step: Independently generate displacement textures in PNG format for each seismic scenario. Construct a canvas by calculating the total number of global floors, and normalize the displacement values of each floor time step and the inter-story drift angle values according to the predetermined floor index mapping rules, and then write them into the R / G channels respectively. Finally, export them as displacement texture files.

[0051] S2: Initialize the ChunkManager through the block dynamic data management and scheduling module to load the data block list; detect the change of the camera position, and adopt a dual boundary control mechanism to realize the on-demand loading / unloading of data blocks; use a concurrent queue to execute the loading task, and optimize the memory usage through the LRU cache. The S2 includes: Initialize the ChunkManager instance and load the data block URL list; Detect the change of the camera position at a fixed period, and adopt an internal and external dual boundary control mechanism to determine the loading / unloading state of the data block; Execute the loading task through a concurrent control queue, store the unloaded grid in an LRU cache pool with a life cycle, and realize the on-demand dynamic scheduling and memory optimization of the data block.

[0052] S3: After verifying the data block through the GPU accelerated rendering module and the GPU parallel displacement animation module, preferentially restore the mesh model from the cache. When constructing a single mesh model, generate a globally unique index for the vertices, configure a custom ShaderMaterial material, bind the displacement texture and time parameters, and drive the animation step through a time controller in the rendering loop, triggering the GPU vertex shader to execute displacement calculations. The S3 includes: Implement data block loading verification, preferentially restore the valid mesh model from the LRU cache, and asynchronously obtain the JSON metadata and corresponding displacement texture of the missing data block; Enable the floor offset mechanism when constructing a single mesh model, generate a globally unique floorIndex attribute for each vertex, and aggregate the building geometric data through a geometry merging tool; Configure a custom ShaderMaterial material, bind the displacement texture, the total number of floors, and the time step; In the main rendering loop, drive the animation step through a time controller, and update the uTimeStep parameter in real time to trigger the GPU vertex shader to execute displacement calculations and dynamic rendering.

[0053] S4: Create a global instantiated pick-up grid through the efficient interaction module and establish a building identification mapping; implement ray tracing in response to a mouse event to obtain the instance ID, query the metadata through the instance ID, and call the DOM reuse tag pool to display the static metadata and dynamic calculation results. The S4 includes: Develop a CPU-side displacement texture sampler: Locate the corresponding displacement texture according to the unique identifier assigned to each building instance; Calculate the texture coordinates corresponding to the current time step; Perform bilinear interpolation sampling to obtain the normalized displacement value and the inter-story displacement angle; Perform anti-normalization calculation: actual displacement = sampling value × maximum allowable displacement value.

[0054] The S4 includes: Create a global instantiated picking grid and establish a mapping table between the building unique identifier and the instance ID; Implement ray tracing in response to the mouse event, convert the screen coordinates into a three-dimensional ray and intersect it with the picking grid, and return the instanceId of the hit instance; Query the global mapping table through the instanceId to obtain the building metadata, and execute the CPU-side displacement texture sampling to calculate the dynamic response value; Call the DOM reuse tag pool update mechanism, integrate the static metadata and the dynamic calculation results, and accurately position and display the interactive information tag in the three-dimensional scene.

[0055] Next, a detailed description of each step is given: The first step: Data preprocessing and organization Spatial partitioning and metadata generation: Divide the urban building data into 200-meter × 200-meter grids, and generate a JSON file for each non-empty data block. This file contains the geometric information (outline coordinates, number of floors, etc.) of all buildings within the block and multi-scene information. The multi-scene information is an object with the scene ID as the key and the metadata under that scene as the value, including the corresponding displacement texture URL.

[0056] Displacement texture generation: For each earthquake scene, generate a displacement texture independently. Traverse all buildings and calculate the total number of floors globally. Create a canvas with a width equal to the total number of floors globally and a height equal to the number of time steps. After normalizing the displacement value and the inter-story displacement angle value of each floor at each time step according to the aforementioned global floor index mapping rule, draw them to the R channel and G channel of the corresponding pixel respectively. Finally, export the canvas as a PNG image.

[0057] The second step: System operation and dynamic scheduling Chunk manager initialization: After the system starts, initialize an instance of the ChunkManager and load the list containing all data block URLs.

[0058] On-demand loading and unloading: The manager detects changes in the camera position at fixed intervals (such as 60 ms). It determines the data blocks that need to be loaded and unloaded based on the dual internal and external boundaries (marginIn, marginOut). The loading tasks enter the concurrent control queue for execution. The unloaded meshes are stored in the LRU cache.

[0059] Step 3: Implementation process of rendering and animation Data block loading: When a data block is scheduled for loading, the system first checks if it exists in the LRU cache. If the cache hit is valid, it directly restores its 3D mesh model; if the cache miss or expiration occurs, the system asynchronously fetches the JSON metadata file corresponding to the data block from the server and, based on the currently active seismic scene ID, also fetches its exclusive displacement texture image.

[0060] Construction of a single mesh model and injection of geometric information: The system starts a construction process of "creating a building complex from a data block". The core functions of this process are: First, it traverses all the buildings included in the data block JSON file and generates 3D geometry data for each building.

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

[0062] After the geometry data of all independent buildings are collected, a dedicated tool module for "geometry merging" aggregates these scattered geometric data and finally generates a single mesh model that includes all the buildings within the block but is structurally unified.

[0063] Custom rendering material and shader parameter configuration: For the merged mesh model generated in the previous step, the system creates a custom shader material (ShaderMaterial). Subsequently, the loaded displacement texture image is assigned to a uniform variable named uDisplacementMap in this material. At the same time, other key parameters, such as the total number of floors in this data block and the total number of time steps of the animation, are also set to the corresponding uniform variables in the material for subsequent GPU calculations.

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

[0065] Step 4: Implementation Process of Interactive Information Query Creation and Mapping of Pickup Agent Instances: While loading data blocks and constructing their rendering models, the data block manager calls a "add building" function of the "building pickup manager". After receiving the building data, this function does not create independent pickup objects, but creates a geometric proxy instance for the building in a globally unique and invisible instanced mesh. At the same time, in a global mapping table inside the pickup manager, it records the association between the unique identifier of the building and the instance ID (instanceId) corresponding to it in the instanced mesh.

[0066] Ray Tracing and Target Recognition: When the user moves the mouse on the screen, a "intersection point detection" function is triggered. This function converts the two-dimensional screen coordinates of the mouse into a ray in three-dimensional space and performs efficient ray tracing calculations specifically for the particular instanced mesh that holds all pickup agents. Once the ray intersects with an instance, this function can immediately return the instanceId of the hit instance.

[0067] Information Query and Visual Presentation: The system uses the instanceId obtained in the previous step to quickly query in the global mapping table of the building pickup manager, thereby obtaining all the static metadata of the selected building.

[0068] If it is necessary to display the precise dynamic response value of the building at the current moment (for example, the specific number of millimeters of the top floor displacement), the system will call a "displacement value calculation" function. This function calculates the required value by precisely sampling the displacement texture at the pixel level on the CPU side.

[0069] Finally, the system calls a "create or update label" function of the label pool, integrates the queried static and dynamic information, updates it to the reusable DOM elements, and positions them at the corresponding locations of the buildings in the three-dimensional scene, presenting them to the user in the form of labels.

[0070] Figure 2 Schematic diagram of the display effect of the response of building groups in a large-scale area Figure 3 Schematic diagram of the display effect of the response of building groups in a local area. Each grid represents a building structure, the color of the grid vertices represents the inter-story displacement response of each layer of the structure, and the position of the grid vertices represents the absolute displacement response of each layer of the structure; red represents a larger response value, and green represents a smaller response value. When the user selects a specific grid, a blue label is displayed and the building name and response information at the current time step are shown.

[0071] In summary, compared with the prior art, the technical solution proposed by the present invention has the following remarkable beneficial effects: Break through the performance bottleneck of ultra-large-scale scenarios: By combining geometry merging and GPU instancing rendering, the rendering batches are minimized, enabling real-time and smooth rendering and roaming of building groups in the order of millions, with rapid interaction responses.

[0072] Achieve efficient real-time dynamic animation: By encoding massive time-series displacement data into textures and using GPU vertex shaders for parallel computing, real-time and smooth animation simulation of the seismic responses of all buildings is realized, solving the performance bottleneck of traditional CPU computing methods.

[0073] Greatly reduce the memory and video memory occupancy: Based on the frustum and double-boundary block dynamic loading and unloading mechanism, combined with the LRU cache strategy with a life cycle, it is ensured that the system only processes the necessary data within the field of view, enabling the system to run ultra-large-scale urban models with limited memory resources.

[0074] Provide an efficient and accurate interaction experience: Based on the picking scheme of a single instanced grid, rapid picking of massive buildings in milliseconds is achieved; combined with the DOM reuse tag pool, a delay-free information tag display is provided, and the interaction experience is smooth and natural.

[0075] Have good scalability and flexibility: By dynamically replacing displacement textures, rapid hot switching between multiple seismic scenarios is realized, facilitating comparative analysis under different disaster scenarios, and providing 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 in that, The system includes: An offline data preprocessing and chunk organization module, which is used to receive the original GIS data and seismic response data, construct a spatial chunk data structure after cleaning and transformation, generate JSON data chunks containing building geometric information and multi-channel displacement textures, and finally output a metadata file containing the URL mapping of the data chunks; A chunk dynamic data management and scheduling module, which dynamically loads or unloads the JSON data chunks generated by the offline data preprocessing and chunk organization module based on the user's view point using the double boundary control and frustum culling algorithms, manages network requests through a concurrent control queue, and stores the unloaded data in the LRU cache; A GPU accelerated rendering module, which is used to receive the data chunks output by the offline data preprocessing and chunk organization module, perform geometry merging to generate a single buffered geometry, assign unique identifiers to the vertices through the global floor index mapping, and finally submit the merged model to the GPU to cooperate with the displacement texture and custom shader to achieve real-time rendering of the building form; A GPU parallel displacement animation module, which is deeply coupled to the GPU rendering pipeline, and is used to perform parallel sampling of the displacement texture using the vertex global floor index, and solve the vertex displacement amount and color value in real time and inject them into the rendering pipeline; An efficient interaction module, which is used to perform ray tracing through the instantiated picking grid to solve the building instance ID, obtain metadata by combining the pre-built building data mapping table, maintain the tag pool using the DOM reuse technology, and dynamically update the tag content and coordinates to achieve three-dimensional interaction.

2. The system according to claim 1, wherein The GIS data contains building outline and height information, the JSON file contains at least the chunk index, chunk boundary coordinates and building list, and the metadata file contains at least the data chunk URL list and the mapping relationship between the scene ID and the displacement texture URL.

3. The system according to claim 1, characterized in that, The double boundary control mechanism includes constructing a loading and unloading determination system using different boundary thresholds. When the extended bounding box of the data chunk enters the inner boundary, preloading is triggered, and when it completely moves out of the outer boundary, the unloading operation is performed, which is used to avoid frequent IO operations caused by small view point movements.

4. The system according to claim 1, wherein The frustum culling algorithm includes constructing a three-dimensional frustum based on the camera view point, accurately determining the intersection relationship between the data chunk and the visible area through spatial geometric calculations, and performing loading or holding processing on the data chunks within the frustum.

5. A visualization method for earthquake disaster simulation of urban building complexes, characterized in that, Using the system according to any one of claims 1 to 4, the method steps are as follows: S1: Divide the data chunks by the offline data preprocessing and chunk organization module according to the preset grid size, generate JSON metadata containing building geometric information and the URL of the scene-based displacement texture; generate PNG displacement textures for each seismic scene, and normalize the displacement values of each floor time step and the inter-story displacement angle values and write them into the R / G channels respectively; S2: Initialize the ChunkManager by the chunk dynamic data management and scheduling module to load the data chunk list; detect the change of the camera position, and use the double boundary control mechanism to achieve on-demand loading / unloading of the data chunks; execute the loading task using the concurrent queue, and optimize the memory usage through the LRU cache; S3: After validating the data block through the GPU accelerated rendering module and the GPU parallel bitshift animation module, preferentially restore the mesh model from the cache. When constructing a single mesh model, generate a globally unique index for each vertex, configure a custom ShaderMaterial material, bind the displacement texture and time parameters, and drive the animation step through the time controller in the rendering loop to trigger the GPU vertex shader to perform displacement calculations; S4: Create a globally instantiated pick-up mesh through the efficient interaction module and establish a building identification mapping; implement ray tracing in response to a mouse event to obtain the instance ID, query the metadata through the instance ID, and call the DOM reuse tag pool to display the static metadata and dynamic calculation results.

6. The method according to claim 5, wherein The S1 includes: Implement the spatial partitioning and metadata generation sub-step: Divide the urban building data into 200m×200m grids, and generate a JSON file containing building geometric information and multi-scenario metadata for each non-empty data block. The multi-scenario metadata maps the displacement texture URL with the scene ID as the key value; Execute the displacement texture generation sub-step: Independently generate a PNG format displacement texture for each earthquake scenario, construct a canvas by calculating the total number of floors globally, normalize the displacement values of each floor time step and the inter-story displacement angle values according to the predetermined floor index mapping rule, and finally export them as displacement texture files.

7. The method according to claim 5, characterized in that, The S2 includes: Initialize the ChunkManager instance and load the data block URL list; Detect the change of the camera position at a fixed period, and use the internal and external double boundary control mechanism to determine the data block loading / unloading state; Execute the loading task through the concurrent control queue, deposit the unloaded mesh into the LRU cache pool with a life cycle, and realize the on-demand dynamic scheduling and memory optimization of the data block.

8. The method according to claim 5, wherein The S3 includes: Implement data block loading verification, preferentially restore the valid mesh model from the LRU cache, and asynchronously obtain the JSON metadata and corresponding displacement texture of the missing data block; Enable the floor offset mechanism when constructing a single mesh model, generate a globally unique floorIndex attribute for each vertex, and aggregate the building geometric data through the geometry merging tool; Configure a custom ShaderMaterial material, bind the displacement texture, the total number of floors, and the time step; In the main rendering loop, drive the animation step through the time controller, and update the uTimeStep parameter in real time to trigger the GPU vertex shader to perform displacement calculations and dynamic rendering.

9. The method according to claim 5, characterized in that, The S4 includes: Create a globally instantiated pick-up mesh, and establish a mapping relationship table between the unique building identifier and the instance ID; Implement ray tracing in response to a mouse event, convert the screen coordinates into a three-dimensional ray and intersect with the pick-up mesh, and return the instanceId of the hit instance; Query the global mapping table through the instanceId to obtain the building metadata, and execute the CPU-side displacement texture sampling calculation to obtain the dynamic response value; Call the DOM reuse tag pool update mechanism, integrate the static metadata and the dynamic calculation results, and accurately position and display the interactive information label in the three-dimensional scene.

10. The method according to claim 9, wherein The S4 includes: Develop a CPU-side displacement texture sampler: Locate the corresponding displacement texture according to the unique identifier assigned to each building instance; Calculate the texture coordinates corresponding to the current time step; Perform bilinear interpolation sampling to obtain the normalized displacement value and the interlayer displacement angle; Perform anti-normalization calculation: actual displacement = sampled value × maximum allowable displacement value.

Images