Constant line width rendering method and system for robot map paths, storage medium

Abstract

The application discloses a kind of constant line width rendering method and system of robot map path, storage medium, the method includes: the ordered path point sequence is preprocessed once, and the vertex with vertex coordinate being located on path center line and carrying normal vector and direction coefficient is generated, is organized as triangular mesh and is uploaded to GPU video memory;In response to view transformation, only update the uniform variable including transformation matrix, target line width and the size of view port transmitted to GPU, vertex data remains unchanged;In GPU vertex shader, utilize transformation matrix to project transformation of vertex coordinate, utilize its linear component to transform and normalize normal vector, determine screen space offset according to target line width and the size of view port, and add to projection coordinate along normal direction according to direction coefficient;Triangular mesh rasterization rendering is carried out.The application can eliminate the performance bottleneck of CPU frame-by-frame recalculation and vertex data retransmission, realize the high-performance rendering of constant screen line width under mass path.

Description

Technical Field

[0001] This invention relates to the field of computer graphics processing and data visualization technology, and in particular to a constant linewidth rendering method and system for robot map paths, as well as a storage medium. Background Technology

[0002] In the scheduling, monitoring, mapping, and navigation of mobile robots (such as AGVs, AMRs, autonomous vehicles, and robotic vacuum cleaners), the host computer software typically needs to render the 2D map constructed by the robot in real time and overlay path data such as historical trajectories, globally planned paths, and locally planned paths onto the map. With the continuous expansion of robot operating areas and the ongoing improvement in mapping accuracy, the number of path nodes in the map has increased dramatically, often reaching hundreds of thousands in a single display. Simultaneously, users frequently need to perform view operations such as zooming in, zooming out, panning, and rotating the robot map. To ensure that the paths are visually clear and distinguishable, the pixel width of the line segments representing the paths on the screen must remain constant during view scaling; they should not become color blocks when the map is zoomed in, nor become invisible when the map is zoomed out, and different types of paths should be distinguished by different line widths.

[0003] However, early rendering solutions were mostly based on traditional 2D engines such as SVG or Canvas. These solutions involved calculating and drawing the position of the graphic after matrix transformation on the CPU, or inversely converting line width and scaling in each frame. However, since the browser's main thread is single-threaded, when dealing with hundreds of thousands of path points, each frame requires heavy matrix operations on the CPU. This drastically consumes CPU resources, causing the main thread to be blocked for extended periods, leading to unresponsive interfaces and dropped frames. Therefore, it is difficult to meet the real-time interactive requirements of massive path data.

[0004] On the other hand, to leverage the parallel rendering capabilities of GPUs, those skilled in the art have turned to using the native line drawing interface (gl.LINES) provided by WebGL to draw paths. However, due to limitations of the underlying graphics interface conversion layer, most mainstream browsers currently only support a maximum line width of 1 pixel for WebGL native lines, and larger line width settings are directly ignored. Therefore, it cannot meet the business requirements of distinguishing multiple path types with different thicknesses.

[0005] To overcome the limitations of native linewidth capabilities, existing technologies further propose a scheme to reconstruct geometry on the CPU side. This involves pre-converting line segments into polygonal meshes with width on the CPU. When the user zooms the map, the CPU obtains the current zoom level, traverses all vertices, performs matrix operations again to calculate the new polygonal vertex coordinates, and then re-uploads the updated vertex data to the GPU for rendering. While this scheme utilizes the GPU for final rendering, the core linewidth compensation calculation is still performed frame-by-frame on the CPU. During frequent zooming interactions, hundreds of thousands of vertices need to be recalculated and re-uploaded to the GPU each frame, resulting in significant CPU performance bottlenecks and bus bandwidth overhead. Even if the above calculations are moved to a sub-thread, the high-frequency data serialization and deserialization overhead between the main thread and the sub-thread exceeds the computation time itself, making it counterproductive. Furthermore, when the map undergoes complex view transformations such as rotation and mirroring, the path offset direction is prone to distortion, leading to distorted and uneven path edges, further affecting the accuracy and readability of the rendering.

[0006] It is evident that existing rendering solutions are largely limited by the CPU's frame-by-frame computation bottleneck or the native capabilities of the graphics interface. When processing massive amounts of robot map path data, they cannot simultaneously meet the multiple requirements of high-performance and smooth rendering, constant screen linewidth under view scaling, and accurate rendering under complex view transformations. Therefore, how to provide a path rendering solution that can get rid of CPU frame-by-frame recalculation and vertex data retransmission, maintain a constant screen linewidth under view scaling, and is not constrained by native linewidth capabilities has become a pressing technical problem to be solved in this field. Summary of the Invention

