A data processing method, apparatus, and related device

Abstract

The application discloses a data processing method and device and related equipment, which can be applied to the field of maps. The method comprises the following steps: obtaining a virtual skeleton animation model in a map application, and obtaining target skeleton animation data associated with the virtual skeleton animation model; the target skeleton animation data comprises model vertices and at least two compressed key skeleton animation frames contained in the virtual skeleton animation model; compressed interpolation skeleton animation frames are generated in the at least two compressed key skeleton animation frames, and the compressed interpolation skeleton animation frames are transmitted to a graphics processor; the compressed interpolation skeleton animation frames are used for position transformation of the model vertices in the graphics processor; and a navigation guide mark corresponding to the virtual skeleton animation model is rendered in an electronic map based on the model vertices after the position transformation. According to the application, the display effect of the navigation guide mark can be enriched in the navigation process.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data processing method, apparatus, and related equipment. Background Technology

[0002] With the development of computer technology, electronic maps have become an important tool for people's travel. Among them, navigation is the most important application of electronic maps, and navigation signs (such as car logos) are the most important location markers when navigating.

[0003] Existing technology generally uses flat 2D (Two-Dimensional) navigation logos to achieve basic current direction indication. However, 2D navigation logos appear flat and have poor effect when viewed from an angle, and the same image content appears from different viewing angles, resulting in a relatively monotonous display effect. Summary of the Invention

[0004] This application provides a data processing method, apparatus, and related equipment that can enrich the display effect of navigation guidance signs during navigation.

[0005] One embodiment of this application provides a data processing method, including:

[0006] In a map application, a virtual skeletal animation model is acquired, and target skeletal animation data associated with the virtual skeletal animation model is acquired. The target skeletal animation data includes the model vertices contained in the virtual skeletal animation model and at least two compressed key skeletal animation frames.

[0007] Generate compressed interpolated skeletal animation frames in at least two compressed key skeletal animation frames, and transfer the compressed interpolated skeletal animation frames to the graphics processor; the compressed interpolated skeletal animation frames are used to perform position transformations on the model vertices in the graphics processor;

[0008] Based on the model vertices after position transformation, the virtual skeletal animation model corresponding to the navigation guide icon is rendered in the electronic map of the map application.

[0009] One embodiment of this application provides a data processing apparatus, including:

[0010] The model acquisition module is used to acquire a virtual skeletal animation model in a map application and to acquire target skeletal animation data associated with the virtual skeletal animation model. The target skeletal animation data includes the model vertices contained in the virtual skeletal animation model and at least two compressed key skeletal animation frames.

[0011] An interpolation transmission module is used to generate compressed interpolated skeletal animation frames from at least two compressed key skeletal animation frames, and to transmit the compressed interpolated skeletal animation frames to a graphics processor; the compressed interpolated skeletal animation frames are used to perform position transformations on model vertices in the graphics processor;

[0012] The model rendering module is used to render navigation guide signs corresponding to the virtual skeletal animation model in the electronic map of the map application based on the model vertices after position transformation.

[0013] Among them, compressed interpolated skeletal animation frames include compressed interpolated skeletal data;

[0014] The aforementioned interpolation transmission module is specifically used to generate compressed interpolated bone data from the compressed bone data of at least two compressed key bone animation frames, and transmit the compressed interpolated bone data to the graphics processor; the compressed bone data of at least two compressed key bone animation frames is obtained by the business server performing matrix compression on the bone data in at least two key bone animation frames, and matrix compression refers to removing redundant data contained in the bone matrix in the bone data.

[0015] The device also includes:

[0016] The first matrix generation module is used to perform data recovery on compressed interpolated skeleton data in the graphics processor to obtain interpolated skeleton data, and generate the first transformation matrix corresponding to the model vertices based on the vertex data of the model vertices and the interpolated skeleton data.

[0017] The second matrix generation module is used to obtain the spatial transformation matrix for fitting the virtual skeletal animation model with the electronic map of the map application, and to generate the second transformation matrix based on the spatial transformation matrix.

[0018] The position transformation module is used to transform the position of the model vertices according to the first transformation matrix and the second transformation matrix to obtain the model vertices after position transformation.

[0019] The second matrix generation module mentioned above includes:

[0020] The first acquisition unit is used to acquire the label offset matrix and label rotation matrix corresponding to the electronic map of the map application; the label offset matrix is ​​used to represent the offset distance between the geographical location of the navigation guide label and the center position of the electronic map; the label rotation matrix is ​​used to represent the rotation of the electronic map relative to the northeast-sky coordinate system;

[0021] The second acquisition unit is used to acquire the first size parameter of the spatial bounding box associated with the virtual skeletal animation model, acquire the second size parameter of the virtual compass used to indicate the map orientation, and generate an identifier scaling ratio based on the first size parameter and the second size parameter.

[0022] The first generation unit is used to generate a spatial transformation matrix based on the identifier offset matrix, the identifier rotation matrix, and the identifier scaling ratio; the spatial transformation matrix is ​​used to transform the virtual skeletal animation model from the model coordinate system to the map coordinate system where the electronic map is located.

[0023] The second generation unit is used to obtain the view matrix and projection matrix associated with the electronic map, and generate a second transformation matrix based on the spatial transformation matrix, view matrix and projection matrix.

[0024] The first dimension parameter includes the first length parameter, the first width parameter, and the height parameter of the spatial bounding box; the second dimension parameter includes the second length parameter and the second width parameter of the virtual compass.

[0025] The aforementioned second acquisition unit is specifically used to acquire a first ratio between the second length parameter and the first length parameter, and to acquire a second ratio between the second width parameter and the first width parameter; and to determine the minimum value between the first ratio and the second ratio as the identifier scaling ratio.

[0026] The aforementioned interpolation transmission module includes:

[0027] An interpolation generation unit is used to generate compressed interpolated bone data for electronic maps from compressed bone data of at least two compressed key bone animation frames, based on a frame skipping strategy used to control the smooth display of the virtual skeletal animation model. The compressed interpolated bone data includes M compressed bone matrices, where each compressed bone matrix corresponds to a virtual bone in the virtual skeletal animation model, and M is a positive integer.

[0028] The data transmission unit is used to transmit M compressed skeleton matrices and the second transformation matrix to the graphics processor.

[0029] The frame skipping strategy includes the reference playback frame rate corresponding to the virtual skeletal animation model;

[0030] The above interpolation generation unit includes:

[0031] The sub-unit is used to obtain the rendering timestamp and reference playback frame rate during map rendering; the rendering timestamp refers to the time when the map rendering engine triggers the electronic map to render and update.

[0032] The generation subunit is used to generate compressed interpolated bone data for the electronic map based on the rendering timestamp, the reference playback frame rate, and compressed bone data from at least two compressed key skeletal animation frames.

[0033] Specifically, the aforementioned generation subunit is used to obtain a first compressed key skeleton animation frame and a second compressed key skeleton animation frame from at least two compressed key skeleton animation frames based on the rendering timestamp and the reference playback frame rate; and to perform interpolation processing on the compressed skeleton data of the first compressed key skeleton animation frame and the compressed skeleton data of the second compressed key skeleton animation frame to generate compressed interpolated skeleton data for the electronic map.

[0034] The reference playback frame rate refers to the number of compressed key skeleton animation frames contained within a unit of time.

[0035] The aforementioned generation subunit is specifically used to obtain the start timestamp corresponding to the starting compressed keybone animation frame in rendering at least two compressed keybone animation frames, determine the target duration based on the start timestamp and the rendering timestamp, perform a modulo operation on the target duration based on the unit duration to obtain the modulo result, determine the first animation frame index and the second animation frame index based on the modulo result, obtain the first compressed keybone animation frame from at least two compressed keybone animation frames according to the first animation frame index, and obtain the second compressed keybone animation frame from at least two compressed keybone animation frames according to the second animation frame index.

[0036] Specifically, the aforementioned data transmission unit is used to concatenate the second transformation matrix and the M compressed skeleton matrices to obtain a one-dimensional concatenated array, and then upload the one-dimensional concatenated array to the graphics processor.

[0037] The virtual skeletal animation model contains N model vertices, where N is a positive integer; the N model vertices include model vertex i, where i is a positive integer less than or equal to N;

[0038] The aforementioned first matrix generation module includes:

[0039] The third acquisition unit is used to acquire the bone index and weight of the target virtual bone bound to model vertex i from the vertex buffer object associated with the graphics processor; the vertex buffer object stores static data from the vertex data of model vertex i, and the bone index and weight of the target virtual bone are both static; the number of target virtual bones is less than or equal to M.

[0040] The data recovery unit is used to obtain the compressed bone matrix corresponding to the target virtual bone from the M compressed bone matrices carried by the one-dimensional concatenation array according to the bone index of the target virtual bone, add redundant data to the compressed bone matrix corresponding to the target virtual bone, and obtain the bone transformation matrix corresponding to the target virtual bone; the size of the bone transformation matrix is ​​larger than the size of the compressed bone matrix.

[0041] The third generation unit is used to generate the first transformation matrix corresponding to model vertex i based on the bone transformation matrix corresponding to the target virtual skeleton and the weights of the target virtual skeleton.

[0042] The vertex buffer object stores the initial vertex position of model vertex i; the initial vertex position of model vertex i is of static type.

[0043] The aforementioned position transformation module includes:

[0044] The first transformation unit is used to generate the intermediate vertex position of model vertex i based on the initial vertex position of model vertex i and the second transformation matrix;

[0045] The second transformation unit is used to generate the target vertex position of model vertex i based on the middle vertex position of model vertex i and the first transformation matrix corresponding to model vertex i.

[0046] The aforementioned model rendering module includes:

[0047] The fourth acquisition unit is used to obtain the index order for vertex rendering from the index buffer object associated with the graphics processor; the index buffer object stores dynamic data of the vertex data of the model vertices, and the index order is also dynamic.

[0048] The rendering and display unit is used to render the model on the electronic map based on the target vertex position corresponding to the model vertex after position transformation, the basic texture information stored in the vertex buffer object, the index order, and the texture conversion data associated with the model vertex, and to display the navigation guide sign corresponding to the virtual skeletal animation model. The texture conversion data is generated by the graphics processor based on the received decompressed texture. The decompressed texture is obtained by decompressing the texture associated with the virtual skeletal animation model in the resource loading thread.

[0049] The aforementioned model acquisition module includes:

[0050] The model loading unit is used to load the virtual skeletal animation model carrying the total skeletal animation data indicated by the setting operation for the navigation guidance mark in the map application from the business server.

[0051] The model parsing unit is used to call the resource loading thread to parse and process the virtual skeletal animation model in the map rendering engine, and to move the total skeletal animation data associated with the virtual skeletal animation model from the central processing unit to the graphics processing unit.

[0052] The data reading unit is used in the graphics processor to determine the type of action displayed by the virtual skeletal animation model based on the driving status of the driving object associated with the map application and the traffic status of the area where the driving object is located; to read the target skeletal animation data associated with the action type from the total skeletal animation data through the map rendering engine; and to associate at least two compressed key skeletal animation frames with the action type.

[0053] The graphics processor is used to bind vertex buffer objects and index buffer objects.

[0054] The virtual skeletal animation model has a proprietary model format; the vertex data of the model vertices belongs to the child nodes of the data header of the total skeletal animation data with a proprietary model format; the compressed skeletal data of at least two compressed key skeletal animation frames are used to indicate the motion state of the virtual bones in the virtual skeletal animation model; the model vertices are bound to the virtual bones; the data header includes version information, basic vertex parameters, and an overall transformation matrix used to adjust the display origin of the virtual skeletal animation model in the electronic map.

[0055] The aforementioned model rendering module includes:

[0056] A map display unit for displaying electronic maps for navigation in map applications;

[0057] The label display unit is used to display navigation guidance labels corresponding to virtual skeletal animation models with target action types in the electronic map based on the model vertices after position transformation; the target action type is determined based on the driving status of the driving object associated with the map application and the traffic status of the area where the driving object is located; the navigation guidance labels are used to indicate the position of the driving object in the electronic map.

[0058] One embodiment of this application provides a computer device, including: a processor and a memory;

[0059] The processor is connected to a memory, which stores a computer program. When the computer program is executed by the processor, it causes the computer device to perform the method provided in the embodiments of this application.

[0060] One aspect of this application provides a computer-readable storage medium storing a computer program adapted to be loaded and executed by a processor, so that a computer device having the processor performs the method provided in this application.

[0061] One embodiment of this application provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method provided in this application embodiment.

