Map element collision detection method, device, equipment and program product

By detecting changes in screen state in a 3D electronic map and performing collision detection only when map features are stable, the problem of excessive resource consumption in existing technologies is solved, resulting in lower power consumption and higher rendering accuracy, thus improving the user experience.

CN116363082BActive Publication Date: 2026-01-23ALIBABA (CHINA) CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202310253343.8
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2023-03-10
Publication Date
2026-01-23
Estimated Expiration
2043-03-10

AI Technical Summary

Technical Problem

Existing technologies perform collision detection for every frame of a 3D electronic map during rendering, leading to excessive resource consumption on user devices, resulting in lag, overheating, and a poor user experience.

Method used

By detecting changes in the state of the electronic map currently displayed on the screen, collision detection is performed only when map features are stable. Depth data of map features of a preset type is read and compared with the depth data of points of interest (POIs) to determine whether to render the POI, thereby reducing the frequency of collision detection.

Benefits of technology

It reduces resource consumption on user devices, avoids map rendering lag and device overheating, improves user experience, and ensures the accuracy of map rendering results.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116363082B_ABST
    Figure CN116363082B_ABST
Patent Text Reader

Abstract

The application provides a map element collision detection method, device, equipment and program product. The method comprises the following steps: detecting the state change of the electronic map currently displayed on the screen; when the state change indicates that the map elements in the electronic map to be displayed are different from the map elements in the currently displayed electronic map and the map elements in the electronic map to be displayed are stable, performing collision detection at least when the electronic map to be displayed is displayed on the screen, comprising the following steps: reading the depth data of the map elements of a preset type from the rendering data of the electronic map to be displayed, wherein the preset type does not include the points of interest; determining the depth data of the points of interest in the electronic map to be displayed; comparing the depth data of the map elements of the preset type with the depth data of the points of interest to obtain the points of interest which need to be displayed in the electronic map to be displayed. The application can reduce the resource consumption of the user equipment, thereby avoiding the problems such as map rendering lag and user equipment heating.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of map rendering technology, and in particular to a collision detection method, apparatus, device, and program product for map elements. Background Technology

[0002] With the development of location-based services, electronic maps are being used in more and more scenarios. Electronic maps are the digital representation of the real world. Users can browse and query locations in the real world, such as shopping malls, hotels, bus stops, shops, and residences, through electronic maps displayed on their device screens. Among these, shopping malls, hotels, bus stops, shops, and residences are usually referred to as Points of Interest (POIs) in electronic maps. POIs are a type of map element in electronic maps, which also include map elements such as roads, green spaces, and waterways.

[0003] The electronic map displayed on the user's device screen is related to the user's browsing location. When there are many points of interest (POIs) around the user's browsing location, in order to avoid occlusion problems between POIs or between POIs and other map features (such as buildings, trees, roads, etc.), existing technologies perform collision detection on the map features in the electronic map before displaying the electronic map on the user's device screen. That is, they detect map features with occlusion problems and process the occluded map features to solve the problem of poor user experience caused by occlusion.

[0004] As the display effect of electronic maps evolves from two-dimensional to three-dimensional, the resource consumption of map rendering on user devices is also increasing. If a collision detection is performed every time a frame of electronic map is rendered, it will result in a very large consumption of user device resources, causing problems such as map rendering lag or user device overheating. Summary of the Invention

[0005] The main objective of this application is to provide a collision detection method, apparatus, device, and program product for map elements, which can reduce the resource consumption of user devices, thereby avoiding problems such as map rendering lag or user device overheating, and improving the user's service experience.

[0006] In a first aspect, embodiments of this application provide a collision detection method for map features, comprising:

[0007] Detecting changes in the state of the currently displayed electronic map on the screen, and when the state change indicates that the map features in the electronic map to be displayed are different from those in the currently displayed electronic map and the map features in the electronic map to be displayed are stable, collision detection is performed at least when the electronic map to be displayed is displayed on the screen. The collision detection includes:

[0008] From the rendering data of the electronic map to be displayed, read the depth data of map features of a preset type, wherein the preset type does not include points of interest;

[0009] Determine the depth data of points of interest in the electronic map to be displayed;

[0010] The depth data of the map features of the preset type are compared with the depth data of the points of interest to obtain the points of interest that need to be displayed in the electronic map to be displayed.

[0011] Optionally, when it is detected that map features in the electronic map to be displayed are different from map features in the currently displayed electronic map, the method further includes:

[0012] The change duration is detected. Whenever the change duration reaches a preset detection duration but the map elements in the electronic map to be displayed are unstable, the collision detection is performed once. If the map elements in the electronic map to be displayed are unstable, the step of detecting the change duration is returned until the map elements in the electronic map to be displayed are stable. When the electronic map to be displayed is displayed on the screen, the collision detection is performed.

[0013] Optionally, detecting changes in the state of the electronic map currently displayed on the screen specifically includes:

[0014] Detect changes in the scale of the electronic map currently displayed on the screen or changes in the camera's status.

[0015] Optionally, if the scale state change is from a target scale to a scale different from the target scale, it means that the map elements in the electronic map to be displayed are different from the map elements in the currently displayed electronic map, and the target scale is the scale of the currently displayed electronic map.

[0016] Optionally, the camera state changes include orientation state changes and position state changes;

[0017] If the difference between the facing angle of the camera of the electronic map to be displayed and the facing angle of the camera of the currently displayed electronic map is greater than a preset angle threshold, it indicates that the map features in the electronic map to be displayed are different from the map features in the currently displayed electronic map.

[0018] Alternatively, if the distance between the location of the camera on the electronic map to be displayed and the location of the camera on the currently displayed electronic map is greater than a preset distance threshold, it indicates that the map elements in the electronic map to be displayed are different from the map elements in the currently displayed electronic map.

[0019] Optionally, the method further includes:

[0020] Based on the map data of the electronic map to be displayed, rendering data of the map elements included in the map data is generated. The rendering data includes: depth data, which corresponds to pixels.

[0021] Optionally, the graphics processing unit (GPU) generates rendering data of map features included in the map data based on the map data of the electronic map to be displayed;

[0022] The step of reading depth data of map features of a preset type from the rendering data of the electronic map to be displayed specifically involves:

[0023] The central processing unit (CPU) reads the depth data of map features of a preset type from the rendering data of the electronic map to be displayed generated by the graphics processing unit (GPU).

[0024] Secondly, embodiments of this application provide a collision detection device for map features, comprising:

[0025] The first detection module is used to detect changes in the status of the electronic map currently displayed on the screen;

[0026] The second detection module is used to trigger the collision detection module at least when the electronic map to be displayed is displayed on the screen, when the state change indicates that the map elements in the electronic map to be displayed are different from the map elements in the currently displayed electronic map and the map elements in the electronic map to be displayed are stable.

[0027] The collision detection module includes:

[0028] A depth data reading unit is used to read depth data of map features of a preset type from the rendering data of the electronic map to be displayed, wherein the preset type does not include points of interest;

[0029] The depth data calculation unit uses depth data to determine points of interest in the electronic map to be displayed;

[0030] The depth data comparison unit is used to compare the depth data of the preset type of map features with the depth data of the points of interest to obtain the points of interest that need to be displayed in the electronic map to be displayed.

[0031] Optionally, the device further includes: a third detection module;