[0007] Therefore, the main objective of this invention is to provide a constant linewidth rendering method, system, and storage medium for robot map paths, so as to eliminate the performance bottleneck caused by the CPU recalculating path geometry and retransmitting vertex data frame by frame in scenarios with a large number of path points, so that the linewidth of the path displayed on the screen remains constant during view scaling, and at the same time, it can realize the expression of paths with arbitrary pixel widths without relying on the native linewidth capabilities of the graphics interface, and ensure that the offset direction of the path is correct and the rendering is not distorted under complex view transformations such as rotation and flipping.

[0008] To achieve the above objective, according to a first aspect of the present invention, a constant linewidth rendering method for robot map paths is provided, the steps of which include:

[0009] The ordered path point sequence is preprocessed in one go to generate vertices whose coordinates are located on the path centerline and carry normal vectors and direction coefficients. The vertices are then organized into a triangular mesh and uploaded to the GPU memory in one go.

[0010] In response to view transformation, only the uniform variables transmitted to the GPU are updated. These uniform variables include the transformation matrix, target linewidth, and viewport size, while the vertex data in the video memory remains unchanged.

[0011] In the GPU vertex shader, the vertex coordinates of each vertex are projected and transformed in parallel using the transformation matrix; the normal vectors of each vertex are transformed and normalized using the linear components of the transformation matrix; the screen space offset is determined based on the target linewidth and the viewport size; and the offset is superimposed on the projected vertex coordinates along the normalized normal direction and according to the direction coefficients of each vertex.

[0012] The triangular mesh formed by the superimposed offset vertices is rasterized so that the line width of the path on the screen remains constant during view scaling.

[0013] In a possible preferred embodiment, the method is implemented based on the WebGL graphics interface, the vertex data and index data of the triangle mesh are stored in vertex buffer objects and index buffer objects respectively, and the uniform variable is passed to the vertex shader via the WebGL Uniform interface.

[0014] In a possible preferred embodiment, in the one-time preprocessing, the unit tangent vector of the line segment formed by adjacent path points is calculated, and the unit tangent vector is rotated by 90 degrees to obtain the unit normal vector of the line segment; for the path point at the corner, the angle bisector of the unit normal vectors of the two adjacent line segments is taken as the unit normal vector of the path point, or the corner is obliquely cut.

[0015] In a possible preferred embodiment, in the one-time preprocessing, each path point generates a pair of vertices with the same vertex coordinates and opposite direction coefficients, and each vertex is organized into a triangular mesh using indexed data.

[0016] In a possible preferred embodiment, the linear component is a two-dimensional linear sub-block of the transformation matrix; the normalization normalizes the magnitude of the transformed normal vector to remove the scaling component in the transformation matrix and retains the directional information, including the direction reversal corresponding to negative scaling.

[0017] In a possible preferred embodiment, the screen space is a standardized device coordinate space, and the screen space offset is the ratio of the target linewidth to the viewport size multiplied by the coordinate span of the standardized device coordinate space.

[0018] In a possible preferred embodiment, the target linewidth is in pixels and is the product of the target linewidth in CSS pixels and the device pixel ratio; the viewport size is the actual pixel size of the rendering buffer.

[0019] In a possible preferred embodiment, the method steps further include: in response to a linewidth adjustment instruction, updating only the target linewidth in the uniform variable, without updating the vertex data in the GPU memory, so that the path is rendered with the adjusted display linewidth.

[0020] In a possible preferred embodiment, each vertex also carries a path type code, which is passed from the vertex shader to the fragment shader. The fragment shader then queries a color table based on the path type code to determine the output color.

[0021] In a possible preferred embodiment, the path is at least one of the historical trajectory in the robot map, the global planning path, and the local planning path.

[0022] To achieve the above objectives, corresponding to the above method, according to a second aspect of the present invention, a constant linewidth rendering system for robot map paths is also provided, comprising:

[0023] The preprocessing module is used to preprocess the ordered path point sequence in one go, generate vertices whose vertex coordinates are located on the path center line and carry normal vectors and direction coefficients, organize each vertex into a triangular mesh and upload it to the GPU memory in one go;