[0062] In this embodiment, the terminal device can acquire a virtual skeletal animation model in a map application and obtain target skeletal animation data associated with the virtual skeletal animation model. This target skeletal animation data includes the model vertices contained in the virtual skeletal animation model and at least two compressed key skeletal animation frames. Further, the terminal device can generate compressed interpolated skeletal animation frames from the at least two compressed key skeletal animation frames, and then transmit the obtained compressed interpolated skeletal animation frames to a graphics processor. These compressed interpolated skeletal animation frames are used to perform position transformations on the model vertices in the graphics processor. Finally, based on the position-transformed model vertices, navigation guidance signs corresponding to the virtual skeletal animation model can be rendered in the electronic map of the map application. Therefore, this embodiment, by introducing a dynamic virtual skeletal animation model, can achieve a three-dimensional display of navigation guidance signs and enrich their display effects. Furthermore, processing model vertices in the graphics processing unit (GPU) can reduce CPU utilization and optimize CPU performance. At the same time, using compressed data formats (such as compressed key skeletal animation frames and compressed interpolated skeletal animation frames) to transmit relevant data to the GPU can save bandwidth and memory used to upload each skeletal animation frame to the GPU. Ultimately, this can optimize the resource usage of the virtual skeletal animation model during navigation. Attached Figure Description

[0063] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0064] Figure 1 This is a schematic diagram of a network architecture provided in an embodiment of this application;

[0065] Figure 2a This is a schematic diagram of a data processing scenario provided in an embodiment of this application;

[0066] Figure 2b This is a schematic diagram of a map navigation interface provided in an embodiment of this application;

[0067] Figure 3This is a flowchart illustrating a data processing method provided in an embodiment of this application;

[0068] Figure 4 This is a schematic diagram of a model format provided in an embodiment of this application;

[0069] Figure 5 This is a schematic diagram of a frame interpolation method provided in an embodiment of this application;

[0070] Figure 6 This is a schematic diagram of a scene where a model is fitted to an electronic map, as provided in an embodiment of this application.

[0071] Figure 7 This is a flowchart illustrating a data processing method provided in an embodiment of this application;

[0072] Figure 8 This is a schematic diagram of a data processing scenario provided in an embodiment of this application;

[0073] Figure 9 This is a schematic diagram of a model vertex position transformation provided in an embodiment of this application;

[0074] Figure 10 This is a flowchart illustrating a data processing procedure provided in an embodiment of this application;

[0075] Figure 11 This is a schematic diagram of a thread call provided in an embodiment of this application;

[0076] Figure 12 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application;

[0077] Figure 13 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0078] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0079] Please see Figure 1 This is a schematic diagram of a network architecture provided in an embodiment of this application. Figure 1As shown, the network architecture may include a service server 100 and a terminal cluster. The terminal cluster may include multiple terminal devices, and this embodiment does not limit the number of terminal devices included in the terminal cluster. For example, the terminal cluster may specifically include: terminal device 200a, terminal device 200b, terminal device 200c, ..., terminal device 200n. Communication connections may exist between terminal devices in the cluster; for example, there is a communication connection between terminal device 200a and terminal device 200b, and between terminal device 200a and terminal device 200c. Simultaneously, any terminal device in the terminal cluster may have a communication connection with the service server 100; for example, there is a communication connection between terminal device 200a and service server 100. The above communication connection is not limited to a specific method; it can be directly or indirectly connected via wired communication, directly or indirectly connected via wireless communication, or through other methods. This application does not impose any restrictions on this method.

[0080] It should be understood that, such as Figure 1 Each terminal device in the terminal cluster shown can have an application client installed. When the application client runs on each terminal device, it can interact with the aforementioned... Figure 1 The business servers 100 shown interact with each other. The application clients can be multimedia applications (e.g., short video applications), travel applications (e.g., map applications), social applications (e.g., instant messaging applications), information applications (e.g., news applications), entertainment applications (e.g., reading applications, game applications), shopping applications, in-vehicle clients, browsers, or other application clients capable of displaying text, images, audio, and video data. These application clients can be standalone clients or embedded sub-clients integrated into other clients (e.g., social clients); this is not limited here. The business servers 100 can be a collection of multiple servers, such as backend servers and data processing servers corresponding to the application clients. Therefore, each terminal device can interact with the business servers 100 through the installed application clients; for example, each terminal device can obtain map data sent by the business servers 100 through a map application.

[0081] For example, taking a map application as an example, when a terminal device (e.g., terminal device 200a) launches a pre-installed map application, it can send a map retrieval request to the business server 100. After receiving the map retrieval request, the business server 100 can send the requested map data to the terminal device. Furthermore, the terminal device can call a map rendering engine to render the map based on the received map data, ultimately displaying the corresponding electronic map on its screen. Subsequently, the terminal device can update the displayed screen in response to triggered operations on the electronic map (e.g., dragging, rotating, zooming, etc.). The map rendering engine is a program component that implements the electronic map display function. In this embodiment, it can refer to a program implemented on a terminal device (e.g., a mobile terminal) that uses a graphics processing unit (GPU) to render vector map data. Compared with general rendering engines, it has the advantages of more data sources, lower resource usage (power consumption), and larger rendering scenes.

[0082] It is understood that the business server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud databases, cloud services, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. Terminal devices can include, but are not limited to, vehicle terminals, mobile terminals (such as smartphones, tablets, and laptops), intelligent voice interaction devices, smart home appliances, terminal devices in future 5G networks, or terminal devices in future evolved Public Land Mobile Networks (PLMNs). They can also include V2X devices, such as on-board units (OBUs) in vehicles, i.e., hardware units installed in vehicles that enable V2X communication and support V2X applications. Terminal devices can be fixed-location or mobile. Terminal devices can be based on iOS or Android systems; this application does not limit the specific technology or device form used in the terminal devices.

[0083] It is understood that electronic maps are commonly used in navigation scenarios. Navigation guidance icons (e.g., car logos) are image elements in electronic maps used to indicate the user's current location, typically located in the center of the screen during navigation. In this embodiment, the user using a map application for navigation can be referred to as the "driving object." To improve the navigation experience for the driving object, this embodiment provides a method for applying skeletal animation to map navigation, which can enrich the display effect of navigation guidance icons. Skeletal animation is a type of 3D (Three-Dimensional) animation model, comprising two parts: bones (also referred to as virtual bones in this embodiment) and skinned mesh data. Interconnected virtual bones form a skeletal structure, and animation is generated by changing the orientation and position of the virtual bones. Compared to traditional vertex animation, it has the advantages of smoothness and better smoothing effects. The 3D animation model is a standard format for 3D animation data, which can be edited and exported using 3D editing tools (e.g., 3ds Max, Maya). Different manufacturers have different 3D animation models. The more mainstream ones are Autodesk's FBX (the format used by the FilmBoX software, later renamed Motionbuilder) and Khronos glTF (GL (including WebGL, OpenGL ES, OpenGL) transmission format).

[0084] For ease of understanding, the following will be used as an example. Figure 1The following explanation uses the business server 100 and terminal device 200a as examples. Terminal device 200a has a map application installed and running, and can obtain a virtual skeletal animation model issued by business server 100 through this map application. Subsequently, it can obtain target skeletal animation data associated with this virtual skeletal animation model. This target skeletal animation data may include the model vertices contained in the virtual skeletal animation model and at least two compressed key skeletal animation frames. In this embodiment, the acquisition of the target skeletal animation data is related to the driving state of the driving object corresponding to terminal device 200a and the traffic state of the area where the driving object is located. Further, terminal device 200a can generate compressed interpolated skeletal animation frames from the at least two compressed key skeletal animation frames obtained, and then transmit the obtained compressed interpolated skeletal animation frames to the graphics processor of terminal device 200a. These compressed interpolated skeletal animation frames are used to perform position transformations on the model vertices in the graphics processor. Finally, based on the position-transformed model vertices, terminal device 200a can render the navigation guidance markers corresponding to the virtual skeletal animation model in the electronic map of the map application. Therefore, the embodiments of this application can enrich the display effect of navigation guidance signs by introducing a dynamic virtual skeletal animation model. In addition, it can also optimize the resource consumption of the virtual skeletal animation model in navigation.

[0085] It is understood that the business scenario applicable to the above network architecture can specifically be a map navigation scenario. For example, in a map navigation scenario, a driving object (e.g., driving object X) can select its preferred virtual skeletal animation model (e.g., virtual skeletal animation model Y designed using skeletal animation technology) through a map application on a terminal device (e.g., the aforementioned terminal device 200a), or optionally, it can directly use the system's default virtual skeletal animation model. During navigation, the terminal device can render navigation guidance markers with corresponding guiding effects on the electronic map of the map application based on the driving state of driving object X (e.g., stopping, accelerating, turning, etc.) and the nearby traffic conditions (e.g., speed limits, congestion, etc.). For example, when driving object X stops on the road, a virtual skeletal animation model Y performing a "standing still" action can be displayed on the electronic map as the current navigation guidance marker.

[0086] It is understandable that, compared with traditional 2D navigation car logos and static 3D models, the method provided in this application, which applies skeletal animation technology to the navigation car logos of terminal devices, can achieve a richer navigation experience and car logo display effect. It can also combine personalized animations and game IPs (Intellectual Property) that the driving object likes with traditional map navigation.

[0087] It is understood that in the specific implementation of this application, data related to user location, driving status, etc. are involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0088] For ease of understanding, please refer to the following: Figure 2a , Figure 2a This is a schematic diagram of a data processing scenario provided in an embodiment of this application. The scenario can be implemented by a terminal device (e.g., terminal device 20, not shown in the diagram), which can be the aforementioned... Figure 1 Any terminal device in the terminal cluster of the corresponding embodiment (e.g., terminal device 200a), and the driving object A is associated with the terminal device.

[0089] like Figure 2a As shown, when the driving object A uses a map application for navigation, the terminal device 20 can obtain a virtual skeletal animation model (e.g., virtual skeletal animation model 20A) from the map application. This virtual skeletal animation model can be a model selected by the driving object A itself, or it can be a system default model. In other words, the driving object A can freely switch between different virtual skeletal animation models according to its preferences; this embodiment does not limit this. Furthermore, the terminal device 20 can obtain target skeletal animation data (e.g., skeletal animation data 20B) associated with the virtual skeletal animation model 20A. The virtual skeletal animation model 20A can be a 3D animation model designed using skeletal animation technology. Skinning is a key aspect of this technology; it attaches (binds) the vertices of the mesh (i.e., model vertices) to the virtual skeleton, and each model vertex can be controlled by one or more virtual skeletons. Thus, as long as the virtual skeleton moves normally, the model vertices / skinning will move along with the virtual skeleton. The advantage of this is that model vertices at joints change position due to the simultaneous pulling of parent and child bones, thereby eliminating gaps. Here, a mesh is a network of data units composed of triangular facet data used in GPU rendering.

[0090] Based on this, the aforementioned skeletal animation data 20B may include two parts: vertex data of the model vertices contained in the virtual skeletal animation model 20A and compressed bone data of at least two compressed key skeletal animation frames. This application embodiment does not limit the number of model vertices or the number of compressed key skeletal animation frames. For example, as... Figure 2aAs shown, assuming the virtual skeletal animation model 20A includes m virtual bones and n vertex data attached to these virtual bones, where m and n are both positive integers, then the skeletal animation data 20B can specifically include the vertex data corresponding to these n model vertices, namely, vertex data A1 of model vertex 1, vertex data A2 of model vertex 2, ..., vertex data An of model vertex n. Each vertex data can include information such as the vertex position of the corresponding model vertex, which virtual bones affect it, and the weight of these virtual bones influencing the model vertex. Furthermore, the skeletal animation data 20B also includes compressed skeletal data for k (integers greater than or equal to 2) compressed key skeletal animation frames (also called animation frames). The compressed skeletal data of these k compressed key skeletal animation frames can be used to characterize the motion process of the virtual bones, for example, to describe the change of the virtual bone position over time under a certain action type (e.g., the "running" action). For example, as... Figure 2a As shown, the compressed bone data of the aforementioned k compressed keybone animation frames can specifically include compressed bone data B1 of compressed keybone animation frame 1, compressed bone data B2 of compressed keybone animation frame 2, ..., compressed bone data Bk of compressed keybone animation frame k. Each compressed keybone animation frame can contain motion information (including rotation, translation, and scaling) of each virtual bone at a certain moment, which can usually be represented by a matrix.

[0091] For ease of understanding and explanation, in this embodiment, the matrices in the compressed bone data of each compressed keybone animation frame can be collectively referred to as motion matrices, and each virtual bone corresponds to one motion matrix. For example, the compressed bone data B1 to compressed bone data Bk can each contain motion matrices corresponding to m virtual bones, that is, each compressed bone data includes m motion matrices. It should be noted that the motion matrix of each virtual bone in each compressed keybone animation frame is pre-calculated before the model is sent, and does not require the central processing unit (CPU) in the terminal device 20 to perform real-time calculations during the rendering process, thus reducing CPU usage to a certain extent.