[0032] The third detection module is used to detect the change duration when the map elements in the electronic map to be displayed are different from the map elements in the currently displayed electronic map. Whenever the change duration reaches a preset detection duration but the map elements in the electronic map to be displayed are unstable, the collision detection is performed once. If the map elements in the electronic map to be displayed are unstable, the step of detecting the change duration is returned until the map elements in the electronic map to be displayed are stable. When the electronic map to be displayed is displayed on the screen, the collision detection module is triggered.

[0033] Thirdly, embodiments of this application provide an electronic device, including:

[0034] At least one processor; and

[0035] A memory that is communicatively connected to the at least one processor;

[0036] The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, cause the electronic device to perform the method described in any of the above aspects.

[0037] Fourthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the methods described in any of the above aspects.

[0038] The collision detection method, apparatus, device, and program product for map elements provided in this application embodiment can detect changes in the state of the electronic map currently displayed on the screen. When the state change indicates that the map elements in the electronic map to be displayed are different from those in the currently displayed electronic map and the map elements in the electronic map to be displayed are stable, collision detection is performed at least when the electronic map to be displayed is displayed on the screen. Further, the collision detection includes: reading depth data of map elements of a preset type from the rendering data of the electronic map to be displayed, wherein the preset type does not include points of interest; determining the depth data of points of interest in the electronic map to be displayed; and comparing the depth data of the map elements of the preset type with the depth data of the points of interest to obtain the points of interest that need to be displayed in the electronic map to be displayed. This application determines whether collision detection is needed by detecting changes in the state of the currently displayed electronic map on the screen, instead of performing collision detection during the rendering process of each frame of the electronic map to update POIs, thus reducing performance consumption. If collision detection is determined to be performed, the depth data of map features of a preset type that do not include POIs are first read from the rendering data of the electronic map to be displayed. At the same time, the depth data of the POIs in the electronic map to be displayed is determined. Then, the depth data of the two are compared to determine whether to render the POI on the map. This makes collision detection more intuitive and effective, thereby ensuring the accuracy of map rendering results and improving the user's service experience. Attached Figure Description

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

[0040] Figure 1 This is a schematic diagram illustrating an application scenario according to an embodiment of this application;

[0041] Figure 2 A schematic flowchart illustrating a collision detection method for map features provided in an embodiment of this application;

[0042] Figure 3 This is a schematic diagram illustrating another application scenario provided by an embodiment of this application;

[0043] Figure 4 A flowchart illustrating another collision detection method for map elements provided in this application embodiment;

[0044] Figure 5 A schematic diagram of the structure of a collision detection device for map elements provided in an embodiment of this application;

[0045] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0046] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0047] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.

[0048] First, let me explain the terms used in this application:

[0049] Depth data represents the distance from map features in an electronic map to the camera. Since map features cover a certain number of pixels when displayed on the screen, each pixel covered by a map feature has a depth data or depth value. When the hardware performance of the terminal device performing map rendering is average, the depth data value needs to be converted into an RGB value.

[0050] In applications that rely on electronic maps, if the logic for displaying Points of Interest (POIs) lacks collision detection for pre-defined map elements (such as buildings and trees), especially in 3D maps, POIs located behind buildings will be displayed on top of those buildings. However, in the real world, users cannot see through buildings to access POIs behind them. This leads to confusion when users see POIs displayed on top of buildings in a 3D map, unsure whether the POI is inside or behind a building. Therefore, to ensure a good user experience, collision detection is necessary during electronic map rendering. This involves detecting map elements with occlusion issues and addressing them to resolve the poor user experience caused by occlusion.

[0051] However, as electronic maps have evolved from two-dimensional to three-dimensional displays, the resource consumption of map rendering on user devices has also increased. If collision detection is performed for every frame of electronic map rendered, it will lead to a significant drain on user device resources, causing problems such as map rendering stuttering or user device overheating. Therefore, existing technologies suffer from excessive user device resource consumption, resulting in stuttering or overheating during map rendering and a poor user experience.

[0052] In view of this, this application provides a collision detection method for map elements. In order to improve user experience, reduce user device resource consumption, and avoid problems such as map rendering stuttering or user device overheating, the method can determine whether collision detection is needed by detecting changes in the state of the electronic map currently displayed on the screen, instead of performing collision detection in the rendering process of each frame of the electronic map, thus reducing performance consumption. If collision detection is determined to be performed, the depth data of map elements of a preset type is read from the rendering data of the electronic map to be displayed and compared with the depth data of POIs in the electronic map to be displayed to determine the POIs that can be rendered on the electronic map. This makes the power consumption of collision detection lower and ensures the accuracy of map rendering results, thereby improving user experience.

[0053] The following details the process of performing collision detection between preset map elements (such as buildings, trees, etc., hereinafter referred to as objects, with buildings as an example) and POIs (such as shopping malls, hotels, bus stops, shops, residences, etc. in electronic maps).

[0054] Figure 1 This is a schematic diagram illustrating an application scenario involved in an embodiment of this application. For example... Figure 1 As shown, the collision detection method for map features provided in this application embodiment can be applied to, for example... Figure 1 In the application scenario shown, the scenario includes a user device. The user device has a client 101 (which can be an application / software) installed with electronic map rendering capabilities. The user views the electronic map through the client 101 to obtain the information they need (such as nearby restaurants or road details around a location, etc., without specific limitations). Rendering the electronic map on the user device's screen is typically performed by the logic processing unit 102 (e.g., CPU) within the user device, which performs the logical processing of the electronic map rendering data. The display chip 103 (e.g., GPU) within the user device then renders the electronic map onto the user device screen for viewing. Since the electronic map is a digital representation of the real world, it is necessary to ensure that the user's experience using the electronic map is consistent with the real world; for example, people should not be able to see geographical features obscured by buildings.