[0024] The parameter update module is used to update only the uniform variables transmitted to the GPU in response to view transformation. The uniform variables include the transformation matrix, target linewidth, and viewport size, while the vertex data in the GPU memory remains unchanged.

[0025] The rendering module is used in the GPU vertex shader to perform parallel projection transformations on the vertex coordinates of each vertex using the transformation matrix; to transform and normalize the normal vectors of each vertex using the linear components of the transformation matrix; to determine the screen space offset based on the target linewidth and the viewport size; to superimpose the offset along the normalized normal direction and according to the direction coefficient of each vertex onto the vertex coordinates after projection transformation; and to rasterize the triangular mesh formed by the superimposed offset vertices so that the display linewidth of the path on the screen remains constant when the view is scaled.

[0026] To achieve the above objectives, according to a third aspect of the present invention, a computer-readable storage medium is also provided, on which a computer program is stored, wherein the computer program, when executed by a processor, implements the method described in any of the above examples.

[0027] By using the constant linewidth rendering method, system, and storage medium for robot map paths of this invention, the solution cleverly preprocesses the geometric topology data of the path only once and uploads it to the video memory. During the rendering process, the vertex data remains unchanged. Each frame only needs to update uniform variables with constant data volume, such as matrix, linewidth, and viewport size. The amount of data transmitted per frame from CPU to GPU is independent of the number of path points, thereby eliminating the performance bottleneck and main thread blocking caused by CPU recalculation per frame and vertex data retransmission. This approach can maintain a high frame rate and smooth rendering even in scenarios with a large number of path points.

[0028] Furthermore, since the linewidth offset in this scheme can be determined after projection transformation based on the target linewidth and viewport size, and is independent of the scaling component in the transformation matrix, the displayed linewidth of the path on the screen remains constant regardless of map scaling. Moreover, because the linewidth is achieved through the extrusion and rasterization of triangular meshes, it does not rely on the native linewidth capabilities of the graphics interface, thus allowing for the expression of arbitrary pixel widths and satisfying the need to distinguish various path types with different thicknesses.

[0029] Meanwhile, since the normal vector in this scheme is normalized after being transformed by the linear components of the transformation matrix, the influence of scaling magnitude is removed and the direction information is preserved. Therefore, it can ensure that the offset direction of the path is always correct under complex view transformations such as rotation and flipping, thereby avoiding rendering anomalies such as path distortion and uneven thickness. Attached Figure Description

[0030] The accompanying drawings, which form part of this application, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings:

[0031] Figure 1 This is a flowchart illustrating the constant linewidth rendering method for robot map paths provided in an embodiment of the present invention.

[0032] Figure 2 A schematic diagram illustrating path data preprocessing and geometry construction provided in an embodiment of the present invention;

[0033] Figure 3 This is a schematic diagram of constant linewidth compensation calculation in a vertex shader provided in an embodiment of the present invention;

[0034] Figure 4 This is a schematic diagram comparing the display effect of path line width before and after map zooming in an embodiment of the present invention;

[0035] Figure 5 This is a schematic diagram of normal correction in a rotated, flipped, and negatively scaled scene provided by an embodiment of the present invention;

[0036] Figure 6This is a schematic diagram of the structure of a robot map path constant linewidth rendering system provided in an embodiment of the present invention. Detailed Implementation

[0037] To enable those skilled in the art to better understand the technical solutions of the present invention, the specific technical solutions of the present invention will be clearly and completely described below in conjunction with embodiments, so as to help those skilled in the art further understand the present invention. Obviously, the embodiments described in this application are merely some embodiments of the present invention, and not all embodiments. It should be noted that, for those skilled in the art, the embodiments and features in the embodiments of this application can be combined with each other without departing from the concept of the present invention and without conflict. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the disclosure and protection scope of the present invention.

[0038] Furthermore, the terms "first," "second," "S100," "S200," etc., used in the specification, claims, and drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such features can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those described herein. At the same time, the stages described in each step are not necessarily to be implemented in the same step; it should be understood that the implementation order of the contents of each step stage can be adjusted and interchanged without violating the inventive concept, so that embodiments of the invention described herein can be implemented in orders other than those described herein. Additionally, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. Unless otherwise expressly specified and limited, the terms "set," "arrange," "install," "connect," and "link" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; a mechanical connection or an electrical connection; a direct connection or an indirect connection through an intermediate medium; or a connection within two elements. Those skilled in the art can understand the specific meaning of the above terms in this case based on the specific circumstances and in conjunction with existing technology.