[0092] To achieve time-varying playback of the model, this embodiment of the application can use frame interpolation to calculate the frame to be played at each moment (i.e., compressed interpolated skeletal animation frames). Simply put, for each virtual skeleton that needs to move, the terminal device 20 can, based on the current playback time, find two preceding and following compressed key skeletal animation frames from the aforementioned k compressed key skeletal animation frames, and then interpolate based on the time difference to obtain the compressed interpolated skeletal animation frame corresponding to the current time point. For example, as... Figure 2aAs shown, assuming that at a certain moment, the terminal device 20 finds compressed key skeleton animation frame 1 and compressed key skeleton animation frame 2 among the above k compressed key skeleton animation frames, then the compressed skeleton data B1 and compressed skeleton data B2 can be interpolated to obtain the corresponding compressed interpolated skeleton animation frame. This interpolated skeleton animation frame includes compressed interpolated skeleton data 20C, which also includes m matrices. In this embodiment, the matrices in the compressed interpolated skeleton data can be collectively referred to as compressed skeleton matrices. It can be understood that interpolating the compressed skeleton data (e.g., compressed skeleton data B1 and compressed skeleton data B2) of two compressed key skeleton animation frames is actually performing linear interpolation on the motion matrix of each virtual bone in these two compressed key skeleton animation frames. Therefore, in this embodiment, the compressed skeleton matrix and the motion matrix have the same meaning, that is, they are used to characterize the motion of the virtual bone, and the size of the compressed skeleton matrix is ​​the same as the size of the motion matrix. For example, as Figure 2a As shown, the compressed interpolated bone data 20C can specifically include compressed bone matrices C1, ..., compressed bone matrices Cm, with one virtual bone corresponding to one compressed bone matrix.

[0093] Furthermore, to optimize CPU performance, embodiments of this application can move the processing and computation of model vertices to the GPU. Therefore, before this, relevant data (including vertex data, compressed interpolated bone data, etc.) needs to be uploaded to the GPU. In embodiments of this application, the terminal device 20 can upload the compressed interpolated bone data to the GPU, for example, as... Figure 2a As shown, compressed interpolated bone data 20C containing m compressed bone matrices can be transmitted to the graphics processor of terminal device 20.

[0094] Since each model vertex needs to be processed in the graphics processor, the compressed interpolated bone data 20C can be restored first to obtain the corresponding interpolated bone data (e.g., interpolated bone data 20D). For ease of distinction, the matrices in the interpolated bone data in this embodiment can be collectively referred to as bone transformation matrices. It can be understood that the bone transformation matrix has the same meaning as the aforementioned compressed bone matrix and motion matrix, that is, it is used to characterize the motion of the virtual skeleton, but the size of the bone transformation matrix is ​​larger than the size of the compressed bone matrix. Figure 2a As shown, each compressed bone matrix in the above compressed interpolated bone data 20C can be restored to obtain interpolated bone data 20D. For example, interpolated bone data 20D may specifically include bone transformation matrix D1, ..., bone transformation matrix Dm.

[0095] Furthermore, a first transformation matrix corresponding to each model vertex can be generated based on the vertex data of each model vertex and the obtained interpolated skeleton data. This first transformation matrix is ​​used for subsequent position transformation of the model vertex. For ease of understanding, this embodiment uses the processing of model vertex 1 as an example for illustration. Figure 2a As shown, the graphics processor can obtain the bone indices of one or more virtual bones bound to model vertex 1 and their corresponding weights from the vertex data A1 of model vertex 1. Then, based on the obtained bone indices, it can obtain the corresponding compressed bone matrix from the compressed interpolated bone data 20C. The obtained compressed bone matrix can then be restored to its original form as the bone transformation matrix corresponding to the one or more virtual bones. Based on the bone transformation matrices and their corresponding weights, the first transformation matrix (e.g., transformation matrix E1) corresponding to model vertex 1 can be generated. Similarly, a similar calculation process can be used to obtain the transformation matrix E2 corresponding to model vertex 2, ..., and the transformation matrix En corresponding to model vertex n. Subsequently, the model vertices can be transformed based on the first and second transformation matrices corresponding to each model vertex. The second transformation matrix can be used to achieve the integration of the virtual skeleton animation model with the electronic map; the specific processing steps can be found in subsequent sections. Figure 3 The relevant descriptions in the corresponding embodiments.

[0096] like Figure 2a As shown, assuming that after performing position transformation on each model vertex in the graphics processor, we can obtain the vertex position F1 of model vertex 1 after position transformation, the vertex position F2 of model vertex 2 after position transformation, ..., the vertex position Fn of model vertex n after position transformation. Then, based on the vertex position of each model vertex and related texture information, we can perform model rendering on the electronic map, and finally obtain the navigation guide icon (e.g., navigation guide icon 20G) corresponding to the virtual skeletal animation model.

[0097] For ease of understanding, please refer to the following: Figure 2b , Figure 2b This is a schematic diagram of a map navigation interface provided in an embodiment of this application. For example... Figure 2bAs shown, assuming the aforementioned driving object A wants to go to location B and uses a map application for navigation, as can be seen from interfaces 201 and 202, if the driving object A selects the aforementioned virtual skeletal animation model 20A as its vehicle logo, then a corresponding three-dimensional navigation guide sign can be displayed on the electronic map (such as navigation guide sign 201a shown in interface 201 and navigation guide sign 202a shown in interface 202). At the same time, as the driving object A moves, the electronic map will be continuously refreshed during the navigation process, and the virtual skeletal animation model 20A will also make different instruction actions accordingly, such as walking, running, turning, etc., which can provide a rich navigation experience for the driving object without causing additional consumption of navigation resources due to the introduction of the virtual skeletal animation model.

[0098] The terminal device 20A acquires the virtual skeletal animation model and target skeletal animation data, generates compressed interpolated skeletal animation frames, and uploads them to the graphics processor. For details on how the graphics processor processes the model vertices, please refer to the following... Figures 3-10 The description in the corresponding embodiments.

[0099] Please see Figure 3 , Figure 3 This is a schematic flowchart of a data processing method provided in an embodiment of this application. This data processing method can be executed by a terminal device. Figure 3 As shown, the data processing method may include at least the following steps S101-S103:

[0100] Step S101: Obtain the virtual skeletal animation model in the map application, and obtain the target skeletal animation data associated with the virtual skeletal animation model;

[0101] Specifically, when a vehicle wishes to set personalized navigation guidance markers, the terminal device can respond to the navigation guidance marker setting operation in the map application by loading a virtual skeletal animation model carrying the total skeletal animation data indicated by the setting operation from the business server. Then, it can invoke a resource loading thread to parse and process the acquired virtual skeletal animation model in the map rendering engine, thereby reading the total skeletal animation data associated with the virtual skeletal animation model. This total skeletal animation data can then be moved from the central processing unit (CPU) to the graphics processing unit (GPU), thus reducing CPU usage. The total skeletal animation data here includes vertex data of all model vertices in the virtual skeletal animation model, compressed skeletal data of compressed key skeletal animation frames for all specified action types, and other relevant information. This embodiment does not limit the number of model vertices or the number of compressed key skeletal animation frames.

[0102] The vertex data for each model vertex may include the vertex index, initial vertex position, basic texture information, as well as the bone index and weight of the virtual bone to which it is bound.

[0103] The compressed bone data for each compressed key skeletal animation frame can include the motion matrix corresponding to each virtual bone in the virtual skeletal animation model. It's important to note that in skeletal animation, the virtual bones of a model (e.g., a character) have a parent-child hierarchical structure. For example, the shoulder is the parent joint, the elbow is the child joint, and the wrist is the child joint of the elbow. This is called a skeletal hierarchy (tree) or skeletal framework. A root node derives one or more child nodes, and each child node can also derive one or more child nodes, thus forming a skeletal hierarchy. The root node identifies the entire virtual skeletal animation model and can represent the origin of the model's own coordinate system; it usually has no skinning attachment. Child nodes identify a joint in the virtual skeletal animation model and usually have skinning attachment. Each node has a unique node name and an initial transformation matrix. The initial transformation matrix of a child node is based on its parent node as the origin of its coordinate system. Therefore, to obtain the motion matrix of a virtual bone, it can be determined by multiplying the initial transformation matrices of all its parent nodes along its path in the skeletal hierarchy. Because this calculation process is relatively performance-intensive, the motion matrix corresponding to each virtual bone in each compressed key skeleton animation frame can be pre-calculated before the model is distributed (for example, by the business server calling computing resources to perform the calculation). The calculation results are then packaged and distributed as a whole. This way, the terminal device does not need to consume its own computing resources to generate the motion matrix in real time. The motion matrix can be understood as representing the translation, rotation, and scaling of a virtual bone.

[0104] Furthermore, within the graphics processor, the terminal device can determine the action type displayed by the virtual skeletal animation model based on the driving state of the object associated with the map application and the traffic conditions of the area where the object is located. Then, the map rendering engine can read the target skeletal animation data associated with that action type from the aforementioned total skeletal animation data. This target skeletal animation data can include the model vertices contained in the virtual skeletal animation model and at least two compressed key skeletal animation frames associated with that action type. The driving state of the object can include, but is not limited to, stopping, accelerating, turning, and decelerating, while the traffic conditions can include, but are not limited to, speed limits, congestion, and smooth traffic. Correspondingly, the action type can include, but is not limited to, walking, running, turning, and stopping, and can be defined according to actual needs.

[0105] In this embodiment, a configuration file (e.g., a JSON file) associated with the virtual skeletal animation model is downloaded along with the virtual skeletal animation model. This configuration file can be used to indicate the types of actions that the virtual skeletal animation model can execute, as well as the starting and ending compressed key skeletal animation frames corresponding to each action type. Each action type will loop through the skeletal animation frames between its starting and ending compressed key skeletal animation frames. For example, "stop": {"frameStart": 0, "frameEnd": 60} indicates that the starting compressed key skeletal animation frame corresponding to the "stop" action type is compressed key skeletal animation frame 0, and the ending compressed key skeletal animation frame is compressed key skeletal animation frame 60. When an external source passes a corresponding action name (e.g., "stop") to the map rendering engine based on the driving state of the driving object and the current traffic state, the map rendering engine will read the compressed skeletal data of at least two corresponding compressed key skeletal animation frames (i.e., all compressed key skeletal animation frames between the starting and ending compressed key skeletal animation frames, such as compressed key skeletal animation frames 0 to 60) according to the passed action name.

[0106] It is understandable that, optionally, in order to send the model vertices to the shader for rendering, it is necessary to upload the relevant data in memory (such as the total skeletal animation data) to the graphics processor. However, this process involves various instructions from the CPU, resulting in low data transfer efficiency. Therefore, in this embodiment, a vertex buffer object (VBO, used to store vertex data, reducing the process of data transfer from the CPU to the GPU and improving rendering efficiency; it is a means of vertex optimization in OpenGL) and an index buffer object (IBO, used to store vertex indices; OpenGL calls these vertex indices to determine which model vertex to draw) can be used to improve data transfer efficiency. That is, the graphics processor can bind vertex buffer objects and index buffer objects. For example, when a map rendering engine uses OpenGL ES (OpenGL for Embedded Systems, a cross-platform 2D and 3D graphics application programming interface designed specifically for various embedded systems such as mobile phones and game consoles; OpenGL stands for Open Graphics Library, a professional graphics programming interface) for rendering, OpenGL ES can deliver a large number of model vertices to the shader at once using vertex buffer objects, thereby greatly reducing the time it takes for related vertex data to move from memory to the CPU and then to the GPU. The index buffer object creates an index cache, which enables vertex reuse. During rendering, it informs the shader of the index (e.g., number) of each model vertex according to the index order of vertex rendering. The shader is used to implement image rendering, replacing the editable program in the fixed rendering pipeline.

[0107] Based on this, in this embodiment, the vertex buffer object can be used to store static data from the vertex data, including the initial vertex position of the model vertex, basic texture information, the bone index of the virtual bone it is bound to, and the weight of the virtual bone; the index buffer object can be used to store dynamic data from the vertex data, including specifying the index order for vertex rendering. Therefore, during the rendering process, the shader can quickly obtain the corresponding vertex data from the vertex buffer object and the index buffer object for processing, thereby improving rendering efficiency.

[0108] Furthermore, this application embodiment also provides a model animation format design suitable for mobile terminals (e.g., mobile phones). It is understood that directly using models output from design software (e.g., Maya, 3DMax) requires the inclusion of a large format parsing library in the application (APP). Parsing consumes additional resources, thus affecting the application's package size and power consumption. Based on this, this application embodiment designs a compact skeletal animation data, which avoids the complexity of parsing on mobile terminals, moves the parsing process to before the model goes online (offline), increases parsing reliability, and reduces the package size increase caused by introducing the parsing library into the map application. Specifically, this application embodiment can perform model rendering on mobile terminals using OpenGL ES.