[0055] To ensure a good user experience when using electronic maps, this application implements a collision detection mechanism. When a user interacts with the electronic map currently displayed on their device screen, such as zooming in or out, the CPU detects this zooming operation and determines whether the operation causes a change in the electronic map to be displayed compared to the currently displayed map. If a change has occurred and the change is no longer ongoing (i.e., the map elements in the electronic map to be displayed are stable; the user's zooming operation has ended, meaning the user is no longer interacting with the electronic map), then collision detection is performed at least while the electronic map is being displayed on the screen. Therefore, this application's CPU determines whether to perform collision detection based on the state changes of the electronic map displayed on the user's device screen, eliminating the need for collision detection for every frame of the rendered map, thus reducing resource consumption on the user's device. The following detailed description of relevant embodiments of this application is provided in conjunction with the accompanying drawings.

[0056] Taking a 3D rendering scene of an electronic map as an example, when a user selects a 3D rendering scene through the client, the user can see a 3D electronic map on the screen. The user can drag, render, and zoom the electronic map. Based on the user's operations, the geographical features displayed in the rendered electronic map will change. In order to reduce the consumption of user device resources, this application determines whether to perform collision detection by detecting the changes in the state of the electronic map currently displayed on the screen. That is, it determines the timing of collision detection, rather than performing collision detection for every frame of the rendered electronic map.

[0057] Specifically, the CPU can detect changes in the state of the currently displayed electronic map and determine whether the map features in the electronic map to be displayed are the same as those in the currently displayed electronic map. If the detected state change indicates that the map features in the electronic map to be displayed are different from those in the currently displayed electronic map, the CPU will determine whether to perform collision detection based on the following two conditions:

[0058] Condition 1: If the map features in the electronic map to be displayed are stable, that is, the electronic map itself no longer changes, then the condition for performing collision detection is met, and collision detection can be performed.

[0059] Condition 2: Determine whether to trigger collision detection by detecting the duration of change: Whenever the duration of change reaches the preset detection duration but the map elements in the electronic map to be displayed are unstable (for example, the time interval between the current change state and the next change state reaches the preset time interval threshold), a collision detection is performed; if the map elements in the electronic map to be displayed are unstable, return to the step of detecting the duration of change until the map elements in the electronic map to be displayed are stable, indicating that the map elements have changed from change to no change. Therefore, when displaying the electronic map to be displayed on the screen, collision detection is performed.

[0060] As mentioned earlier, changes in map elements in the electronic map usually occur when the user performs an operation on the currently displayed electronic map on the screen. Since user operations are generally short-lived, to ensure that there are no conflicts in the electronic map seen by the user on the screen, condition 1 has higher priority than condition 2. That is, once the user stops operating on the screen, collision detection must be performed on the electronic map to be rendered. If the user's operation on the electronic map takes a long time, such as exceeding the preset time interval threshold, to ensure that there are no conflicts in the electronic map rendered during the process, a collision detection step needs to be performed every preset time interval threshold during the process.

[0061] The collision detection process may include: based on a pre-set configuration table, reading the depth data of map features of a preset type that do not include POIs from the rendering data of the electronic map to be displayed, then obtaining the depth data of POIs in the electronic map to be displayed, comparing the depth data of the two, and then determining which POIs need to be displayed in the electronic map and which POIs do not need to be displayed.

[0062] For example, in combination Figure 2 As shown, Figure 2 This is a schematic flowchart illustrating a collision detection method for map features provided in an embodiment of this application. Figure 2 The diagram illustrates a 3D rendering scene of an electronic map, including map feature and POI updates, collision detection triggering, collision detection execution, and 3D map rendering display. Specifically, when a user interacts using a client (e.g., an electronic map client), collision detection of map features based on map rendering can be achieved synchronously and interactively through multi-threading (at least including a rendering thread and a logic thread; the logic thread runs on the CPU, and the rendering thread runs on the GPU): On the logic thread, based on the detected current scene (here referring to the 3D rendering scene), it first determines the buildings in the current scene that need to be collided with (here referring to the buildings closest to the camera that are occluded with POIs and need to be rendered) based on the map feature types that need to be collided with recorded in a pre-set configuration table. The building is then marked in the rendering pipeline, added to the rendering pipeline, and its rendering information is updated.

[0063] On the rendering thread, based on the updated rendering information (or rendering data), the building is rendered, and its depth is converted into RGB color. Then, based on whether a request to read depth data from the CPU has been received, it is determined whether to send a command to the CPU to read depth data. If no request is received, no command is sent; if a request is received, the command is sent, and the RGB color data from the GPU is transferred to memory. The CPU updates the Point of Interest (POI), and during the POI update process, it reads the RGB color data to obtain the depth data of a preset type of map feature. Whether the CPU sends a request to read depth data is determined based on whether collision detection is performed. If the CPU determines to perform collision detection, it sends a command to the GPU to read depth data. Upon receiving this command, the GPU transfers the depth data to memory, allowing the CPU to read the depth data of a preset type of map feature from the rendering data, such as the depth data of the building.

[0064] Furthermore, during POI updates, the location of the POI's pixel is obtained by calling a predefined interface. Based on this location, the RGB color data of the POI's pixel is retrieved from the read RGB color data and converted into corresponding depth data. Then, based on the obtained POI coordinates and camera parameters, the updated POI's depth data (referring to the POI's depth data on the electronic map to be displayed) is calculated. The two depth data are then compared (i.e., comparing which is closer to the camera, the POI or the building) to determine if the POI is occluded. If the building's depth data is greater than the POI's depth data, the POI is in front of the building and is not occluded, requiring subsequent collision handling. If the building's depth data is less than the POI's depth data, the POI is behind the building. If the building's depth data is equal to the POI's depth data, the POI is inside the building. In both cases, the POI is considered occluded and is not displayed on the map.

[0065] For example, see Figure 3 As shown, Figure 3This is a schematic diagram of another application scenario provided by an embodiment of this application. A user obtains valuable map information about a certain area through a map operation interface in the client (e.g., the client's homepage interface 31) by triggering operations (e.g., input, click, swipe, drag, rotate, zoom, etc.): The user performs a first triggering operation on the client (when the user opens the homepage interface 31, the current homepage interface 31 displays an electronic map (or map) of the user's current location; the homepage interface can also display a first function key area 311 for interface switching, including function keys such as "Home," "Nearby," and "My," and the user can click any function key to switch to the corresponding function's interface), for example, entering a destination name (e.g., destination 1) in the pre-defined input box 312, and then clicking the query button to perform a map query of the location and surrounding environment (see...). Figure 3 As shown in (a), the client performs map rendering based on the first triggering operation, and displays the electronic map corresponding to the first triggering operation on the screen. Figure 1 (or place) Figure 1 (See also) Figure 3 As shown in (b), the electronic map also displays a description of the destination and a second function key area 321, including function keys such as "Nearby," "Navigation," and "Route." Users can click on these function keys to access corresponding services. If a user wants to view a specific area or location on the electronic map, they can perform a second trigger operation on the map, such as sliding or zooming. For example, regarding the sliding operation (see...),... Figure 3 As shown in (c), the map server sends the corresponding map data to the client, which then renders and displays the electronic map (e.g., including at least the building closest to the camera in the scene) in the map display area 32 on the device screen, corresponding to the second input operation: electronic map Figure 2 (or place) Figure 2 (See also) Figure 3 (as shown in d).

[0066] During the client's operation, the map server uses multi-threading technology to handle business logic and rendering based on the client's triggered operations. For example, the rendering thread runs on the display chip (e.g., GPU) to implement map rendering, while the logic thread runs on the logic processing unit (e.g., CPU) to implement business processes such as whether to perform collision detection, whether to update POIs, whether to notify the rendering thread to send depth data reading instructions, whether to read depth data, and whether to determine the rendering map features and POIs.

[0067] Specifically, when a user's second trigger operation is to drag, rotate, or zoom to view the desired electronic map, this electronic map can be a 3D rendered scene. That is, what the user sees on the screen is a 3D electronic map. Even when the user performs operations on this electronic map, they still see a 3D scene, but the content within the map differs. During dragging or rotating, the electronic map is in a changing state (i.e., the camera in the electronic map is moving), or during zooming, the electronic map is in a changing state (i.e., the scale of the electronic map changes). Therefore, to reduce CPU and GPU performance consumption, it is unnecessary to perform collision detection, POI update, and depth data processing logic in the logic thread every frame of the electronic map during rendering to determine whether to render map elements and POIs. Instead, the rendering can be based on changes in the state of the currently displayed electronic map. For example, if the state change indicates that the map elements in the electronic map to be displayed are different from those in the currently displayed electronic map, and the map elements in the electronic map to be displayed are stable, then collision detection is performed. This allows the POIs that need to be displayed in the electronic map to be shown to be obtained, and the rendered map elements and the POIs are then displayed on the electronic map.

[0068] If collision detection is determined, the POI update can be triggered immediately, and the logic thread sends a notification to the rendering thread indicating that the updated depth data of the building is allowed to be sent. The rendering thread sends a depth data read instruction to the logic thread. The logic thread reads the associated data of the depth data stored in the GPU (here, it refers to the RGB data converted from the depth data). That is, the GPU sends the associated data to the CPU's memory. Then, the CPU uses the information of the updated POI (such as the updated POI's 3D coordinates, the position of the updated POI's pixel, etc.) to determine whether the POI should be rendered and displayed.

[0069] When the user stops dragging, rotating, or zooming, and the map features in the electronic map stabilize for the first time, a forced update of the Point of Interest (POI) is performed. During the POI update process, the logic thread reads the depth data of the rendered buildings and performs POI occlusion detection based on the updated POI information to determine whether to render and display the POI. When the map features in the electronic map are not initially stable, collision detection is performed by detecting whether changes in the duration of change and / or changes in the scene scale or camera status meet preset conditions, thereby determining whether to render and display the POI.

[0070] In order to ensure the consistency of scene and depth data and the stability of collision effects when the map features of the electronic map are stable, the POI can be updated when the collision detection operation is triggered. By controlling the timing of triggering the POI update and the timing of reading the updated depth data, the logic thread can read the depth data of the building in the rendering thread and determine whether the updated POI is occluded by the building in a timely manner after the rendering thread renders the building. If it is not occluded, collision processing is performed and the POI is rendered in the map, that is, the POI is displayed; if it is occluded, the POI does not need to be rendered in the map, that is, the POI is not displayed.

[0071] Therefore, by identifying the map features that need to collide with POIs as described above, rendering those map features on the map, and determining whether to update the POI based on the current scene, instead of updating the POI every frame of the electronic map rendering process, performance consumption is reduced. If it is determined to update the POI, when the map features of the currently displayed electronic map are stable, the timing of triggering the POI update and the timing of reading the depth data of the map feature are controlled to process the depth data and the current scene, thereby determining whether to render the POI on the electronic map. This ensures that the depth data is consistent with the current scene when the POI is updated, making the collision effect stable, thus ensuring the accuracy of the map rendering results and improving the user's service experience.

[0072] It should be noted that the above-described steps, which determine whether collision detection is needed by detecting changes in the state of the currently displayed electronic map, and if collision detection is determined to be performed, involve comparing the depth data of preset map features (excluding POIs) read from the rendering data of the electronic map to be displayed with the depth data of the POIs in the electronic map to be displayed, to determine the POIs to be displayed in the electronic map. This is merely an illustrative example, and the process could also be achieved by splitting the data into more platforms and more modules. This application does not specifically limit this approach. Furthermore, the user information (such as location information), target objects, rendering information, location, and coordinates obtained are all authorized by the user.

[0073] The technical solutions of this application will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0074] For example, Figure 4This is a flowchart illustrating another collision detection method for map features provided in this application. This embodiment can be applied to any device capable of performing collision detection for map features, such as user equipment (or terminals). The following description uses buildings as an example to illustrate the collision detection method for map features. Figure 4 As shown, the collision detection method for map features may include:

[0075] S401. Detect the state change of the electronic map currently displayed on the screen. When the state change indicates that the map elements in the electronic map to be displayed are different from the map elements in the currently displayed electronic map and the map elements in the electronic map to be displayed are stable, perform collision detection at least when the electronic map to be displayed is displayed on the screen.

[0076] Here, stability means that the electronic map to be displayed no longer changes, because dragging, zooming, and rotating all involve a process, while electronic maps... Figure 1 The system renders dozens of frames per second. When the final displayed electronic map shows little difference from the previously displayed electronic map, the elements are considered stable. Stability is determined by camera parameters; small changes in angle or distance are considered stable. Because electronic maps... Figure 1 Dozens of frames are rendered per second. The electronic map currently displayed in this application refers to the electronic map displayed on the screen before collision detection is performed, and does not refer to a specific frame of the electronic map.

[0077] Specifically, this process is executed by the CPU: by detecting changes in the state of the currently displayed electronic map on the screen, it determines whether to perform collision detection. Collision detection is not required for every frame of rendering, thus reducing resource consumption on the user's device. If the map features in the electronic map to be displayed are different from those in the currently displayed electronic map, and the map features in the electronic map to be displayed are stable, then the conditions for performing collision detection are met. Therefore, collision detection is performed at least while the electronic map to be displayed is shown on the screen.

[0078] S402. Read the depth data of map features of a preset type from the rendering data of the electronic map to be displayed. The preset type does not include points of interest.

[0079] Specifically, this application embodiment is applied to 3D scenes. There will be a configuration table in advance, which records the types of map elements that need to be collision detected, such as buildings, trees, etc. The preset type of map elements (referring to the map elements corresponding to the map element types recorded in the configuration table) and POIs can be determined from the map elements of the electronic map.

[0080] Here, POIs can be one or more, and each POI needs to be checked for occlusion with map features of the preset type. Collision detection, taking buildings as an example, involves POIs either inside or outside a building. Since frequently reading depth data to update the scene can impact GPU performance, to reduce GPU performance consumption, it's unnecessary to read depth data every frame to update the scene. Instead, based on changes in the state of the currently displayed electronic map, the scene can be analyzed against the scene of the electronic map to be displayed to determine whether to perform collision detection, thereby achieving scene updates.

[0081] Optionally, the map features to be collided with must first be determined:

[0082] Based on the user's trigger operation on the map operation interface through the user device, the objects that need to be collided with (i.e. map elements) are marked, and the objects that need to be collided with are used as map elements to be collided with; wherein, the map elements to be collided with are the objects to be rendered that are closest to the camera in the map.

[0083] Based on the markers, update the rendering information of the map features to be collided.

[0084] Specifically, in combination Figures 1 to 3 As shown, users can trigger operations on the map operation interface provided by the client through their devices, such as dragging, rotating, or zooming the current electronic map. Based on these operations, the logic thread can determine the nearest object to the camera (such as a building to be rendered) based on the camera's parameters in the current scene. It then marks the building in the rendering pipeline and submits it. Since the map has many layers, but many layers do not require depth information (or depth data), unmarked objects do not need to have their depth data updated or be rendered, reducing user device performance consumption. Furthermore, building data includes several types, requiring the collection of all building types. This way, the marking alone is enough to determine if an object needs updating, thus updating the building's rendering information. After updating the building's rendering information, this updated information provides data for the rendering thread on how to render these buildings.

[0085] Optionally, the map features to be collided are rendered in the map, including:

[0086] The updated rendering information corresponding to the map feature to be collided is obtained, the depth data in the updated rendering information is converted into RGB data, and stored in the display chip.

[0087] In this embodiment, firstly, in the logic thread, based on the current electronic map (or current scene), the building closest to the camera that needs to be collided with is determined as the target object. Then, the building is placed into the rendering pipeline (also called the rendering pipeline or pixel pipeline, which is a parallel processing unit that processes graphics signals independently within the display chip. The rendering pipeline is used to improve the working capacity and efficiency of the graphics card) to update the building's rendering information (or rendering data). Then, the building is rendered in the rendering thread, and the depth data in the updated rendering information (here referring to the updated depth data of the building during the rendering process) is converted into RGB color data. The depth data (here referring to the depth value) is a single-precision floating-point number, while RGB consists of three integers from 0 to 255. After conversion, the data is stored in the texture.