[0039] To address the limitations of existing technologies, which are constrained by CPU-based frame-by-frame computation or the native capabilities of graphics interfaces, and thus cannot simultaneously meet the multiple requirements of high-performance, smooth rendering, constant screen linewidth under view scaling, and accurate rendering under complex view transformations when processing massive robot map path data, this invention proposes a constant linewidth rendering scheme for robot map paths. Its core concept lies in "decoupling static and dynamic elements" and "decoupling space and size" in the path rendering process.

[0040] On the one hand, the geometric topological information (connection relationships of path points, orientation of normals, and vertex unfolding methods) that is unrelated to view transformation in path rendering is separated from the quantities (transformation matrix, target line width, and viewport size) that change dynamically with view transformation. The former is calculated once by the CPU during the initialization phase and fixed in the GPU memory, remaining static throughout the entire rendering lifecycle. The latter is updated as needed in the form of a uniform variable during the rendering process, thereby reducing the amount of computation and data transmission per CPU frame from the order of magnitude related to the number of path points to a constant order of magnitude.

[0041] On the other hand, inside the GPU vertex shader, the coordinate transformation that determines the path position and direction is separated from the normal offset that determines the path width. The vertex coordinates undergo projection transformation of the complete transformation matrix, the normal vector is transformed only by the linear components of the transformation matrix and normalized, and the line width is synthesized after projection using the screen space offset converted from the target line width and the viewport size, so that the screen display line width of the path and the map scaling ratio are completely decoupled mathematically.

[0042] like Figure 1 As shown, this invention proposes a constant linewidth rendering method for robot map paths. This method comprises two parts: an initialization phase and a per-frame interaction phase. The initialization phase is executed only once (reconstructed when the path data itself changes), including steps S100 to S300. The per-frame interaction phase includes steps S400 to S600. During rendering, there is no retransmission of vertex data; vertex-by-vertex calculations are performed in parallel by the GPU. The specific details of each step are as follows.

[0043] Step S100: Obtain an ordered sequence of path points.

[0044] Obtain the ordered path point sequence P=[p0,p1,…,p] corresponding to the path to be rendered. n The path can be a historical trajectory in the robot map, a global planning path, or a local planning path, etc.

[0045] In step S200, the CPU performs a one-time preprocessing of the path point sequence to construct the geometry.

[0046] Combination Figure 2 As shown, the CPU sequentially traverses the line segments (p) formed by adjacent path points. i p i+1 ), and perform the following processing:

[0047] Step S210, Normal Vector Calculation: Calculate the unit tangent vector T = normalize(p) of the line segment. i+1- p iThe unit tangent vector is rotated 90 degrees to obtain the unit normal vector N=(-Ty,Tx) of the line segment; for path points at corners, the unit normal vectors of adjacent line segments are bisected (Miter method) or the corner is beveled to ensure the width of the path at the turning point.

[0048] Step S220, Vertex Symmetrical Unfolding: Expand each path point into a pair of vertices, where the vertex coordinates of the pair are identical, both being the original coordinates p on the path centerline. i It is distinguished only by the direction coefficient attribute a_side (e.g., +0.5 represents the left side and -0.5 represents the right side), and adjacent vertices are organized into a triangular mesh using index data, where each line segment consists of two triangles.

[0049] Step S230, Vertex attribute recording: For each vertex, record the vertex coordinates a_position, unit normal a_normal, direction coefficient a_side, and path type code a_pathType, etc. Among them, a_position and a_normal constitute the vertex attribute cache, and a_side and a_pathType constitute the auxiliary attribute cache.

[0050] It's important to note that in this step, linewidth is not baked into vertex coordinates; all vertex coordinates remain on the path's centerline. The geometric extrusion of the linewidth is delayed until it's dynamically composited frame-by-frame on the GPU. The principle behind this is that the path's geometric topology depends only on the path data itself, independent of view scaling, translation, and rotation, thus requiring only one calculation. Amounts that change with the view are completely removed from the vertex data, making it statically unchanging throughout its lifecycle. This lays the data structure foundation for zero recalculation and zero retransmission in subsequent rendering processes. Furthermore, using a triangular mesh to carry the linewidth eliminates reliance on the native linewidth capabilities of the graphics interface.

[0051] Step S300: Upload the vertex data and index data to the GPU memory at once.