[0109] For ease of understanding, please refer to the following: Figure 4 , Figure 4 This is a schematic diagram of a model format provided in an embodiment of this application. Embodiments of this application can... Figure 4 The model format shown is called a proprietary model format. For ease of distinction, the model format used by models exported from software such as Maya and 3ds Max can be called a general model format. It can be understood that when a virtual skeletal animation model has a proprietary model format, the vertex data of the model's vertices belongs to a child node of the data header of the total skeletal animation data with the proprietary model format. This data header can include the version information of the virtual skeletal animation model, basic vertex parameters, and the overall transformation matrix used to adjust the display origin of the virtual skeletal animation model on the electronic map. Here, the basic vertex parameters refer to relatively macroscopic parameters, such as the number of model vertices, the start and end positions of the vertex data for each model vertex, etc. For example, as... Figure 4As shown, the vertex data of model vertices Mesh1, Mesh2, ..., MeshN are all child nodes of this data header. Each model vertex's vertex data can include its vertex index, initial vertex position, basic texture information (including texture coordinates and the image name corresponding to the texture), and the bone index and weight of the virtual bone it is bound to. Optionally, the compressed bone data of each compressed keybone animation frame in the total skeletal animation data can be arranged sequentially by bone index, for example, from the first frame to the Kth frame, or other arrangements can be used; this embodiment does not limit this. The compressed bone data of each frame can include the motion matrices corresponding to all virtual bones (e.g., virtual bone 0, virtual bone 1, virtual bone 2, ..., virtual bone M). It can be understood that the compressed bone data of at least two compressed keybone animation frames belonging to the same action type are used to indicate the motion state of the virtual bones in the virtual skeletal animation model under that action type. Each model vertex can be bound to one or more virtual bones; optionally, in some embodiments, a model vertex can be bound to a maximum of four virtual bones.

[0110] It should be noted that other model formats can be designed to achieve similar effects for terminal devices. This application does not limit the specific model format used for the virtual skeletal animation model.

[0111] Step S102: Generate compressed interpolated skeletal animation frames in at least two compressed key skeletal animation frames, and transfer the compressed interpolated skeletal animation frames to the graphics processor.

[0112] It is understandable that the rendering frame rate of electronic maps changes continuously during actual map navigation. If the animation of the virtual skeletal animation model is played along with the map, it may cause problems such as animation stuttering and inconsistent speed. However, increasing the map rendering frame rate to ensure smooth animation would increase CPU usage. Therefore, the embodiments of this application can use frame interpolation to achieve a stable playback effect under different map rendering frame rates, that is, to achieve dynamic control of the animation playback speed of the virtual skeletal animation model.

[0113] Specifically, the compressed interpolated skeletal animation frames in this embodiment include compressed interpolated skeletal data. Therefore, the terminal device can generate corresponding compressed interpolated skeletal data from the compressed skeletal data of at least two compressed key skeletal animation frames, and then transmit the compressed interpolated skeletal data to the graphics processor. It should be noted that the compressed key skeletal animation frames in this embodiment are obtained by compressing key skeletal animation frames. That is, before the model goes online, after the business server obtains a 3D skeletal model with a common model format (e.g., FBX, glTF) exported by design software (e.g., Maya, 3DMax), it can convert the format of the 3D skeletal model to obtain data with the format of FBX, glTF, etc. Figure 4 The virtual skeletal animation model shown is in a proprietary model format. During this process, the business server can perform matrix compression on the bone data in at least two key skeletal animation frames associated with the 3D skeletal model, thereby obtaining at least two compressed key skeletal animation frames carrying compressed bone data. It can be understood that, similar to the data structure of the compressed key skeletal animation frames, the bone data in each key skeletal animation frame may include the bone matrix corresponding to each virtual bone. Here, the bone matrix can be the result of the business server sequentially multiplying the initial transformation matrices of all parent nodes along the path of the virtual bone in the skeletal hierarchy. After calculating the bone matrix, the business server can perform matrix compression on each bone matrix. Specifically, redundant data contained in the bone matrix can be removed to obtain the corresponding motion matrix. The skeletal animation frame containing the motion matrix is ​​the compressed key skeletal animation frame described in this application embodiment. Therefore, the motion matrix carried by the final virtual skeletal animation model is actually pre-calculated and compressed before the model goes online.

[0114] It is understandable that the skeleton matrix and the motion matrix have the same meaning, that is, they are used to represent the movement of virtual skeletons, and the size of the skeleton matrix is ​​larger than the size of the motion matrix.

[0115] In one implementation, assuming the virtual skeletal animation model contains M virtual bones, where M is a positive integer, the terminal device can generate compressed interpolated skeletal data for the electronic map from compressed skeletal data of at least two compressed key skeletal animation frames, based on a frame-skipping strategy used to control the smooth display of the virtual skeletal animation model. This compressed interpolated skeletal data can include M compressed skeletal matrices, with each compressed skeletal matrix corresponding to a virtual bone in the virtual skeletal animation model.

[0116] Optionally, the frame skipping strategy in this application embodiment may specifically include a reference playback frame rate corresponding to the virtual skeletal animation model. This reference playback frame rate can be understood as a recommended or ideal frame rate given during model animation design. The playback effect corresponding to this reference playback frame rate is relatively stable, neither too fast nor too slow. Its specific value can be designed based on the actual model, and this application embodiment does not limit this. The specific process of generating compressed interpolated skeletal data can then be as follows: During map rendering, the rendering timestamp and reference playback frame rate are first obtained. Then, based on the rendering timestamp, reference playback frame rate, and the compressed skeletal data of at least two compressed key skeletal animation frames, compressed interpolated skeletal data for the electronic map can be generated. The rendering timestamp refers to the timestamp at which the map rendering engine triggers the electronic map to render and update. That is, every time the map rendering engine refreshes a frame of map content, the virtual skeletal animation model needs to calculate which compressed interpolated skeletal animation frame is currently being played.

[0117] To achieve stable playback at different map rendering frame rates, the terminal device can obtain a first compressed key skeleton animation frame and a second compressed key skeleton animation frame from at least two compressed key skeleton animation frames based on the rendering timestamp and a reference playback frame rate. Then, interpolation processing can be performed on the compressed bone data of the first and second compressed key skeleton animation frames to generate compressed interpolated bone data. Specifically, this interpolation processing can be linear interpolation of the compressed bone data of the first and second compressed key skeleton animation frames. Optionally, for rotational changes represented by quaternions, quaternion spherical linear interpolation can be used to implement the interpolation processing, and then the interpolated quaternions can be converted into matrix form.

[0118] In some embodiments, the reference playback frame rate may specifically refer to the number of compressed keybone animation frames contained within a unit duration, and the specific value of the unit duration will not be limited here. Based on this, the terminal device can obtain the start timestamp corresponding to the starting compressed keybone animation frame among the rendering of at least two compressed keybone animation frames, and then determine the target duration based on the start timestamp and the rendering timestamp. Further, the target duration can be moduloed based on the unit duration to obtain the modulo result, and then the first animation frame index and the second animation frame index can be determined based on the modulo result. Finally, the first compressed keybone animation frame can be obtained from at least two compressed keybone animation frames based on the first animation frame index, and the second compressed keybone animation frame can be obtained from at least two compressed keybone animation frames based on the second animation frame index.

[0119] For ease of understanding, please refer to the following: Figure 5 , Figure 5This is a schematic diagram illustrating a frame interpolation method provided in an embodiment of this application. For example... Figure 5 As shown, assuming the reference playback frame rate in this scene is 5 compressed keyskeletal animation frames played within 1 second (i.e., unit duration), these frames could include compressed keyskeletal animation frames A1, A2, A3, A4, and A5. Compressed keyskeletal animation frame A1 is the starting frame, and A5 is the ending frame. For ease of understanding, assume these compressed keyskeletal animation frames are evenly distributed along a timeline with unit durations. Each frame corresponds to a timestamp on that timeline. For example, frame A1 corresponds to timestamp T1 (the starting timestamp), frame A2 to timestamp T2, frame A3 to timestamp T3, frame A4 to timestamp T4, and frame A5 to timestamp T5. The difference between timestamps T1 and T5 is equal to the unit duration.

[0120] Optionally, in scenarios with high map rendering frame rates, the electronic map's rendering update frequency is higher. Taking the generation of compressed interpolated skeletal animation frame B5 as an example, the terminal device has already played compressed interpolated skeletal animation frames B1 to B4. If the map rendering engine needs to refresh another map frame at this time, and the current rendering timestamp is timestamp T6, then the target duration = timestamp T6 - timestamp T1 = duration R. Furthermore, the duration R can be moduloed based on the unit duration, i.e., the duration R % unit duration can be calculated to obtain the corresponding modulo result. Assuming this modulo result points to a certain interpolation point between compressed key skeletal animation frames A3 and A4... If the value point is determined, then compressed keybone animation frame A3 can be identified as the first compressed keybone animation frame, and compressed keybone animation frame A4 as the second compressed keybone animation frame. Interpolation processing can then be performed on the compressed bone data of compressed keybone animation frames A3 and A4. Specifically, linear interpolation is performed on the motion matrix of the virtual bone in compressed keybone animation frame A3 and the motion matrix of the virtual bone in compressed keybone animation frame A4, respectively, to obtain the compressed bone matrix corresponding to the virtual bone. Finally, compressed interpolated bone animation frame B5 can be obtained. As mentioned above, although the motion matrix does not contain redundant data, it does not affect the interpolation processing. The process of generating other compressed interpolated bone animation frames in this scene can be found in the process of generating compressed interpolated bone animation frame B5, which will not be repeated here. It can be understood that since the animation is played in a loop, after playing to the last frame using this frame interpolation method, it will start playing from the beginning again.

[0121] Similarly, optionally, in scenarios with low map rendering frame rates, the electronic map is rendered and updated less frequently. In such scenarios, the process of generating compressed interpolated skeletal animation frames C1-C4 can also generate compressed interpolated skeletal animation frames B5, which will not be elaborated here.

[0122] like Figure 5 As shown, comparing the two scenarios, it can be seen that in scenarios with a higher map rendering frame rate, the number of compressed interpolated skeletal animation frames per unit duration is greater, while in scenarios with a lower map rendering frame rate, the number of compressed interpolated skeletal animation frames per unit duration is less. However, the terminal device always uses the same calculation method to select the current frame skipping amplitude (for example, when the map rendering frame rate is higher, the frame skipping amplitude at a certain moment is 0.6 compressed key skeletal animation frames; when the map rendering frame rate is lower, the frame skipping amplitude at a certain moment is 1.5 compressed key skeletal animation frames) to generate the compressed interpolated skeletal animation frames to be played, regardless of the map rendering frame rate. Therefore, dynamic control of the animation playback speed for the virtual skeletal animation model can be achieved.

[0123] In other words, regardless of the map rendering frame rate, the time point at which the map rendering engine renders each frame (i.e., the rendering timestamp mentioned above) can be used to find an interpolation point in at least two compressed key skeleton animation frames by taking the remainder. By linearly interpolating the compressed skeleton data (including translation, rotation, scaling, etc.) of the compressed key skeleton animation frames before and after this interpolation point, the compressed interpolated skeleton data at the current time point can be calculated, thereby enabling the virtual skeleton animation model to play according to the time-varying process.

[0124] Optionally, other frame skipping strategies can also be used to achieve a similar effect, and this application does not limit this approach.

[0125] Optionally, in some embodiments, if the calculated interpolation point happens to point to an integer compressed key skeleton animation frame, i.e., the remainder result is zero, then interpolation calculation is not required. Since the compressed skeleton data of the compressed key skeleton animation frame is already stored in the GPU, there is no need to upload it again. The data can be directly obtained and restored in the GPU and then used.

[0126] It is understandable that after obtaining the compressed interpolated skeletal animation frames, the corresponding compressed interpolated skeletal data needs to be uploaded to the graphics processor for computation. Since this embodiment also requires uploading the second transformation matrix used for position transformation of the model vertices to the graphics processor, in order to reduce the frequency of OpenGL calls and improve computational efficiency, this embodiment can upload the compressed interpolated skeletal data and the second transformation matrix to the graphics processor at once. As mentioned above, the compressed interpolated skeletal data includes M compressed skeletal matrices, and thus the M compressed skeletal matrices and the second transformation matrix can be transmitted to the graphics processor. Similar to the motion matrix, the compressed skeletal matrix does not contain redundant data.

[0127] In some embodiments, each bone matrix in each key skeletal animation frame is a 4*4 matrix, which can represent the translation, rotation, and scaling of a virtual bone, belonging to rigid body transformation. The last column (0, 0, 0, 1) of the rigid body transformation is redundant data. Therefore, this redundant data can be temporarily removed before the model is uploaded, thereby obtaining a 3*4 motion matrix. Interpolating the motion matrix yields a 3*4 compressed bone matrix, which can then be restored later. This saves bandwidth and memory on the graphics processor for each skeletal animation frame (e.g., compressed interpolated skeletal animation frame, compressed key skeletal animation frame), thereby optimizing memory performance and improving data transmission efficiency.

[0128] For example, optionally, the terminal device can concatenate the second transformation matrix and the M compressed skeleton matrices to obtain a one-dimensional concatenated array, which can then be uploaded to the graphics processor.