[0088] Since the rendering operation is performed in the rendering thread (meaning it is handled by the GPU), and whether to display the POI is determined in the logic thread (meaning it is handled by the CPU), the depth data of the rendered buildings needs to be placed in memory for the CPU to process. By synchronizing the data across threads, the management of depth data can be made more reasonable.

[0089] Optionally, the graphics processing unit (GPU) generates rendering data of map features included in the map data based on the map data of the electronic map to be displayed;

[0090] The step of reading depth data of map features of a preset type from the rendering data of the electronic map to be displayed specifically involves:

[0091] The central processing unit (CPU) reads the depth data of map features of a preset type from the rendering data of the electronic map to be displayed generated by the graphics processing unit (GPU).

[0092] The rendering data is generated by the GPU, and the CPU reads the depth data from the GPU.

[0093] Optionally, based on the map data of the electronic map to be displayed, rendering data of the map elements included in the map data is generated, wherein the rendering data includes: depth data, and the depth data corresponds to pixels.

[0094] Specifically, this process is executed by the GPU: depth data is generated during GPU rendering of map features of a preset type. Here, the depth data refers to the updated depth data obtained during the process of updating the rendering information of map features. If it is determined that a Point of Interest (POI) needs to be updated, by controlling the timing of POI updates and the reading of map feature depth data, the depth data can be made consistent with the scene, achieving accurate collision detection between the POI and map features. The steps of the above-described collision detection method for map features ensure both performance and accuracy of the collision effect, thereby ensuring the accuracy of the map rendering results.

[0095] Optionally, the depth data is pixel-by-pixel.

[0096] S403. Determine the depth data of the points of interest in the electronic map to be displayed.

[0097] In this embodiment, collision detection is performed to determine the POIs to be displayed on the electronic map. Specifically, based on the latest map data downloaded from the server (referring to the coordinates of the POIs in the world coordinate system), the depth data of the POIs is calculated using the parameters of the camera in the currently displayed electronic map; that is, the depth data of the POIs in the electronic map to be displayed.

[0098] S404. Compare the depth data of the preset type of map elements with the depth data of the points of interest to obtain the points of interest that need to be displayed in the electronic map to be displayed.

[0099] In this embodiment, based on the position and depth data of the pixel where the POI is located, and combined with the updated depth data of map features of a preset type, it is determined whether the POI is occluded by the preset type of map features. If it is occluded, the POI is not displayed; if it is not occluded, collision handling is performed, and finally, the object and the POI are rendered and displayed. Therefore, by reading the depth data of the preset type of map features and comparing the depth of the POI with that of the preset type of map features—that is, comparing the relative positions of the camera—it is more intuitive and accurate to determine whether the POI is occluded by the preset type of map features. The collision handling is accurate, resulting in accurate rendering results.

[0100] Therefore, the collision detection method for map elements provided in this application embodiment can detect changes in the state of the electronic map currently displayed on the screen. When the state change indicates that the map elements in the electronic map to be displayed are different from those in the currently displayed electronic map and the map elements in the electronic map to be displayed are stable, collision detection is performed at least when the electronic map to be displayed is displayed on the screen. Further, the collision detection includes: reading depth data of map elements of a preset type from the rendering data of the electronic map to be displayed, wherein the preset type does not include points of interest; determining the depth data of points of interest in the electronic map to be displayed; and comparing the depth data of the map elements of the preset type with the depth data of the points of interest to obtain the points of interest that need to be displayed in the electronic map to be displayed. This application determines whether collision detection is needed by detecting changes in the state of the currently displayed electronic map on the screen, instead of performing collision detection during the rendering process of each frame of the electronic map to update POIs, thus reducing performance consumption. If collision detection is determined to be performed, the depth data of map features of a preset type that do not include POIs are first read from the rendering data of the electronic map to be displayed. At the same time, the depth data of the POIs in the electronic map to be displayed is determined. Then, the depth data of the two are compared to determine whether to render the POI on the map. This makes collision detection more intuitive and effective, thereby ensuring the accuracy of map rendering results and improving the user's service experience.

[0101] Optionally, when it is detected that map features in the electronic map to be displayed are different from map features in the currently displayed electronic map, the method further includes:

[0102] The change duration is detected. Whenever the change duration reaches a preset detection duration but the map elements in the electronic map to be displayed are unstable, the collision detection is performed once. If the map elements in the electronic map to be displayed are unstable, the step of detecting the change duration is returned until the map elements in the electronic map to be displayed are stable. When the electronic map to be displayed is displayed on the screen, the collision detection is performed.

[0103] The change duration starts counting from the moment a map element in the electronic map to be displayed is detected to be different from the map element in the currently displayed electronic map. Every time the count is 200ms, if the map element is still unstable, a collision detection is performed, and then the count is repeated for another 200ms.

[0104] Specifically, if the map elements in the electronic map to be displayed are different from those in the currently displayed electronic map, and the time interval between the detected differences in the map elements (i.e., the change duration) reaches a preset detection duration, such as being greater than or equal to a preset interval threshold, then when the map elements in the electronic map to be displayed are unstable, the collision detection is performed once. Since the map elements in the electronic map to be displayed are unstable, the step of detecting the change duration is returned until the map elements in the electronic map to be displayed are stable, and then the collision detection is performed again. That is, when the electronic map to be displayed is displayed on the screen, the collision detection is performed.

[0105] For example, if the map features in the electronic map to be displayed are different from those in the currently displayed electronic map, collision detection is performed if the map features in the electronic map to be displayed stabilize within 200ms. Otherwise, collision detection is performed every 200ms until the map features in the electronic map to be displayed stabilize, at which point a final collision detection is performed to ensure that the electronic map displayed stably on the screen does not store occlusion issues.

[0106] Optionally, detect changes in the status of the electronic map currently displayed on the screen, specifically including:

[0107] Detect changes in the scale of the electronic map currently displayed on the screen or changes in the camera's status.

[0108] In this embodiment, the scale of the electronic map changes through zooming; the camera status changes through dragging or rotating. Therefore, based on the changes in the scale of the electronic map or the camera status currently displayed on the screen, it can be determined whether to perform collision detection, eliminating the need for collision detection to be performed on every frame of the rendered map, thus reducing the consumption of user device resources.

[0109] Optionally, the camera state changes include orientation state changes and position state changes;

[0110] If the difference between the facing angle of the camera of the electronic map to be displayed and the facing angle of the camera of the currently displayed electronic map is greater than a preset angle threshold, it indicates that the map features in the electronic map to be displayed are different from the map features in the currently displayed electronic map.

[0111] Alternatively, if the distance between the location of the camera on the electronic map to be displayed and the location of the camera on the currently displayed electronic map is greater than a preset distance threshold, it indicates that the map elements in the electronic map to be displayed are different from the map elements in the currently displayed electronic map.

[0112] Here, distance refers to the pixel distance on the screen. For example, changes in orientation, such as changes in the facing angle.

[0113] Specifically, if the difference between the orientation angle of the camera on the electronic map to be displayed and the orientation angle of the camera on the currently displayed electronic map is greater than a preset angle threshold, it indicates that the camera orientation change has reached a certain value, meaning that the change data of the camera parameters in the electronic map between the two scenes meets the preset change conditions, and then collision detection is performed. If the distance between the position of the camera on the electronic map to be displayed and the position of the camera on the currently displayed electronic map is greater than a preset distance threshold, it indicates that the camera movement has reached a certain value, meaning that the change data of the camera parameters in the electronic map between the two scenes meets the preset change conditions, and then collision detection is performed.