[0052] Specifically, the vertex attribute data and index data generated in step S200 are written to the vertex buffer object (VBO) and index buffer object (IBO) respectively, and uploaded to the GPU memory in one go by calling the buffer data interface. Afterward, the buffer data is not updated in any subsequent rendering frames. All parameters that change with interaction during the rendering process are passed to the shader as unified variables, including the transformation matrix u_matrix (model-view-projection matrix), the target linewidth u_lineWidthPx, and the viewport size u_viewportSize.

[0053] In this embodiment, the target linewidth is measured in pixels, and its value is the product of the target linewidth in CSS pixels and the device pixel ratio, i.e., u_lineWidthPx = cssLineWidth × window.devicePixelRatio; the viewport size uses the actual pixel size of the rendering buffer, i.e., viewportWidth = gl.drawingBufferWidth, viewportHeight = gl.drawingBufferHeight. This ensures that the visual linewidth of the path is consistent on both ordinary screens and high pixel density screens.

[0054] Furthermore, the above embodiments use the WebGL interface as an example, but in other implementations, it can also be implemented based on graphics interfaces such as WebGPU.

[0055] Step S400: In response to the view transformation, update the uniform variable.

[0056] Specifically, when a user performs view operations such as zooming, panning, or rotating, the CPU only recalculates and updates unified variables such as the transformation matrix, and then initiates a drawing call. At this time, the amount of data updated by the CPU per frame is only a 4×4 (or 3×3) matrix and several scalars, that is, more than ten floating-point numbers. The amount of data is constant and completely independent of the number of path points. The complexity of frame-by-frame data transfer from the CPU to the GPU is reduced from the order of magnitude related to the number of path points to a constant order of magnitude. The main thread no longer executes any vertex-by-vertex loop, and there is no need to introduce sub-threads and their communication overhead.

[0057] In step S500, the GPU vertex shader performs a decoupling transformation on each vertex in parallel.

[0058] Specifically, in combination Figure 3 As shown, when the view undergoes any transformation, the vertex shader receives vertex input (a_position, a_normal, a_side, etc.) and performs the following processing in parallel for each vertex:

[0059] Step S501, Position Transformation: The vertex coordinates are projected using a transformation matrix to obtain the projected coordinates pos_clip=u_matrix×vec4(a_position,0.0,1.0). At this point, the vertex is still located on the path centerline and can normally accept all scaling, translation, and rotation, ensuring that the overall position and direction of the path are strictly aligned with the map.

[0060] Step S502, Normal processing: Take the linear component of the transformation matrix (i.e., the two-dimensional linear sub-block) to transform the normal vector, and normalize the transformation result to obtain the screen normal n_rot=normalize(mat2(u_matrix)×a_normal). The principle is that the two-dimensional linear sub-block combines rotation and scaling components. Proportional scaling only changes the length and magnitude of the vector without changing its direction. Normalization forces the vector length to be normalized, which is equivalent to removing the interference of scaling magnitude, while completely preserving the direction information, including the direction reversal corresponding to negative scaling (mirror flip).

[0061] Combination Figure 5 As shown, taking a transformation matrix containing negative scaling as an example, when the matrix contains a scaling factor of -2 (such as Sx=-2, Sy=2), if no normalization is performed, the offset magnitude will be affected by the scaling, resulting in path distortion. After normalization, the magnitude scalar is eliminated, and the 180° topological flip direction corresponding to the negative sign is retained, so that the normal still points to the correct side in the mirrored scene.

[0062] Furthermore, the above-mentioned normalization process is a preferred implementation for extracting rotational components. In other embodiments, rotational components can also be obtained by means of two-dimensional orthogonal basis reconstruction, polar decomposition approximation, or quaternion / angle parameterization, as long as the scaling effect is removed and the normal direction is kept consistent.

[0063] Therefore, regardless of the rotation, mirroring, or proportional scaling of the map, the extrusion direction is always perpendicular to the tangent of the path on the screen, fundamentally eliminating the sudden changes in normal length and direction distortion caused by matrix scaling, and preventing rendering anomalies such as path edge distortion, uneven thickness, or polygonal broken surfaces.