[0129] Understandably, the terminal device can further obtain a spatial transformation matrix for fitting the virtual skeletal animation model to the electronic map of the map application, and then generate a second transformation matrix based on this spatial transformation matrix. Optionally, the specific process of generating the second transformation matrix can be as follows: The terminal device can first obtain the marker offset matrix and marker rotation matrix corresponding to the electronic map of the map application. The marker offset matrix is ​​used to represent the offset distance between the geographical location of the navigation guide marker and the center position of the electronic map. The marker rotation matrix is ​​used to represent the rotation of the electronic map relative to the northeast-sky coordinate system (or zero-rotation coordinate system). This rotation can include two types: rotation of the map plane and 3D rotation (e.g., rotation of the electronic map at a tilted viewpoint caused by a specified trigger operation). The northeast-sky coordinate system can also be called the station-center coordinate system. This coordinate system takes the user's location as the origin, with the X-axis pointing east, the Y-axis pointing north, and the Z-axis pointing to the zenith. Then, the first size parameter of the spatial bounding box (e.g., a 3D bounding box) associated with the virtual skeletal animation model can be obtained, and the second size parameter of the virtual compass used to indicate the map orientation can be obtained. Subsequently, the marker scaling ratio can be generated based on the first and second size parameters. It is understandable that using a slightly larger and simpler geometric shape as a spatial bounding box to approximate a complex virtual skeletal animation model can reduce computation and thus improve rendering efficiency. Here, the first size parameter can include the first length, first width, and height parameters of the spatial bounding box, and the second size parameter can include the second length and second width parameters of the virtual compass. Therefore, the terminal device can obtain a first ratio between the second length parameter and the first length parameter, and simultaneously obtain a second ratio between the second width parameter and the first width parameter. The minimum value between the first and second ratios can then be determined as the scaling ratio.

[0130] Furthermore, the terminal device can generate a corresponding spatial transformation matrix based on the aforementioned identifier offset matrix, identifier rotation matrix, and identifier scaling ratio. Specifically, the identifier offset matrix, identifier rotation matrix, and identifier scaling ratio can be multiplied together. This spatial transformation matrix is ​​used to transform the virtual skeletal animation model from the model coordinate system to the map coordinate system where the electronic map is located. Subsequently, the view matrix and projection matrix associated with the electronic map can be obtained, and then a second transformation matrix can be generated based on the spatial transformation matrix, view matrix, and projection matrix. This second transformation matrix can also be called the MVP matrix, which includes three matrices: Model, View, and Projection. Here, the Model matrix is ​​the spatial transformation matrix, the View matrix is ​​the view matrix, and the Projection matrix is ​​the projection matrix. The MVP matrix can be used to project the 3D model onto the screen.

[0131] For ease of understanding, please refer to the following: Figure 6 , Figure 6 This is a schematic diagram illustrating a scenario where a model is fitted to an electronic map, as provided in an embodiment of this application. In this scenario, the virtual skeletal animation model is independent of geographic coordinates during the design phase, but it needs to be placed on an electronic map later, thus requiring the fitting of the virtual skeletal animation model and the electronic map. The fitting of the virtual skeletal animation model to the electronic map mainly involves three aspects: translation, rotation, and scaling. Specifically:

[0132] (1) Translation and Rotation: When designing a virtual skeletal animation model, ensure that its feet are positioned at the origin of the three-dimensional space, i.e., the coordinate point (0, 0, 0), and that the model's face is towards the -y axis, its head towards the +z axis, and its left side towards the +x direction. Figure 6 As shown in model 60A, the corresponding coordinate system 60 is the model coordinate system used during model design. During model design, the model is aligned with the center point and rotation direction of the Earth's Cartesian coordinate system. Then, the center point coordinates and rotation matrix from the real-time rendering of the electronic map are used to construct a label transformation matrix (i.e., the product of the label offset matrix and the label rotation matrix). Each vertex of the subsequent virtual skeletal animation model is multiplied by this label transformation matrix to achieve alignment with the electronic map. In this system, the origin of the Earth's Cartesian coordinate system coincides with the Earth's center of mass, the Z-axis points to the Earth's North Pole, the X-axis points to the intersection of the Earth's equatorial plane and the Greenwich Meridian, and the Y-axis forms a right-handed coordinate system with the XOZ coordinate system in the equatorial plane.