[0114] Optionally, the collision detection method for map features can also determine whether to update the point of interest, and the method further includes:

[0115] The state of the electronic map when the update of the point of interest was triggered in the scene where the electronic map was last rendered, the time when the update of the point of interest was triggered in the scene where the electronic map was last rendered, and the current time are obtained.

[0116] Based on the current state of the electronic map, the state of the electronic map when the point of interest was last updated, and the time interval between the last time the point of interest was last updated and the current time, it is determined whether to update the point of interest.

[0117] In this embodiment, based on the current state of the electronic map, the decision to update the Point of Interest (POI) is determined by analyzing the scene from the last electronic map rendering. The scene from the last electronic map rendering may include the state of the electronic map when the POI update was triggered, the time of the last POI update, etc. Based on the current state of the electronic map, combined with the state of the electronic map when the POI update was triggered and / or the time interval between the last POI update and the current time, the decision is made whether to update the POI. For example, a free combination strategy can be used, such as whether the time interval reaches a preset threshold, or whether the changes in camera parameters in the electronic map between the two scenes meet preset change conditions, to determine whether to update the POI. If it is determined that the POI should be updated, the rendering thread sends a command to the logic thread to read depth data. The logic thread reads the depth data and, combined with the updated POI information, determines whether to render the POI.

[0118] By comprehensively analyzing the current scene from different perspectives, it is possible to determine whether to update the Point of Interest (POI). This ensures the effectiveness of POI updates and enables accurate rendering. If it is determined that the POI should be updated, the depth data of the building is read and compared with the depth value of the POI to determine whether to render and display the POI. The depth data in the rendering data is not used every frame, which reduces the GPU performance consumption caused by frequently updating the scene with depth data.

[0119] Optionally, determining whether to update the point of interest based on the current state of the electronic map, the state of the electronic map when the update was last triggered, and the time interval between the last time the update was triggered and the current time can be achieved in at least two of the following ways:

[0120] Method 1: Based on the current state of the electronic map and the state of the electronic map when the point of interest (POI) was last updated (e.g., the map features of the current electronic map were unstable and the map features of the electronic map were unstable when the POI was last updated, the map features of the current electronic map were unstable and the map features of the electronic map were stable when the POI was last updated, the map features of the current electronic map were stable and the map features of the electronic map were stable when the POI was last updated, the map features of the current electronic map were stable and the map features of the electronic map were unstable when the POI was last updated), determine whether to update the POI using a combination strategy of the time interval between the last time the POI was last updated and the current time, and the change data of the camera parameters in the image during the two scenes.

[0121] If the map features of the current electronic map are unstable, and the map features of the electronic map were unstable when the point of interest was last updated, then the time interval is compared with a preset interval threshold. If the time interval is greater than or equal to the preset interval threshold, then the point of interest is determined to be updated.

[0122] If the map features of the electronic map are unstable and the map features of the electronic map were stable when the point of interest was last updated, or if the map features of the current electronic map are stable and the map features of the electronic map were stable when the point of interest was last updated, then if the change data of the camera parameters in the electronic map in the two scenes meets the preset change conditions, or if the change data of the camera parameters in the electronic map in the two scenes does not meet the preset change conditions and the time interval is greater than or equal to the preset interval threshold, then it is determined to perform collision detection (determine to update the point of interest).

[0123] If the map features of the current electronic map are stable, and the map features of the electronic map were unstable when the last update of the point of interest was triggered, then it is determined to update the point of interest (determine to update the point of interest).

[0124] Specifically, it determines whether to update the POI or whether to send a command to read depth data. The criteria for this determination include:

[0125] a: Time interval. If the time interval between two read commands (or the time interval between two POI updates) is less than a preset threshold, such as 400 milliseconds, then the POI will not be updated and the read depth data command will not be sent, and thus the scene will not be updated;

[0126] b: Should the current scene enter a stable state? If so, determine whether criterion c holds true. If true, update the POI and send a command to read depth data, regardless of whether the interval reaches 400 milliseconds, thereby updating the scene. If not, determine whether to update based on step a.

[0127] If the current scene enters a stable state for the first time, that is, the previous scene was in a changing state (meaning the map elements of the electronic map were unstable), and the current scene is in a static state, then in order to ensure the consistency between the scene and the depth data, the timing for updating the POI and the timing for reading the depth data are determined to update the scene.

[0128] C: Whether the scene camera moves. Record the camera parameters when the scene (referring to the current scene and the scene from the last rendered electronic map) enters a stationary state and a read command is sent. If the camera moves or changes its orientation but does not reach a certain value, that is, the change data of the camera parameters in the electronic map between the two scenes does not meet the preset change conditions, then do not update; otherwise, update.

[0129] For example, firstly, time intervals are used to avoid sending a command to read depth data for every frame; secondly, when sending the command to read depth data, the current state of the camera is recorded. When the command is sent again, the state of the camera at that time is compared with the recorded state. If the state of the camera (position and orientation) has not changed much (movement distance not exceeding 2 pixels, orientation change not exceeding 1 degree, level scaling not exceeding 0.1), then the command to read depth data is not sent and the POI is not updated.

[0130] Therefore, this method 1 combines the current state of the electronic map with the state of the electronic map when the point of interest was last updated. Different processing logics or strategies are corresponding to different specific scenarios with different states. This targeted or differentiated processing method is more refined and can ensure the accuracy of whether to update the point of interest, thereby accurately determining whether to render the point of interest to ensure the accuracy of the rendering result.

[0131] Method 2: Based on whether the current state of the electronic map is the same as the state of the electronic map when the point of interest was last updated, determine the strategy for deciding whether to update the POI, and then determine whether to update the POI and read the depth data.

[0132] If the current state of the electronic map is different from the state of the electronic map when the point of interest was last updated, then the point of interest is to be updated.

[0133] If the current state of the electronic map is the same as the state of the electronic map when the point of interest was last updated, and the time interval is greater than or equal to a preset interval threshold and / or the change data of the camera parameters in the electronic map in the two scenes meet the preset change conditions, then the point of interest is determined to be updated.

[0134] Specifically, Method 2 will be explained in detail through the following three implementation methods:

[0135] Method 21: If the two states are different, directly determine to update the POI; if the two states are the same, determine whether the time interval has reached the preset threshold. If it has, update the POI; if it has not, do not update.

[0136] Method 22: If the two states are different, directly determine to update the POI; if the two states are the same, determine whether the changes in the camera parameters in the two scenes meet the preset change conditions. If they do, update; if they do not, do not update.

[0137] Method 23: If the two states are different, directly determine to update the POI; if the two states are the same, determine whether the changes in the camera parameters in the two scenes meet the preset change conditions and whether the time interval meets the preset threshold. If both are met, update the POI; if neither is met, do not update.

[0138] Therefore, the above three implementation methods of this method 2 determine the corresponding processing logic based on whether the two states are the same. The implementation logic is simple, and compared with the existing technology, which does not have the logic processing for scene refinement analysis under stable map elements, it improves the accuracy of rendering.

[0139] Optionally, before reading depth data of map features of a preset type from the rendering data of the electronic map to be displayed, the method further includes: determining the timing for triggering the point of interest update and the timing for reading the depth data.