[0064] Step S503, Offset Composition: Determine the screen space offset based on the target linewidth and viewport size. Then, superimpose the offset along the normalized normal direction and according to the direction coefficients of each vertex onto the vertex coordinates after projection transformation. In this embodiment, the screen space is the Normalized Device Coordinate (NDC) space. The target linewidth is converted from pixel units to the NDC offset offset_ndc = (u_lineWidthPx / u_viewportSize) × 2.0, where the NDC coordinate range is [-1,1] and the total span is 2, so the pixel percentage needs to be multiplied by 2. The offset is then superimposed onto the projection coordinates, i.e., gl_Position.xy = pos_clip.xy + n_rot × offset_ndc × a_side. The direction coefficient a_side causes the two vertices corresponding to the same center point to symmetrically squeeze out half a linewidth to both sides of the path centerline.

[0065] This offset is directly calculated from the ratio of the target linewidth to the viewport size. The overlay occurs after the projection transformation and does not involve any scaling components of the transformation matrix. Therefore, its corresponding pixel width on the screen is completely independent of the map scaling ratio. That is, whether the map is zoomed in to centimeter-level detail or zoomed out to kilometer-level global coverage, the screen linewidth of the path always maintains the preset target pixel value. Furthermore, since the linewidth is implemented by the shader using triangle extrusion, rather than relying on the native linewidth properties of the graphics interface, the linewidth can take any pixel value, thus overcoming the limitation of the maximum 1-pixel linewidth of native line segments in mainstream browsers.

[0066] It should be noted that this embodiment uses NDC spatial composition offset as an example for illustration. In other embodiments, equivalent pixel compensation can also be completed in view space before being projected to clip space. As long as the principles of scaling decoupling and fixed pixel target are met, they are all equivalent variations of the present invention.

[0067] In this embodiment, the core code example of the vertex shader is as follows:

[0068] attribute vec2 a_position; / / Centerline vertex coordinates (static, uploaded once during initialization)

[0069] attribute vec2 a_normal; / / Unit normal (static)

[0070] attribute float a_side; / / Direction coefficient ±0.5 (static)

[0071] uniform mat4 u_matrix; / / MVP matrix (only this item is updated per frame)

[0072] uniform float u_lineWidthPx; / / Target line width (pixels)

[0073] uniform vec2 u_viewportSize; / / Viewport size (pixels)

[0074] void main() {

[0075] / / Centerline standard projection: Accepts all scaling / translation / rotation

[0076] vec4 pos_clip = u_matrix * vec4(a_position, 0.0, 1.0);

[0077] / / Extract rotation components and normalize: strip scaling magnitude, retain signed direction.

[0078] vec2 n_rot = normalize(mat2(u_matrix) * a_normal);

[0079] / / Pixel to NDC conversion, constant width extrusion decoupled from scaling

[0080] vec2 offset_ndc = n_rot * (u_lineWidthPx / u_viewportSize) * 2.0;

[0081] gl_Position = vec4(pos_clip.xy + offset_ndc * a_side, pos_clip.zw);

[0082] }

[0083] It should be noted that the calculations between vertices in step S500 are independent and have no data dependency, which is naturally adapted to the parallel architecture of the GPU and can be executed concurrently by a large number of stream processors. For a scale of 200,000 path points (about 400,000 vertices), the processing time of a single frame vertex is in the sub-millisecond level. Combined with the constant-level data update in step S400, the whole machine can stably maintain full-frame rendering.

[0084] Furthermore, since the vertex-by-vertex calculations are independent and have no data dependency, those skilled in the art will understand that, under supported operating environments, the aforementioned offset calculations can also be completed by the computation shader or other GPU parallel computing modules before entering the rasterization process, which still conforms to the core concept of this invention.

[0085] Step S600: Rasterize the rendering and output a path with a constant screen linewidth.

[0086] Specifically, this involves rasterizing the triangular mesh formed by the superimposed offset vertices. In this embodiment, the vertex shader passes the path type code a_pathType to the fragment shader. The fragment shader queries the color table provided in the form of a unified variable based on the path type code, and outputs the corresponding color for historical trajectories, global planning paths, local planning paths, or different robot states. When the business state changes (such as robot abnormal alarms), only the unified variable in the color table needs to be updated to change the coloring, without touching the vertex buffer.

[0087] The following combination Figure 4The diagram further illustrates the runtime interaction process. When the user zooms in or out of the map using the scroll wheel, the data update path of this solution differs fundamentally from existing CPU reconstruction solutions. Existing solutions require a complete chain of "zoom change → traversing path points → reconstructing geometry → uploading buffer → drawing," necessitating CPU recalculation and GPU memory retransmission in each frame. In contrast, this solution only requires "zoom change → updating unified variables → drawing," meaning the vertex buffer data remains unchanged, and all linewidth compensation is completed in parallel by the GPU within the same frame. Consequently, in terms of display effects, the path linewidth in existing solutions changes with the map scale; when zoomed in, the path becomes a colored block, and when zoomed out, it becomes invisible. In contrast, the screen pixel linewidth of the path remains constant in both zoomed-out and zoomed-out views in this solution.