[0133] (2) Scaling: The units used in the design of the virtual skeletal animation model are not fixed, but when displayed on an electronic map, they cannot be too large or too small. Therefore, scaling is required to maintain the normal proportion with other features. For example, this can be achieved in the following ways: (a) Calculate the size of the bounding box (box_x, box_y, box_z) during the model loading stage, where box_x, box_y, and box_z can represent the first length parameter, the first width parameter, and the height parameter of the bounding box, respectively; (b) Obtain the virtual compass (e.g., Figure 6 The virtual compass 60C shown in interface 60B has a size (x, y), where x and y can represent the second length parameter and the second width parameter of the virtual compass, respectively; (c) when rendering the virtual skeletal animation model, each model vertex is multiplied by the identified scaling ratio min(x / box_x, y / box_y), where x / box_x is the first ratio and y / box_y is the second ratio. As shown in interface 60B, after processing with the spatial transformation matrix, the model 60A and the electronic map are successfully aligned.

[0134] Furthermore, after the compressed interpolated skeleton data is transmitted to the graphics processor through the above process, the compressed interpolated skeleton data can be restored in the graphics processor to obtain the interpolated skeleton data. Then, the first transformation matrix corresponding to the model vertex can be generated based on the vertex data of the model vertex and the interpolated skeleton data.

[0135] Specifically, in this embodiment, it is assumed that the virtual skeletal animation model contains N model vertices, where N is a positive integer. These N model vertices include model vertex i, where i is a positive integer less than or equal to N. For ease of understanding, this embodiment uses model vertex i as an example for illustration.

[0136] In the vertex buffer object associated with the graphics processor, the terminal device can obtain the bone index and weight of the target virtual bone bound to the model vertex i. The vertex buffer object (VBO) stores static data from the vertex data of model vertex i. The bone index and weight of the target virtual bone are both static, and the number of target virtual bones is less than or equal to M. In some embodiments, the number of target virtual bones is at most four; this application does not limit this.

[0137] Furthermore, based on the bone index of the target virtual bone, the compressed bone matrix (e.g., a 3*4 matrix) corresponding to the target virtual bone can be obtained from the M compressed bone matrices carried by the aforementioned one-dimensional concatenation array. Then, redundant data (e.g., the last column of the matrix (0, 0, 0, 1)) can be added to the compressed bone matrix corresponding to the target virtual bone, thereby obtaining the bone transformation matrix (e.g., a 4*4 matrix) corresponding to the target virtual bone, to achieve data recovery of the compressed bone data. It can be understood that the size of the bone transformation matrix is ​​larger than the size of the compressed bone matrix. Further, based on the bone transformation matrix corresponding to the target virtual bone and the weights of the target virtual bone, a first transformation matrix corresponding to model vertex i can be generated. Optionally, when there are multiple target virtual bones, the weight of each target virtual bone is multiplied by its corresponding bone transformation matrix, and the resulting products are summed to obtain the first transformation matrix corresponding to model vertex i. It can be understood that for a model vertex, the sum of the weights of the target virtual bones is 1. For example, suppose a model vertex V has three bound virtual skeletons: virtual skeleton 1, virtual skeleton 2, and virtual skeleton 3. Virtual skeleton 1 has a transformation matrix of U1 and weights of W1; virtual skeleton 2 has a transformation matrix of U2 and weights of W2; and virtual skeleton 3 has a transformation matrix of U3 and weights of W3, where W1 + W2 + W3 = 1. Then, the first transformation matrix corresponding to model vertex V is W1*U1 + W2*U2 + W3*U3. Similar processing is performed on each model vertex to generate the first transformation matrix for each vertex.

[0138] The first transformation matrix is ​​used to transform the position of the model vertices in the graphics processor. Therefore, after obtaining the first and second transformation matrices, the terminal device can transform the position of the model vertices according to the first and second transformation matrices to obtain the transformed model vertices.

[0139] In this embodiment, the vertex buffer object also stores the initial vertex position of model vertex i, which is also of static type. Taking model vertex i as an example, the specific process of transforming the position of model vertex i can be as follows: In the graphics processor, the second transformation matrix carried by the aforementioned one-dimensional concatenation array is first obtained. Then, based on the initial vertex position of model vertex i and the second transformation matrix, the intermediate vertex position of model vertex i can be generated (i.e., the initial vertex position is multiplied by the second transformation matrix). This achieves the macroscopic transformation of model vertex i in the electronic map. Further, based on the intermediate vertex position of model vertex i and the first transformation matrix corresponding to model vertex i, the target vertex position of model vertex i can be generated (i.e., the intermediate vertex position is multiplied by the first transformation matrix). This achieves the microscopic transformation of model vertex i based on the target virtual skeleton, thus ultimately realizing the position transformation of model vertex i. It can be understood that the specific process of transforming the position of other model vertices can refer to the process of transforming the position of model vertex i, which will not be repeated here. Ultimately, the position transformation of all model vertices can be achieved.

[0140] Optionally, the terminal device can first perform data recovery on the entire one-dimensional spliced ​​array to obtain the second transformation matrix and M skeleton transformation matrices, and then calculate the first transformation matrix corresponding to each model vertex.

[0141] Step S103: Based on the model vertices after position transformation, render the navigation guide icon corresponding to the virtual skeletal animation model in the electronic map of the map application.

[0142] Specifically, within the index buffer object associated with the graphics processor, the terminal device can obtain the index order used for vertex rendering. This index buffer object stores dynamically typed vertex data from the model's vertices, and the index order is also dynamically typed. Furthermore, based on the target vertex position corresponding to the transformed model vertices, the basic texture information (e.g., texture coordinates) stored in the vertex buffer object, the index order, and the texture transformation data associated with the model vertices, model rendering can be performed on an electronic map. Ultimately, navigation indicators corresponding to the virtual skeletal animation model can be displayed; these navigation indicators can represent corresponding actions.

[0143] The texture conversion data is generated by the graphics processor based on the received decompressed textures, which are obtained in the resource loading thread by decompressing the textures associated with the virtual skeletal animation model.

[0144] In some embodiments, the map rendering engine can call shaders in OpenGL ES to render the model.

[0145] Understandably, after successful rendering, the terminal device can display an electronic map for navigation in the map application. Then, based on the model vertices after position transformation, it can display navigation guidance icons corresponding to the virtual skeletal animation model with the target action type in the electronic map. Here, the target action type is determined based on the driving status of the driving object associated with the map application and the traffic status of the area where the driving object is located. The navigation guidance icons can be used to indicate the position of the driving object in the electronic map.

[0146] As described above, this application embodiment, by introducing a dynamic virtual skeletal animation model, can achieve a three-dimensional display of navigation guidance signs. Since the target skeletal animation data is related to the current driving state of the object and the nearby traffic conditions, different guidance effects can be displayed according to different driving and traffic states during navigation, thereby enriching the display effect of navigation guidance signs. Furthermore, pre-calculating the compressed skeletal data of each compressed key skeletal animation frame before model delivery and processing the model vertices in the graphics processor can reduce the CPU's occupancy rate and optimize CPU performance. Simultaneously, transmitting the obtained compressed key skeletal animation frames and compressed interpolated skeletal animation frames to the graphics processor in compressed data form can save bandwidth and memory used for uploading each skeletal animation frame to the graphics processor, ultimately optimizing the resource usage of the virtual skeletal animation model during navigation. In addition, a frame skipping strategy can also achieve stable playback of the virtual skeletal animation model under different map rendering frame rates.

[0147] Please see Figure 7 , Figure 7 This is a schematic flowchart of a data processing method provided in an embodiment of this application. This data processing method can be executed by a terminal device. Figure 7 As shown, the data processing method may include at least the following steps S201-S210:

[0148] Step S201, in response to the setting operation for navigation guidance markers in the map application, load the virtual skeletal animation model carrying the total skeletal animation data indicated by the setting operation from the business server;

[0149] The specific process for this step can be found above. Figure 3 Step S101 in the corresponding embodiment will not be described again here.

[0150] Step S202: The virtual skeletal animation model is parsed and processed in the map rendering engine, and the total skeletal animation data associated with the virtual skeletal animation model is moved from the central processing unit to the graphics processing unit.

[0151] The specific process for this step can be found above. Figure 3 Step S101 in the corresponding embodiment will not be described again here.

[0152] Step S203: Based on the driving status of the driving object associated with the map application and the traffic status of the area where the driving object is located, read the target skeletal animation data from the total skeletal animation data;

[0153] The specific process for this step can be found above. Figure 3 Step S101 in the corresponding embodiment will not be described again here.

[0154] Step S204: When rendering the map, obtain the rendering timestamp and reference playback frame rate, and generate compressed interpolated bone data for the electronic map based on the rendering timestamp, reference playback frame rate and compressed bone data of at least two compressed key bone animation frames.

[0155] The specific process for this step can be found above. Figure 3 Step S102 in the corresponding embodiment will not be described again here.

[0156] Step S205: Obtain the spatial transformation matrix for fitting the virtual skeletal animation model with the electronic map of the map application, and generate a second transformation matrix based on the spatial transformation matrix.

[0157] The specific process for this step can be found above. Figure 3 Step S102 in the corresponding embodiment will not be described again here.

[0158] Step S206: The second transformation matrix and the M compressed bone matrices in the compressed interpolated bone data are spliced ​​together to obtain a one-dimensional spliced ​​array, and the one-dimensional spliced ​​array is uploaded to the graphics processor.

[0159] The specific process for this step can be found above. Figure 3 Step S102 in the corresponding embodiment will not be described again here.

[0160] Step S207: In the graphics processor, data recovery is performed on the compressed interpolated skeleton data to obtain interpolated skeleton data, and a first transformation matrix corresponding to the model vertex is generated based on the vertex data of the model vertex and the interpolated skeleton data.

[0161] The specific process for this step can be found above. Figure 3 Step S102 in the corresponding embodiment will not be described again here.

[0162] Step S208: Perform position transformation on the model vertices according to the first transformation matrix and the second transformation matrix to obtain the model vertices after position transformation;

[0163] The specific process for this step can be found above. Figure 3 Step S102 in the corresponding embodiment will not be described again here.

[0164] Step S209: Based on the target vertex position corresponding to the model vertex after position transformation, the basic texture information stored in the vertex buffer object, the index order stored in the index buffer object, and the texture transformation data associated with the model vertex, the model is rendered in the electronic map, and the navigation guide sign corresponding to the virtual skeletal animation model is displayed.

[0165] The specific process for this step can be found above. Figure 3 Step S103 in the corresponding embodiment will not be described again here.

[0166] This application's embodiments, by introducing a dynamic virtual skeletal animation model, enable the three-dimensional display of navigation guidance signs. Since the target skeletal animation data is related to the current driving state of the object and the nearby traffic conditions, different guidance effects can be displayed based on different driving and traffic states during navigation, thus enriching the display effects of navigation guidance signs. Furthermore, pre-calculating the compressed skeletal data for each compressed key skeletal animation frame before model delivery and processing the model vertices in the graphics processor (GPU) reduces the CPU's occupancy, optimizing CPU performance. Simultaneously, transmitting the obtained compressed key skeletal animation frames and compressed interpolated skeletal animation frames to the GPU in compressed data format saves bandwidth and memory compared to uploading each skeletal animation frame to the GPU, ultimately optimizing resource usage of the virtual skeletal animation model during navigation.

[0167] Please see Figure 8 , Figure 8 This is a schematic diagram of a data processing scenario provided in an embodiment of this application. This data processing scenario can be handled by a terminal device (e.g., Figure 1 The terminal device 200a) shown is implemented as follows. Figure 8As shown, the terminal device can acquire a virtual skeletal animation model carrying total skeletal animation data. After parsing and processing the virtual skeletal animation model, the total skeletal animation data it carries can be obtained. This total skeletal animation data can then be moved from the CPU to the GPU and executed only once. It can be understood that after the vertex data is moved to the GPU, the vertex data in the CPU can be deleted to reduce memory usage, but the compressed bone data in the CPU still needs to be retained for subsequent interpolation calculations. The total skeletal animation data can include multiple compressed key skeletal animation frames (e.g., compressed key skeletal animation frames frame0-frameQ). The compressed bone data (also collectively referred to as animation parameters) of each compressed key skeletal animation frame contains the motion matrices corresponding to all virtual bones in the virtual skeletal animation model (e.g., virtual bones bone_0-virtual bones bone_m). It can be understood that the motion matrix is ​​obtained by matrix compression of the bone matrix. Therefore, compared to directly uploading key skeletal animation frames carrying bone matrices, uploading compressed key skeletal animation frames carrying motion matrices to the GPU can save bandwidth and memory usage per frame uploaded to the GPU, ultimately achieving memory performance optimization. The specific data content and model format of the total skeletal animation data can be found above. Figure 4 The descriptions in the corresponding embodiments will not be repeated here. In the embodiments of this application, the rendering timestamp specifically refers to the timestamp when the map rendering engine calls the draw method, where the draw method is a class method of the virtual skeletal animation model. Figure 8As shown, when the map refreshes, the map rendering engine calls the `draw` method. Based on the corresponding rendering timestamp and reference playback frame rate, the animation frame indices corresponding to the compressed keybone animation frames before and after the interpolation point can be obtained. Then, based on these two animation frame indices, the corresponding two compressed keybone animation frames can be found in the animation parameters. Subsequently, the required compressed interpolated bone animation frame can be obtained by interpolating the compressed bone data of these two compressed keybone animation frames. This compressed interpolated bone animation frame also includes the compressed bone matrices corresponding to virtual bones bone_0 to bone_m. Furthermore, the terminal device can generate a spatial transformation matrix based on the rotation, translation, and scaling of the car logo on the electronic map. Then, based on the spatial transformation matrix, view matrix, and projection matrix, a second transformation matrix (i.e., the MVP matrix) can be generated. Further, the second transformation matrix and the compressed bone matrices corresponding to virtual bones bone_0 to bone_m can be concatenated into a one-dimensional array and uploaded to the GPU through a relevant transmission interface. It is understandable that each compressed interpolated skeletal animation frame only needs to be transmitted once, and to ensure compatibility with OpenGL ES 2.0 (an industry-standard Application Programming Interface (API) that can greatly improve the 3D graphics rendering speed of different terminal devices), the number of virtual bones supported is 40. Specifically, the transmission interface here can be the gIUniform4fv interface (an OpenGL interface that can upload data from the CPU to video memory). Further, in the vertex shader, based on the bone index of the virtual bones bound to the model vertices, the corresponding 3*4 compressed bone matrix can be obtained from the one-dimensional concatenation array for data reconstruction, resulting in a 4*4 bone transformation matrix. Based on the operational characteristics of OpenGL (using column-major order, unlike the row-major order used in one-dimensional concatenation arrays), the bone transformation matrix can be transposed. Then, based on the transposed bone transformation matrix and vertex data, the first transformation matrix can be calculated. After processing the first and second transformation matrices, the model vertices after position transformation can be obtained, and finally, the corresponding navigation guide markers can be drawn.

[0168] For ease of understanding, please refer to the following: Figure 9 , Figure 9 This is a schematic diagram illustrating the process of transforming the vertex position of a model according to an embodiment of this application. For example... Figure 9As shown, the original model vertices are located in the model coordinate system, corresponding to the initial vertex positions. After accumulating the relevant bone transformation matrices according to the weights, the first transformation matrix corresponding to the model vertex can be obtained. Based on the first transformation matrix, the model vertex is transformed to obtain the model vertex that follows the changes of the virtual skeleton. Furthermore, the model vertices that follow the changes of the virtual skeleton can be transformed into the world coordinate system through the model-map adaptation matrix (i.e., the M matrix, also known as the spatial transformation matrix). Then, the model vertices in the world coordinate system can be transformed into the camera-centered coordinate system (i.e., the viewpoint coordinate system) through the view matrix (i.e., the V matrix). Finally, the model vertices in the viewpoint coordinate system can be transformed onto the screen through the projection matrix (i.e., the P matrix).

[0169] Please see Figure 10 , Figure 10 This is a flowchart illustrating a data processing procedure provided in an embodiment of this application. Figure 10 As shown, the data processing procedure may include:

[0170] (1) Designers can use software such as Maya or 3DMax to compile 3D animation models and export them as 3D skeleton models in common model formats such as FBX and glTF.

[0171] (2) Before the model is deployed online, a 3D skeletal model with a general model format can be converted locally into a virtual skeletal animation model with a proprietary model format. This proprietary model format is a custom binary format suitable for terminal devices. A description of this proprietary model format can be found above. Figure 4 The corresponding implementation examples will not be elaborated here. It should be noted that compared with the general model format, which has a complex decoding process, the proprietary model format has less data. During format conversion, the data required for the electronic map can be extracted from the data obtained by parsing the general model format and organized into a proprietary model format (e.g., calculating the skeleton matrix and compressing it into an action matrix). This is equivalent to splitting the "download -> parsing -> rendering" process that the terminal device originally had to execute into two parts: the "parsing -> conversion to proprietary model format" process pre-executed by the business server and the "proprietary model format download -> rendering" process executed by the terminal device. This eliminates the need to introduce a large parsing library into the map application, thereby improving parsing efficiency, increasing parsing reliability, and optimizing resource consumption.

[0172] (3) The terminal device downloads the virtual skeletal animation model with a proprietary model format through the network, and performs format parsing in the map rendering engine to read the initial vertex position, vertex index, texture coordinates, bone-related data and other data (i.e., total skeletal animation data), and uploads these data from memory (the storage space for CPU temporary data) to video memory (the storage space for GPU temporary data).

[0173] (4) The terminal device can select the compressed bone data of two compressed key bone animation frames according to the input time parameter (i.e. rendering timestamp), perform interpolation calculation, and upload the resulting compressed interpolated bone data to the video memory and render the final model.

[0174] It is understood that the method provided in this application embodiment can be applied to any terminal device that supports OpenGL ES 2.0, and has no negative effect on resource consumption.

[0175] Please see Figure 11 , Figure 11 This is a schematic diagram of a thread call provided in an embodiment of this application. For example... Figure 11 As shown, the main thread refers to the thread where the UI (User Interface) interface resides; the resource loading thread is used to generate the data required by the rendering thread, such as converting the binary data of the virtual skeletal animation model into meaningful results (e.g., vertex data, compressed bone data, etc.), and decompressing compressed textures (e.g., PNG or JPG format); the rendering thread is used to render the navigation guide signs corresponding to the virtual skeletal animation model on the electronic map, including real-time calculation of interpolation (i.e., generating compressed interpolated skeletal animation frames).

[0176] In this embodiment, the main thread can notify the rendering thread of the currently used identifier type (setLocatorType) based on the setting operation for the navigation guide identifier. For example, it can include a normal 2D car logo type and a dynamic 3D car logo type. The terminal device can copy the textures associated with the virtual skeletal animation model through the main thread, and then decompress the compressed textures through the resource loading thread, and upload the decompressed textures to the GPU. Subsequently, the rendering thread can generate corresponding texture conversion data based on the decompressed textures. In addition, the resource loading thread can also calculate the first size parameter of the spatial bounding box. Similarly, the terminal device can also copy the virtual skeletal animation model with a custom binary format (e.g., proprietary model format) through the main thread, so that the resource loading thread can decompress and parse the virtual skeletal animation model to obtain the corresponding vertex data and compressed bone data, and upload them to the GPU. Among them, for vertex data, the rendering thread can bind data of static type (e.g., initial vertex position, texture coordinates, etc.) to VBO, and bind data of dynamic type (e.g., index order) to IBO. Finally, the rendering thread can return the corresponding model loading result to the main thread, informing the main thread whether the loading was successful or an error occurred.

[0177] It is understood that the resource loading thread and rendering thread in this embodiment are asynchronous with respect to the main thread, and therefore will not block the main thread where the UI is located.

[0178] This application's embodiments enable skeletal animation rendering technology for navigation guide signs. By introducing a dynamic virtual skeletal animation model, it achieves a three-dimensional display of navigation guide signs and enriches their display effects. Furthermore, by performing the parsing process before the model is uploaded, the CPU usage can be reduced, optimizing CPU performance. Simultaneously, it saves bandwidth and memory spent uploading skeletal animation frames to the graphics processor, ultimately optimizing resource usage of the virtual skeletal animation model in navigation.

[0179] Please see Figure 12 This is a schematic diagram of the structure of a data processing apparatus provided in an embodiment of this application. The data processing apparatus can be a computer program (including program code) running on a computer device; for example, the data processing apparatus is application software. The apparatus can be used to execute corresponding steps in the data processing method provided in the embodiments of this application. Figure 12 As shown, the data processing device 1 may include: a model acquisition module 11, an interpolation transmission module 12, a model rendering module 13, a first matrix generation module 14, a second matrix generation module 15, and a position transformation module 16.

[0180] The model acquisition module 11 is used to acquire a virtual skeletal animation model in a map application and to acquire target skeletal animation data associated with the virtual skeletal animation model. The target skeletal animation data includes model vertices and at least two compressed key skeletal animation frames contained in the virtual skeletal animation model.

[0181] The model acquisition module 11 may include: a model loading unit 111, a model parsing unit 112, and a data reading unit 113;

[0182] Model loading unit 111 is used to load a virtual skeletal animation model carrying total skeletal animation data from the business server in response to a setting operation for a navigation guide icon in a map application.

[0183] The model parsing unit 112 is used to call the resource loading thread to parse and process the virtual skeletal animation model in the map rendering engine, and to move the total skeletal animation data associated with the virtual skeletal animation model from the central processing unit to the graphics processing unit.

[0184] The data reading unit 113 is used in the graphics processor to determine the type of action displayed by the virtual skeletal animation model based on the driving state of the driving object associated with the map application and the traffic state of the area where the driving object is located; to read the target skeletal animation data associated with the action type from the total skeletal animation data through the map rendering engine; and to associate at least two compressed key skeletal animation frames with the action type.

[0185] The graphics processor is used to bind vertex buffer objects and index buffer objects.

[0186] The specific functional implementation methods of the model loading unit 111, model parsing unit 112, and data reading unit 113 can be found in the above description. Figure 3 Step S101 in the corresponding embodiment will not be described again here.

[0187] The interpolation transmission module 12 is used to generate compressed interpolated skeletal animation frames in at least two compressed key skeletal animation frames and transmit the compressed interpolated skeletal animation frames to the graphics processor; the compressed interpolated skeletal animation frames are used to perform position transformations on the model vertices in the graphics processor.

[0188] Among them, compressed interpolated skeletal animation frames include compressed interpolated skeletal data;

[0189] The interpolation transmission module 12 is specifically used to generate compressed interpolated bone data from the compressed bone data of at least two compressed key bone animation frames, and transmit the compressed interpolated bone data to the graphics processor; the compressed bone data of at least two compressed key bone animation frames is obtained by the business server performing matrix compression on the bone data in at least two key bone animation frames, and matrix compression refers to removing redundant data contained in the bone matrix in the bone data.

[0190] The interpolation transmission module 12 may include: an interpolation generation unit 121 and a data transmission unit 122;

[0191] The interpolation generation unit 121 is used to generate compressed interpolated bone data for the electronic map from compressed bone data of at least two compressed key bone animation frames based on a frame skipping strategy used to control the smooth display of the virtual skeletal animation model; the compressed interpolated bone data includes M compressed bone matrices, one compressed bone matrix corresponds to one virtual bone in the virtual skeletal animation model, and M is a positive integer;

[0192] The frame skipping strategy includes the reference playback frame rate corresponding to the virtual skeletal animation model;

[0193] The interpolation generation unit 121 may include: an acquisition subunit 1211 and a generation subunit 1212;

[0194] Get sub-unit 1211, used to obtain the rendering timestamp and reference playback frame rate when performing map rendering; the rendering timestamp refers to the time when the map rendering engine triggers the electronic map to render and update;

[0195] Generating subunit 1212 is used to generate compressed interpolated bone data for electronic maps based on the rendering timestamp, reference playback frame rate and compressed bone data of at least two compressed key bone animation frames.

[0196] Specifically, the aforementioned generation subunit 1212 is used to obtain a first compressed key skeleton animation frame and a second compressed key skeleton animation frame from at least two compressed key skeleton animation frames based on the rendering timestamp and the reference playback frame rate; and to perform interpolation processing on the compressed skeleton data of the first compressed key skeleton animation frame and the compressed skeleton data of the second compressed key skeleton animation frame to generate compressed interpolated skeleton data for the electronic map.

[0197] The reference playback frame rate refers to the number of compressed key skeleton animation frames contained within a unit of time.

[0198] The aforementioned generation subunit 1212 is specifically used to obtain the start timestamp corresponding to the starting compressed key skeletal animation frame in rendering at least two compressed key skeletal animation frames, determine the target duration based on the start timestamp and the rendering timestamp, perform a modulo operation on the target duration based on the unit duration to obtain the modulo result, determine the first animation frame index and the second animation frame index based on the modulo result, obtain the first compressed key skeletal animation frame from at least two compressed key skeletal animation frames according to the first animation frame index, and obtain the second compressed key skeletal animation frame from at least two compressed key skeletal animation frames according to the second animation frame index.

[0199] The specific implementation methods for obtaining subunit 1211 and generating subunit 1212 can be found above. Figure 3 Step S102 in the corresponding embodiment will not be described again here.

[0200] Data transmission unit 122 is used to transmit M compressed skeleton matrices and a second transformation matrix to the graphics processor;

[0201] Specifically, the data transmission unit 122 is used to perform splicing processing on the second transformation matrix and M compressed skeleton matrices to obtain a one-dimensional splicing array, and then upload the one-dimensional splicing array to the graphics processor.

[0202] The specific functional implementation methods of the interpolation generation unit 121 and the data transmission unit 122 can be found in the above description. Figure 3 Step S102 in the corresponding embodiment will not be described again here.

[0203] Model rendering module 13 is used to render the navigation guide sign corresponding to the virtual skeletal animation model in the electronic map of the map application based on the model vertices after position transformation;

[0204] The model rendering module 13 may include: a fourth acquisition unit 131, a rendering and display unit 132, a map display unit 133, and an identifier display unit 134.

[0205] The fourth acquisition unit 131 is used to acquire the index order for vertex rendering from the index buffer object associated with the graphics processor; the index buffer object stores dynamic data of the vertex data of the model vertices, and the index order is dynamic.

[0206] The rendering and display unit 132 is used to render the model on the electronic map based on the target vertex position corresponding to the model vertex after position transformation, the basic texture information stored in the vertex buffer object, the index order, and the texture conversion data associated with the model vertex, and to display the navigation guide sign corresponding to the virtual skeletal animation model; the texture conversion data is generated by the graphics processor based on the received decompressed texture; the decompressed texture is obtained by decompressing the texture associated with the virtual skeletal animation model in the resource loading thread;

[0207] Map display unit 133 is used to display an electronic map for navigation in a map application;

[0208] The identification display unit 134 is used to display navigation guidance icons corresponding to the virtual skeletal animation model with the target action type in the electronic map based on the model vertices after position transformation; the target action type is determined based on the driving status of the driving object associated with the map application and the traffic status of the area where the driving object is located; the navigation guidance icons are used to indicate the position of the driving object in the electronic map.

[0209] The specific functional implementation methods of the fourth acquisition unit 131, rendering and display unit 132, map display unit 133, and marker display unit 134 can be found above. Figure 3 Step S103 in the corresponding embodiment will not be described again here.

[0210] The first matrix generation module 14 is used to perform data recovery on compressed interpolated skeleton data in the graphics processor to obtain interpolated skeleton data, and generate the first transformation matrix corresponding to the model vertices based on the vertex data of the model vertices and the interpolated skeleton data.

[0211] The virtual skeletal animation model contains N model vertices, where N is a positive integer; the N model vertices include model vertex i, where i is a positive integer less than or equal to N;

[0212] The first matrix generation module 14 may include: a third acquisition unit 141, a data recovery unit 142, and a third generation unit 143;

[0213] The third acquisition unit 141 is used to acquire the bone index and weight of the target virtual bone bound to the model vertex i from the vertex buffer object associated with the graphics processor; the vertex buffer object stores static data from the vertex data of the model vertex i, and the bone index and weight of the target virtual bone are both static; the number of target virtual bones is less than or equal to M.

[0214] The data recovery unit 142 is used to obtain the compressed bone matrix corresponding to the target virtual bone from the M compressed bone matrices carried by the one-dimensional concatenation array according to the bone index of the target virtual bone, add redundant data to the compressed bone matrix corresponding to the target virtual bone, and obtain the bone transformation matrix corresponding to the target virtual bone; the size of the bone transformation matrix is ​​larger than the size of the compressed bone matrix.

[0215] The third generation unit 143 is used to generate the first transformation matrix corresponding to model vertex i based on the bone transformation matrix corresponding to the target virtual skeleton and the weight of the target virtual skeleton.

[0216] The specific functional implementation methods of the third acquisition unit 141, data recovery unit 142, and third generation unit 143 can be found above. Figure 3 Step S102 in the corresponding embodiment will not be described again here.

[0217] The second matrix generation module 15 is used to obtain a spatial transformation matrix for fitting the virtual skeletal animation model with an electronic map of a map application, and to generate a second transformation matrix based on the spatial transformation matrix.

[0218] The second matrix generation module 15 may include: a first acquisition unit 151, a second acquisition unit 152, a first generation unit 153, and a second generation unit 154.

[0219] The first acquisition unit 151 is used to acquire the label offset matrix and label rotation matrix corresponding to the electronic map of the map application; the label offset matrix is ​​used to represent the offset distance between the geographical location of the navigation guide label and the center position of the electronic map; the label rotation matrix is ​​used to represent the rotation of the electronic map relative to the northeast-sky coordinate system;

[0220] The second acquisition unit 152 is used to acquire the first size parameter of the spatial bounding box associated with the virtual skeletal animation model, acquire the second size parameter of the virtual compass used to indicate the map orientation, and generate an identifier scaling ratio based on the first size parameter and the second size parameter.

[0221] The first dimension parameter includes the first length parameter, the first width parameter, and the height parameter of the spatial bounding box; the second dimension parameter includes the second length parameter and the second width parameter of the virtual compass.

[0222] The second acquisition unit 152 is specifically used to acquire a first ratio between the second length parameter and the first length parameter, acquire a second ratio between the second width parameter and the first width parameter, and determine the minimum value between the first ratio and the second ratio as the identification scaling ratio.

[0223] The first generation unit 153 is used to generate a spatial transformation matrix based on the identifier offset matrix, the identifier rotation matrix, and the identifier scaling ratio; the spatial transformation matrix is ​​used to transform the virtual skeletal animation model from the model coordinate system to the map coordinate system where the electronic map is located.

[0224] The second generation unit 154 is used to obtain the view matrix and projection matrix associated with the electronic map, and generate a second transformation matrix based on the spatial transformation matrix, view matrix and projection matrix.

[0225] The specific functional implementation methods of the first acquisition unit 151, the second acquisition unit 152, the first generation unit 153, and the second generation unit 154 can be found above. Figure 3 Step S102 in the corresponding embodiment will not be described again here.

[0226] The position transformation module 16 is used to transform the position of the model vertices according to the first transformation matrix and the second transformation matrix to obtain the model vertices after position transformation.

[0227] The vertex buffer object stores the initial vertex position of model vertex i; the initial vertex position of model vertex i is of static type.

[0228] The position transformation module 16 may include: a first transformation unit 161 and a second transformation unit 162;

[0229] The first transformation unit 161 is used to generate the intermediate vertex position of model vertex i based on the initial vertex position of model vertex i and the second transformation matrix.

[0230] The second transformation unit 162 is used to generate the target vertex position of model vertex i based on the middle vertex position of model vertex i and the first transformation matrix corresponding to model vertex i.

[0231] The specific functional implementation methods of the first transformation unit 161 and the second transformation unit 162 can be found in the above description. Figure 3 Step S102 in the corresponding embodiment will not be described again here.

[0232] The virtual skeletal animation model has a proprietary model format; the vertex data of the model vertices belongs to the child nodes of the data header of the total skeletal animation data with a proprietary model format; the compressed skeletal data of at least two compressed key skeletal animation frames are used to indicate the motion state of the virtual bones in the virtual skeletal animation model; the model vertices are bound to the virtual bones; the data header includes version information, basic vertex parameters, and an overall transformation matrix used to adjust the display origin of the virtual skeletal animation model in the electronic map.

[0233] The specific functional implementations of the model acquisition module 11, interpolation transmission module 12, model rendering module 13, first matrix generation module 14, second matrix generation module 15, and position transformation module 16 can be found above. Figure 3 Steps S101-S103 in the corresponding embodiments will not be described again here. Furthermore, the beneficial effects of using the same method will also not be described again.

[0234] Please see Figure 13 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 13 As shown, the computer device 1000 may include a processor 1001, a network interface 1004, and a memory 1005. Furthermore, the computer device 1000 may also include a user interface 1003 and at least one communication bus 1002. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen and a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 1005 may also be at least one storage device located remotely from the processor 1001. Figure 13 As shown, the memory 1005, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application.

[0235] In such Figure 13 In the computer device 1000 shown, the network interface 1004 provides network communication functionality; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to execute the aforementioned... Figure 3 , Figure 7The description of the data processing method in any corresponding embodiment will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0236] Furthermore, it should be noted that this application embodiment also provides a computer-readable storage medium, which stores a computer program executed by the aforementioned data processing device 1. The computer program includes program instructions, and when the processor executes the program instructions, it can execute the aforementioned... Figure 3 , Figure 7 The description of the data processing method in any corresponding embodiment is already provided, and therefore will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer-readable storage medium embodiments related to this application, please refer to the description of the method embodiments of this application.