[0140] The determination of when to trigger the interest point update and when to read the depth data includes:

[0141] When the number of still frames counted after the current electronic map has stabilized reaches N frames, the update of the point of interest is triggered, and the time when the update of the point of interest is triggered is recorded.

[0142] In the N+1th frame, the RGB data is sent to the logic processing unit through the display chip, and the logic processing unit reads the RGB data and converts the RGB data into depth data to determine whether the point of interest is to be rendered in the map.

[0143] Specifically, the time when the current trigger for updating the point of interest is recorded is used to calculate the time interval for the next trigger, thus serving as a criterion for determining whether to update the POI.

[0144] Specifically, when the current electronic map is in a changing state and the last time the update of the point of interest was triggered, the electronic map was in a stable state (meaning when the screen first enters a stable state), a forced update of the depth data is performed (updating the depth data means transferring the depth data from the GPU to memory). Alternatively, when the current electronic map is in a stable state and the last time the update of the point of interest was triggered, and the update scene is determined, since reading the depth data is done in the rendering thread after entering the stable state, this means that the depth data update will be done after one frame. Therefore, the update time of the POI (i.e., the timing of triggering the update of the point of interest) is placed one frame after entering the stable state, and this process is achieved by calculating the number of frames that have passed since stabilization.

[0145] After reaching a stable state, the system calculates how many frames have been stabilized. Then, when N frames have been stabilized (e.g., 3 frames; since the POI data collection interval is 4 frames), a POI update is triggered. For example, the logic thread triggers a POI update in the third frame, requests depth data from the rendering thread, reads the depth data in the fourth frame, and then performs logic processing based on the updated POI information and the read depth data. This ensures that the depth data is consistent with the scene, thus correcting POI collisions. For instance, when the application detects three identical frames on the electronic map, it sends a command to update the depth data, and then reads the data in the fourth frame. The processing in the third and fourth frames is used to solve cross-thread data synchronization issues.

[0146] Since rendering operations are performed in the rendering thread (processed by the GPU), and whether to display a Point of Interest (POI) is determined in the logic thread (processed by the CPU), the depth data of the rendered buildings needs to be processed on the CPU. When the application detects N identical frames on the electronic map, it requests to read the depth data at frame N. That is, the logic thread tells the rendering thread that it can send a command to read the depth data. The data is queried and processed at frame N+1, solving the data synchronization problem. Therefore, through cross-thread data synchronization processing, the rationality of depth data management is achieved; by controlling the update of POIs and the timing of depth data reading, accurate collision detection between POIs and objects is achieved.

[0147] In addition, in certain situations, such as when switching between portrait and landscape modes or when POI does not use building collision detection, the depth data of certain buildings and related data need to be released. In order to ensure that other threads can run correctly during the release, the rendering thread converts the depth data into RGB color data and stores it in video memory during rendering. When the related data is released, the logic processing thread reads the RGB color data in the corresponding scene, converts the RGB color data back into depth data, and performs logical processing on the depth data. The operation of the two threads does not affect each other.

[0148] Optionally, determine whether to render the POI, including:

[0149] Obtain the updated depth data of the points of interest and their pixel positions on the map;

[0150] Based on the updated depth data of the point of interest, the position of the updated point of interest's pixels in the map, and the depth data, it is determined whether the point of interest should be rendered in the map.

[0151] The updated depth data of the point of interest can be obtained by calculating the updated depth data of the point of interest based on the coordinates of the updated point of interest in the world coordinate system and the parameters of the camera in the current electronic map (such as position, orientation, etc.).

[0152] Specifically, based on the updated pixel position and depth data of the POI, and combined with the updated depth data of the building, it is determined whether the POI is occluded by the building. If it is occluded, the POI is not displayed. If it is not occluded, collision handling is performed, and finally the building and the POI are rendered and displayed.

[0153] By reading the depth data of buildings and updating POIs, the depth values ​​of POIs and buildings are compared, that is, compared relative to the position of the camera, to determine whether the POI is occluded by buildings in a more intuitive and accurate way. The collision handling is accurate, which makes the rendering results accurate.

[0154] Optionally, determining whether to render the point of interest in the map based on the updated depth data of the point of interest, the position of the updated point of interest's pixels in the map, and the depth data includes:

[0155] Based on the updated position of the point of interest (POI) in the map, the depth data of the pixel where the POI is located is obtained from the depth data; the depth data of the pixel where the POI is located is used to represent the depth data of the part of the target object that collides with the POI.

[0156] The depth data of the pixel where the point of interest is located is compared with the depth data of the point of interest to determine whether the target object and the point of interest are occluded.

[0157] If there is no occlusion, the point of interest is rendered in the map by performing collision processing between the target object and the point of interest; if there is occlusion, the point of interest is not rendered in the map.

[0158] Specifically, the GPU first stores the RGB color data in memory. The CPU then reads the RGB color data from memory and converts it into depth values; this process can be understood as updating the depth data. Based on the pixel location of the Point of Interest (POI), the CPU searches for the corresponding depth data from the read depth data. This depth value represents the depth of the building that collides with the POI. Comparing this depth value with the POI's depth value allows for a direct and accurate determination of the positional relationship between the POI and the building relative to the camera in the current scene.

[0159] Therefore, this application obtains depth data by converting depth values ​​into RGB color values ​​and achieves the effect of POI building collision in a multi-threaded environment by reading depth map data. By utilizing camera movement, the frequency of reading depth map data is reduced, improving performance. Furthermore, by controlling the update of POIs and the timing of depth data reading, they can accurately collide with the scene, resulting in more accurate rendering results and enhancing the user's service experience.

[0160] Corresponding to the above-mentioned collision detection method for map elements, this application provides a collision detection device for map elements. Figure 5 This is a schematic diagram of a collision detection device for map features provided in an embodiment of this application. The device includes:

[0161] The first detection module 501 is used to detect changes in the status of the electronic map currently displayed on the screen;

[0162] The second detection module 502 is used to trigger the collision detection module at least when the electronic map to be displayed is displayed on the screen, when the state change indicates that the map elements in the electronic map to be displayed are different from the map elements in the currently displayed electronic map and the map elements in the electronic map to be displayed are stable.

[0163] The collision detection module 503 includes:

[0164] A depth data reading unit is used to read depth data of map features of a preset type from the rendering data of the electronic map to be displayed, wherein the preset type does not include points of interest;

[0165] The depth data calculation unit is used to determine the depth data of points of interest in the electronic map to be displayed.

[0166] The depth data comparison unit is used to compare the depth data of the preset type of map features with the depth data of the points of interest to obtain the points of interest that need to be displayed in the electronic map to be displayed.

[0167] The collision detection device for map features provided in this application embodiment can be used to perform the above-mentioned... Figures 1 to 4 The technical solutions of the embodiments shown are similar in principle and in effect, and will not be described again here.

[0168] Optionally, the device further includes: a third detection module;

[0169] The third detection module is used to detect the change duration when the map elements in the electronic map to be displayed are different from the map elements in the currently displayed electronic map. Whenever the change duration reaches a preset detection duration but the map elements in the electronic map to be displayed are unstable, the collision detection is performed once. If the map elements in the electronic map to be displayed are unstable, the step of detecting the change duration is returned until the map elements in the electronic map to be displayed are stable. When the electronic map to be displayed is displayed on the screen, the collision detection module is triggered.