[0088] When the business requires adjusting the path linewidth (e.g., highlighting a selected path), only the unified variable corresponding to the target linewidth needs to be updated to take effect in real time in the next rendering frame. There's no need to recalculate path vertices or update vertex and index buffers. For example, if a path is displayed with a default linewidth of 3 pixels, selecting it only updates the target linewidth to 5, and the path will be displayed with a 5-pixel linewidth in the next frame. The path's centerline position, geometry, color, and map space position remain unchanged. Deselecting it restores the target linewidth to restore the original display linewidth.

[0089] In the same test environment, the performance of this solution was compared with that of existing CPU reconstruction solutions. The test data included 200,000 path points, and map zooming operations were performed continuously. The existing solution recalculates path vertices and uploads buffered data every frame, with an average CPU time of approximately 50ms and an average rendering frame rate of approximately 26 FPS. In contrast, in this solution, the CPU only updates the matrix and unified variables every frame, while the vertex buffer data remains unchanged. Therefore, the average CPU time per frame is approximately 0.3ms, and the average rendering frame rate is 60 FPS. This demonstrates that this solution can significantly reduce CPU processing time per frame and maintain a stable high frame rate rendering even in scenarios with a large number of path points.

[0090] On the other hand, corresponding to the above method examples, such as Figure 6 As shown, this embodiment also provides a robot map path constant line width rendering system, which includes a preprocessing module, a parameter update module and a rendering module. The functions of each module correspond one-to-one with the steps in the above method embodiment.

[0091] The preprocessing module performs a one-time preprocessing on the ordered path point sequence, generating vertices whose coordinates lie on the path centerline and carry normal vectors and direction coefficients. It then organizes these vertices into a triangular mesh and uploads it to the GPU memory all at once. The parameter update module updates only the unified variables transmitted to the GPU in response to view transformations. These unified variables include the transformation matrix, target linewidth, and viewport size, while the vertex data in the GPU memory remains unchanged. The rendering module performs projection transformation, normal transformation normalization, and screen space offset synthesis in the GPU vertex shader, and rasterizes the triangular mesh to ensure that the path's displayed linewidth on the screen remains constant during view scaling.

[0092] The specific implementation methods and technical effects of each module in this embodiment are the same as those in the above-described method embodiments, and can be referred to each other. They will not be repeated here.

[0093] In summary, the constant linewidth rendering method, system, and storage medium for robot map paths provided in this embodiment of the invention preprocesses and solidifies the view-independent geometric topology information in the path rendering during the initialization phase, keeping the vertex data static throughout the entire rendering lifecycle. During the rendering phase, all dynamic transformations per vertex are pushed down to the GPU vertex shader for parallel execution, and spatial and dimensional decoupling is achieved within the shader. Vertex coordinates are projected through a complete transformation matrix to ensure strict alignment between the path and the map. Normal vectors are transformed and normalized through the linear components of the transformation matrix to remove scaling magnitude and retain direction information. The linewidth is synthesized along the normal direction in the form of screen space offset after projection, based on the target linewidth and viewport size.

[0094] Therefore, when the view changes, the CPU only needs to update a unified variable with a constant amount of data. There is no need to recalculate the geometry or retransmit vertex data. Thus, in scenarios with massive robot map path data, it can simultaneously achieve high-performance and smooth rendering, constant screen line width under view scaling, arbitrary pixel line width expression, and rendering correctness under complex view changes such as rotation and flipping. The freed-up CPU computing power is returned to core business logic such as robot monitoring and scheduling, which has significant engineering application value.

[0095] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The present invention is limited only by the claims and their full scope and equivalents. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the invention should be included within the protection scope of the invention.

[0096] Those skilled in the art will understand that, besides implementing the system, apparatus, unit, and its modules provided by this invention in purely computer-readable program code, the same program can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, the system, apparatus, and its modules provided by this invention can be considered a hardware component, and the modules included therein for implementing various programs can also be considered structures within the hardware component; alternatively, modules for implementing various functions can be considered both software programs implementing the method and structures within the hardware component.