[0237] The aforementioned computer-readable storage medium can be an internal storage unit of the data processing apparatus or computer device provided in any of the foregoing embodiments, such as a hard disk or memory of the computer device. The computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the computer device. Furthermore, the computer-readable storage medium can include both internal and external storage units of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0238] Furthermore, it should be noted that this application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. The processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the aforementioned... Figure 3 , Figure 7 The method is provided in any of the corresponding embodiments. Furthermore, the beneficial effects of using the same method will not be repeated here. For technical details not disclosed in the computer program products or computer program embodiments involved in this application, please refer to the description of the method embodiments of this application.

[0239] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0240] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0241] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A data processing method, characterized in that, include: In a map application, a virtual skeletal animation model is obtained, and target skeletal animation data associated with the virtual skeletal animation model is acquired. The target skeletal animation data includes the model vertices contained in the virtual skeletal animation model and at least two compressed key skeletal animation frames; A compressed interpolated skeletal animation frame is generated from the at least two compressed key skeletal animation frames, and the compressed interpolated skeletal animation frame is transmitted to a graphics processor; the compressed interpolated skeletal animation frame is used to perform position transformation on the model vertices in the graphics processor; the compressed interpolated skeletal animation frame includes compressed interpolated skeletal data. In the graphics processor, the compressed interpolated skeleton data is restored to obtain interpolated skeleton data, and a first transformation matrix corresponding to the model vertex is generated based on the vertex data of the model vertex and the interpolated skeleton data. Obtain a spatial transformation matrix for fitting the virtual skeletal animation model to the electronic map of the map application, and generate a second transformation matrix based on the spatial transformation matrix; The model vertices are transformed according to the first transformation matrix and the second transformation matrix to obtain the transformed model vertices. Based on the model vertices after position transformation, the navigation guide icon corresponding to the virtual skeletal animation model is rendered in the electronic map of the map application.