[0170] Optionally, the first detection module 501 is specifically used for:

[0171] Detect changes in the scale of the electronic map currently displayed on the screen or changes in the camera's status.

[0172] Optionally, if the scale state change is from a target scale to a scale different from the target scale, it means that the map elements in the electronic map to be displayed are different from the map elements in the currently displayed electronic map, and the target scale is the scale of the currently displayed electronic map.

[0173] Optionally, the camera state changes include orientation state changes and position state changes;

[0174] If the difference between the facing angle of the camera of the electronic map to be displayed and the facing angle of the camera of the currently displayed electronic map is greater than a preset angle threshold, it indicates that the map features in the electronic map to be displayed are different from the map features in the currently displayed electronic map.

[0175] Alternatively, if the distance between the location of the camera on the electronic map to be displayed and the location of the camera on the currently displayed electronic map is greater than a preset distance threshold, it indicates that the map elements in the electronic map to be displayed are different from the map elements in the currently displayed electronic map.

[0176] Optionally, the collision detection device for the map features further includes: a generation module, used for:

[0177] Based on the map data of the electronic map to be displayed, rendering data of the map elements included in the map data is generated. The rendering data includes: depth data, which corresponds to pixels.

[0178] Optionally, a graphics processing unit (GPU) is used to generate rendering data of map features included in the map data based on the map data of the electronic map to be displayed; a central processing unit (CPU) is used to read depth data of map features of a preset type from the rendering data of the electronic map to be displayed generated by the GPU.

[0179] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device in this embodiment may include:

[0180] At least one processor 601; and

[0181] Memory 602 communicatively connected to the at least one processor;

[0182] The memory 602 stores instructions that can be executed by the at least one processor 601 to cause the electronic device to perform the method as described in any of the above embodiments.

[0183] Optionally, the memory 602 can be either standalone or integrated with the processor 601. Optionally, the memory 602 can be connected to the processor 601 via bus 603.

[0184] The implementation principle and technical effects of the electronic device provided in this embodiment can be found in the foregoing embodiments, and will not be repeated here.

[0185] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the method described in any of the foregoing embodiments.

[0186] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the methods described in any of the foregoing embodiments.

[0187] The technical solution of this application involves the collection, storage, use, processing, transmission, provision, and disclosure of various information of users and merchants, which all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0188] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed.

[0189] The integrated modules implemented as software functional modules described above can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this application.

[0190] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor. The memory may include high-speed RAM, and may also include non-volatile memory (NVM), such as at least one disk storage device, and may also be a USB flash drive, external hard drive, read-only memory, disk, or optical disc, etc.

[0191] The aforementioned storage medium can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The storage medium can be any available medium accessible to general-purpose or special-purpose computers.

[0192] An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be an integral part of the processor. Both the processor and the storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and storage medium can exist as discrete components in an electronic device or host device.

[0193] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0194] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0195] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0196] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A collision detection method for map features, wherein, The method includes: The system detects changes in the state of the electronic map currently displayed on the screen. When the change indicates that the map features in the electronic map to be displayed are different from those in the currently displayed electronic map and the map features in the electronic map to be displayed are stable, collision detection is performed when the electronic map to be displayed is displayed on the screen. The collision detection includes: reading depth data of map features of a preset type from the rendering data of the electronic map to be displayed, wherein the preset type does not include points of interest; Determine the depth data of points of interest in the electronic map to be displayed; The depth data of the map features of the preset type are compared with the depth data of the points of interest to obtain the points of interest that need to be displayed in the electronic map to be displayed.

2. The method according to claim 1, wherein, When it is detected that map features in the electronic map to be displayed are different from map features in the currently displayed electronic map, the method further includes: The change duration is detected. Whenever the change duration reaches a preset detection duration but the map elements in the electronic map to be displayed are unstable, the collision detection is performed once. If the map elements in the electronic map to be displayed are unstable, the step of detecting the change duration is returned until the map elements in the electronic map to be displayed are stable. When the electronic map to be displayed is displayed on the screen, the collision detection is performed.

3. The method according to claim 1, wherein, The detection of changes in the state of the electronic map currently displayed on the screen specifically includes: Detect changes in the scale of the electronic map currently displayed on the screen or changes in the camera's status.

4. The method according to claim 3, wherein, The change in scale status, from a target scale to a scale different from the target scale, indicates that the map elements in the electronic map to be displayed are different from the map elements in the currently displayed electronic map. The target scale is the scale of the currently displayed electronic map.

5. The method according to claim 3, wherein, The camera state changes include orientation state changes and position state changes; If the difference between the facing angle of the camera of the electronic map to be displayed and the facing angle of the camera of the currently displayed electronic map is greater than a preset angle threshold, it indicates that the map features in the electronic map to be displayed are different from the map features in the currently displayed electronic map. Alternatively, if the distance between the location of the camera on the electronic map to be displayed and the location of the camera on the currently displayed electronic map is greater than a preset distance threshold, it indicates that the map elements in the electronic map to be displayed are different from the map elements in the currently displayed electronic map.

6. The method according to any one of claims 1-5, wherein, The method further includes: Based on the map data of the electronic map to be displayed, rendering data of the map elements included in the map data is generated. The rendering data includes: depth data, which corresponds to pixels.

7. The method according to claim 6, wherein, The graphics processing unit (GPU) generates rendering data of map features included in the map data based on the map data of the electronic map to be displayed. The step of reading depth data of map features of a preset type from the rendering data of the electronic map to be displayed specifically involves: The central processing unit (CPU) reads the depth data of map features of a preset type from the rendering data of the electronic map to be displayed generated by the graphics processing unit (GPU).

8. A collision detection device for map features, characterized in that, include: The first detection module is used to detect changes in the status of the electronic map currently displayed on the screen; The second detection module is used to trigger the collision detection module when the electronic map to be displayed is displayed on the screen when the state change indicates that the map elements in the electronic map to be displayed are different from the map elements in the currently displayed electronic map and the map elements in the electronic map to be displayed are stable. The collision detection module includes: A depth data reading unit is used to read depth data of map features of a preset type from the rendering data of the electronic map to be displayed, wherein the preset type does not include points of interest; The depth data calculation unit is used to determine the depth data of points of interest in the electronic map to be displayed. The depth data comparison unit is used to compare the depth data of the preset type of map features with the depth data of the points of interest to obtain the points of interest that need to be displayed in the electronic map to be displayed.

9. The apparatus according to claim 8, wherein, The device further includes: a third detection module; The third detection module is used to detect the change duration when the map elements in the electronic map to be displayed are different from the map elements in the currently displayed electronic map. Whenever the change duration reaches a preset detection duration but the map elements in the electronic map to be displayed are unstable, the collision detection is performed once. If the map elements in the electronic map to be displayed are unstable, the step of detecting the change duration is returned until the map elements in the electronic map to be displayed are stable. When the electronic map to be displayed is displayed on the screen, the collision detection module is triggered.

10. An electronic device, wherein, include: At least one processor; as well as A memory that is communicatively connected to the at least one processor; The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, cause the electronic device to perform the method according to any one of claims 1-7.

11. A computer program product comprising a computer program, wherein, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-7.

Citation Information

Patent Citations

  • Sparse map for autonomous vehicle navigation

    CN107438754A

  • Map data creation device, map data creation method and map data creation computer program, as well as vehicle position detection device

    JP2016142604A