[0097] Furthermore, all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a microcontroller, chip, or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0098] Furthermore, various different implementations of the present invention can be combined arbitrarily, as long as they do not violate the spirit of the present invention, they should also be regarded as the content disclosed in the present invention.

Claims

1. A constant linewidth rendering method for robot map paths, characterized in that, include: The ordered path point sequence is preprocessed in one go to generate vertices whose coordinates are located on the path centerline and carry normal vectors and direction coefficients. The vertices are then organized into a triangular mesh and uploaded to the GPU memory in one go. In response to view transformation, only the uniform variables transmitted to the GPU are updated. These uniform variables include the transformation matrix, target linewidth, and viewport size, while the vertex data in the video memory remains unchanged. In the GPU vertex shader, the vertex coordinates of each vertex are projected and transformed in parallel using the transformation matrix; the normal vectors of each vertex are transformed and normalized using the linear components of the transformation matrix. The screen space offset is determined based on the target line width and the viewport size. The offset is then superimposed along the normalized normal direction and according to the direction coefficient of each vertex to the vertex coordinates after projection transformation. The triangular mesh formed by the superimposed offset vertices is rasterized so that the line width of the path on the screen remains constant when the view is zoomed.

2. The method according to claim 1, characterized in that, The method is implemented based on the WebGL graphics interface. The vertex data and index data of the triangle mesh are stored in vertex buffer objects and index buffer objects, respectively. The uniform variable is passed to the vertex shader through the WebGL Uniform interface.

3. The method according to claim 1, characterized in that, In the one-time preprocessing, the unit tangent vector of the line segment formed by adjacent path points is calculated, and the unit tangent vector is rotated by 90 degrees to obtain the unit normal vector of the line segment; for the path point at the corner, the angle bisector of the unit normal vectors of the two adjacent line segments is taken as the unit normal vector of the path point, or the corner is obliquely cut.

4. The method according to claim 1, characterized in that, In the one-time preprocessing, each path point generates a pair of vertices with the same vertex coordinates and opposite direction coefficients, and each vertex is organized into a triangular mesh using indexed data.

5. The method according to claim 1, characterized in that, The linear component is a two-dimensional linear sub-block of the transformation matrix; the normalization normalizes the magnitude of the transformed normal vector to remove the scaling component in the transformation matrix and retains the direction information, including the direction reversal corresponding to negative scaling.

6. The method according to claim 1, characterized in that, The screen space is a standardized device coordinate space, and the screen space offset is the ratio of the target linewidth to the viewport size multiplied by the coordinate span of the standardized device coordinate space.

7. The method according to claim 1, characterized in that, The target linewidth is in pixels and its value is the product of the target linewidth in CSS pixels and the device pixel ratio; the viewport size is the actual pixel size of the rendering buffer.

8. The method according to claim 1, characterized in that, The steps also include: in response to the linewidth adjustment instruction, only updating the target linewidth in the uniform variable, without updating the vertex data in the GPU memory, so that the path is rendered with the adjusted display linewidth.

9. The method according to claim 1, characterized in that, Each vertex also carries a path type code, which is passed from the vertex shader to the fragment shader. The fragment shader then queries the color table based on the path type code to determine the output color.

10. The method according to any one of claims 1 to 9, characterized in that, The path is at least one of the following: historical trajectory in the robot map, global planning path, and local planning path.

11. A constant linewidth rendering system for robot map paths, characterized in that, include: The preprocessing module is used to preprocess the ordered path point sequence in one go, generate vertices whose vertex coordinates are located on the path center line and carry normal vectors and direction coefficients, organize each vertex into a triangular mesh and upload it to the GPU memory in one go; The parameter update module is used to update only the uniform variables transmitted to the GPU in response to view transformation. The uniform variables include the transformation matrix, target line width, and viewport size, while the vertex data in the GPU memory remains unchanged. The rendering module is used to perform parallel projection transformations on the vertex coordinates of each vertex in the GPU vertex shader using the transformation matrix. The normal vectors of each vertex are transformed and normalized using the linear components of the transformation matrix. The screen space offset is determined based on the target linewidth and the viewport size. The offset is then superimposed onto the vertex coordinates after projection transformation along the normalized normal direction and according to the direction coefficient of each vertex. The triangular mesh formed by the superimposed offset vertices is rasterized so that the display linewidth of the path on the screen remains constant when the view is zoomed.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 10.

Images