2. The method according to claim 1, characterized in that, The step of generating compressed interpolated skeletal animation frames from the at least two compressed key skeletal animation frames and transmitting the compressed interpolated skeletal animation frames to the graphics processor includes: The compressed interpolated bone data is generated from the compressed bone data of the at least two compressed key bone animation frames, and the compressed interpolated bone data is transmitted to the graphics processor. The compressed bone data of the at least two compressed key bone animation frames is obtained by the service server performing matrix compression on the bone data of the at least two key bone animation frames. The matrix compression refers to removing redundant data contained in the bone matrix in the bone data.

3. The method according to claim 2, characterized in that, The step of obtaining the spatial transformation matrix for fitting the virtual skeletal animation model to the electronic map of the map application, and generating a second transformation matrix based on the spatial transformation matrix, includes: Obtain the identifier offset matrix and identifier rotation matrix corresponding to the electronic map of the map application; the identifier offset matrix is ​​used to represent the offset distance between the geographical location of the navigation guide identifier and the center position of the electronic map; the identifier rotation matrix is ​​used to represent the rotation of the electronic map relative to the northeast-central coordinate system; Obtain the first size parameter of the spatial bounding box associated with the virtual skeletal animation model, obtain the second size parameter of the virtual compass used to indicate map orientation, and generate an identifier scaling ratio based on the first size parameter and the second size parameter; A spatial transformation matrix is ​​generated based on the identifier offset matrix, the identifier rotation matrix, and the identifier scaling ratio; the spatial transformation matrix is ​​used to transform the virtual skeletal animation model from the model coordinate system to the map coordinate system where the electronic map is located. Obtain the view matrix and projection matrix associated with the electronic map, and generate a second transformation matrix based on the spatial transformation matrix, the view matrix, and the projection matrix.

4. The method according to claim 3, characterized in that, The first dimension parameter includes the first length parameter, the first width parameter, and the height parameter of the spatial bounding box; the second dimension parameter includes the second length parameter and the second width parameter of the virtual compass; The step of generating the identifier scaling ratio based on the first size parameter and the second size parameter includes: Obtain the first ratio between the second length parameter and the first length parameter, and obtain the second ratio between the second width parameter and the first width parameter; The minimum value between the first ratio and the second ratio is determined as the identification scaling ratio.

5. The method according to claim 2, characterized in that, The step of generating the compressed interpolated bone data from the compressed bone data of the at least two compressed key skeleton animation frames, and transmitting the compressed interpolated bone data to the graphics processor, includes: Based on the frame skipping strategy used to control the smooth display of the virtual skeletal animation model, compressed interpolated skeletal data for the electronic map is generated from the compressed skeletal data of the at least two compressed key skeletal animation frames; the compressed interpolated skeletal data includes M compressed skeletal matrices, one compressed skeletal matrix corresponds to one virtual bone in the virtual skeletal animation model, and M is a positive integer; The M compressed skeleton matrices and the second transformation matrix are transmitted to the graphics processor.

6. The method according to claim 5, characterized in that, The frame skipping strategy includes the reference playback frame rate corresponding to the virtual skeletal animation model; The method of generating compressed interpolated skeletal data for the electronic map from the compressed skeletal data of at least two compressed key skeletal animation frames, based on a frame-skipping strategy for controlling the smooth display of the virtual skeletal animation model, includes: During map rendering, the rendering timestamp and the reference playback frame rate are obtained; the rendering timestamp refers to the time when the map rendering engine triggers the electronic map to render and update. Based on the rendering timestamp, the reference playback frame rate, and the compressed bone data of at least two compressed key skeletal animation frames, the compressed interpolated bone data for the electronic map is generated.

7. The method according to claim 6, characterized in that, The process of generating compressed interpolated skeleton data for the electronic map based on the rendering timestamp, the reference playback frame rate, and the compressed skeleton data of at least two compressed key skeleton animation frames includes: Based on the rendering timestamp and the reference playback frame rate, the first compressed key skeleton animation frame and the second compressed key skeleton animation frame are obtained from the at least two compressed key skeleton animation frames. The compressed bone data of the first compressed key skeleton animation frame and the compressed bone data of the second compressed key skeleton animation frame are interpolated to generate the compressed interpolated bone data for the electronic map.

8. The method according to claim 7, characterized in that, The reference playback frame rate refers to the number of compressed key skeleton animation frames contained within a unit of time; obtaining the first compressed key skeleton animation frame and the second compressed key skeleton animation frame from the at least two compressed key skeleton animation frames based on the rendering timestamp and the reference playback frame rate includes: Obtain the start timestamp corresponding to the start compressed key skeleton animation frame in the rendering of the at least two compressed key skeleton animation frames, and determine the target duration based on the start timestamp and the rendering timestamp; The target duration is moduloed based on the unit duration to obtain the remainder result; Based on the remainder result, a first animation frame index and a second animation frame index are determined. A first compressed key skeleton animation frame is obtained from the at least two compressed key skeleton animation frames according to the first animation frame index, and a second compressed key skeleton animation frame is obtained from the at least two compressed key skeleton animation frames according to the second animation frame index.

9. The method according to claim 5, characterized in that, The step of transmitting the M compressed skeleton matrices and the second transformation matrix to the graphics processor includes: The second transformation matrix and the M compressed skeleton matrices are concatenated to obtain a one-dimensional concatenated array, which is then uploaded to the graphics processor.

10. The method according to claim 9, characterized in that, The virtual skeletal animation model contains N model vertices, where N is a positive integer; the N model vertices include model vertex i, where i is a positive integer less than or equal to N; In the graphics processor, data recovery is performed on the compressed interpolated skeleton data to obtain interpolated skeleton data. A first transformation matrix corresponding to the model vertices is generated based on the vertex data of the model vertices and the interpolated skeleton data, including: In the vertex buffer object associated with the graphics processor, the bone index and weight of the target virtual bone bound to the model vertex i are obtained; the vertex buffer object stores static data from the vertex data of the model vertex i, and the bone index and weight of the target virtual bone are both of the static type; the number of target virtual bones is less than or equal to M; Based on the bone index of the target virtual bone, the compressed bone matrix corresponding to the target virtual bone is obtained from the M compressed bone matrices carried by the one-dimensional concatenation array. The redundant data is added to the compressed bone matrix corresponding to the target virtual bone to obtain the bone transformation matrix corresponding to the target virtual bone. The size of the bone transformation matrix is ​​larger than the size of the compressed bone matrix. Based on the bone transformation matrix corresponding to the target virtual skeleton and the weights of the target virtual skeleton, a first transformation matrix corresponding to the model vertex i is generated.

11. The method according to claim 10, characterized in that, The vertex buffer object stores the initial vertex position of model vertex i; the initial vertex position of model vertex i belongs to the static type; The step of performing position transformation on the model vertices according to the first transformation matrix and the second transformation matrix to obtain the position-transformed model vertices includes: Based on the initial vertex position of the model vertex i and the second transformation matrix, the intermediate vertex position of the model vertex i is generated; Based on the middle vertex position of the model vertex i and the first transformation matrix corresponding to the model vertex i, the target vertex position of the model vertex i is generated; The rendering of navigation guidance markers corresponding to the virtual skeletal animation model in the electronic map of the map application based on the model vertices after position transformation includes: In the index buffer object associated with the graphics processor, the index order for vertex rendering is obtained; the index buffer object stores the dynamic type of vertex data of the model vertices, and the index order belongs to the dynamic type; Based on the target vertex position corresponding to the model vertex after position transformation, the basic texture information stored in the vertex buffer object, the index order, and the texture conversion data associated with the model vertex, the model is rendered in the electronic map to display the navigation guide icon corresponding to the virtual skeletal animation model; the texture conversion data is generated by the graphics processor based on the received decompressed texture; the decompressed texture is obtained by decompressing the texture associated with the virtual skeletal animation model in the resource loading thread.

12. The method according to claim 11, characterized in that, The step of obtaining a virtual skeletal animation model in a map application and obtaining target skeletal animation data associated with the virtual skeletal animation model includes: In response to a setting operation for a navigation guidance identifier in the map application, a virtual skeletal animation model carrying total skeletal animation data, as indicated by the setting operation, is loaded from the business server. The resource loading thread is invoked to parse and process the virtual skeletal animation model in the map rendering engine, and the total skeletal animation data associated with the virtual skeletal animation model is moved from the central processing unit to the graphics processing unit. In the graphics processor, the type of motion displayed by the virtual skeletal animation model is determined based on the driving status of the driving object associated with the map application and the traffic status of the area where the driving object is located; The target skeletal animation data associated with the action type is read from the total skeletal animation data through the map rendering engine; the at least two compressed key skeletal animation frames are associated with the action type; The graphics processor is used to bind the vertex buffer object and the index buffer object.

13. The method according to claim 12, characterized in that, The virtual skeletal animation model has a proprietary model format; the vertex data of the model vertices belongs to the child nodes of the data header of the total skeletal animation data having the proprietary model format; the compressed skeletal data of at least two compressed key skeletal animation frames are used to indicate the motion state of the virtual bones in the virtual skeletal animation model; the model vertices are bound to the virtual bones; the data header includes version information, basic vertex parameters, and an overall transformation matrix for adjusting the display origin of the virtual skeletal animation model in the electronic map.

14. The method according to claim 1, characterized in that, The rendering of navigation guidance markers corresponding to the virtual skeletal animation model in the electronic map of the map application based on the model vertices after position transformation includes: Display electronic maps for navigation in map applications; Based on the model vertices after position transformation, navigation guidance icons corresponding to the virtual skeletal animation model with the target action type are displayed in the electronic map; the target action type is determined based on the driving status of the driving object associated with the map application and the traffic status of the area where the driving object is located; the navigation guidance icons are used to indicate the position of the driving object in the electronic map.

15. A data processing apparatus, characterized in that, include: The model acquisition module is used to acquire a virtual skeletal animation model in a map application and to acquire target skeletal animation data associated with the virtual skeletal animation model. The target skeletal animation data includes the model vertices contained in the virtual skeletal animation model and at least two compressed key skeletal animation frames; An interpolation transmission module is used to generate compressed interpolated skeletal animation frames from the at least two compressed key skeletal animation frames, and to transmit the compressed interpolated skeletal animation frames to a graphics processor; the compressed interpolated skeletal animation frames are used to perform position transformations on the model vertices in the graphics processor; the compressed interpolated skeletal animation frames include compressed interpolated skeletal data. The first matrix generation module is used in the graphics processor to perform data recovery on the compressed interpolated skeleton data to obtain interpolated skeleton data, and to generate a first transformation matrix corresponding to the model vertex based on the vertex data of the model vertex and the interpolated skeleton data. The second matrix generation module is used to obtain a spatial transformation matrix for fitting the virtual skeletal animation model with the electronic map of the map application, and to generate a second transformation matrix based on the spatial transformation matrix. The position transformation module is used to transform the position of the model vertex according to the first transformation matrix and the second transformation matrix to obtain the model vertex after position transformation. The model rendering module is used to render the navigation guide icon corresponding to the virtual skeletal animation model in the electronic map of the map application based on the model vertices after position transformation.

16. A computer device, characterized in that, include: Processor and memory; The processor is connected to the memory, wherein the memory is used to store a computer program, and the processor is used to invoke the computer program to cause the computer device to perform the method according to any one of claims 1-14.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1-14.

18. A computer program product, characterized in that, The computer program product includes computer instructions stored in a computer-readable storage medium, the computer instructions being adapted to be read and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1-14.

Images