A method, apparatus, medium and device for texture rendering in engine migration

Abstract

The present application belongs to the technical field of texture rendering, and in particular relates to a texture rendering method, device, medium and equipment in engine migration. The method solves the performance and consistency problems existing in rendering texture drawing and other projects in the game engine migration process. The method comprises the following steps: creating a special rendering camera, the special rendering camera is used for mounting and submitting an execution rendering texture drawing command, and the special rendering camera has a to-be-executed command buffer set in a front event; receiving a to-be-drawn display object, synchronizing source engine attribute parameters of the to-be-drawn display object to a current engine object through a drawing front synchronization interface, the source engine attribute parameters including a matrix, a level, a visibility, a texture and a material state; forming a rendering command buffer set based on a synchronization result of the source engine attribute parameters and according to source engine rendering logic; adding the rendering command buffer set to the to-be-executed command buffer set, and submitting the command buffer in the to-be-executed command buffer set to a rendering thread for execution by the special rendering camera.

Description

Technical Field

[0001] This invention belongs to the field of texture rendering technology, and specifically relates to a texture rendering method, apparatus, medium and device in engine migration. Background Technology

[0002] In Flash / Starling-style game projects, rendered textures are typically used as dynamic textures. For example... Figure 1 As shown, in this type of project, it supports drawing the display tree to a dynamic texture based on its state. Developers can draw any display object onto this texture, preserving the object's current position, rotation, scaling, opacity, or specified matrix transformations during the drawing process. When drawing a large number of objects at once, multiple drawings can be aggregated into a single drawing block through a batch drawing interface to reduce intermediate state switching. This mechanism is commonly used for combat effects, character compositing, interface screenshots, trailing effects, cached drawing, blurred foregrounds, skeletal animation transfer mapping, masking, or scenarios where a complex display tree needs to be solidified into a texture.

[0003] When migrating the above projects to the Unity engine, one common practice is as follows: Figure 2 As shown, this involves creating or reusing a camera for each draw, setting the target rendering texture as the camera's output target, and then calling the camera to render immediately or waiting for the camera to render normally. This method is intuitive, but it triggers culling, state collection, canvas pre-rendering events, interface reconstruction, or other processing flows similar to the main camera in Unity's camera rendering lifecycle. For scenarios where only a single display object tree needs to be drawn to the rendering texture, this process incurs significant unnecessary overhead, especially in combat interfaces, skeletal animations, special effects, and scenarios with frequent texture rendering, leading to increased frame rates.

[0004] The second existing approach involves rewriting each original display object as a Unity sprite, UI image, canvas, or regular mesh renderer during migration, relying on Unity's own rendering order and dynamic batching capabilities. This method is feasible for simple static images, but it struggles to reliably replicate the parent-child hierarchy of display object containers, drawing matrices, persistent texture rendering, non-persistent screen clearing, batch drawing, and the processing logic of pre-rendered texture data in the original custom shaders, which can easily lead to hierarchical errors, material incompatibility, texture sampling errors, or differences in transparency blending.

[0005] The third existing approach, such as Figure 3As shown, this method directly writes content to the rendering texture using texture copying, command buffer per-renderer drawing, or per-mesh drawing via the graphics interface. This method can bypass some camera rendering costs, but if it lacks recursive collection, sorting, material replacement, mesh data reuse, batching of consecutive materials, and aggregation of drawing blocks, it will still generate a lot of drawing calls and runtime object allocation. Furthermore, it is prone to lacking compatibility logic when dealing with multiple materials, special shaders, skeletal graphics, or blurred interface materials.

[0006] The fourth existing approach is to migrate the project to a programmable rendering pipeline and write custom rendering features. While this approach offers strong scalability, for existing projects that already use Unity's built-in rendering pipeline and whose project assets and shaders are built around the standard pipeline, switching the entire rendering pipeline would incur costs for material remaking, shader rewriting, platform verification, and engineering modifications. It is not suitable for large-scale modifications solely for migrating rendering texture drawing semantics.

[0007] Furthermore, creating temporary command buffers, meshes, materials, or auxiliary cameras for each draw, or failing to clean up references promptly after drawing, can easily lead to garbage collection jitter and memory increases. Creating material instances for each object to ensure compatibility with rendering textures will also break batching conditions and increase the burden of object management. Directly calling the camera for rendering but then clipping the canvas via reflection can reduce some UI overhead, but it still cannot systematically solve the problems of drawing command submission, rendering thread execution, material variant reuse, batching of consecutive objects, and parallel processing between the logic and rendering sides.

[0008] In summary, existing technologies have performance and consistency issues that need to be addressed in rendering textures and other projects during game engine migration. Summary of the Invention

[0009] Based on the above analysis, the embodiments of the present invention aim to provide a texture rendering method, apparatus, medium and device in engine migration, so as to solve the performance and consistency problems in rendering textures and other projects during the game engine migration process.

[0010] This invention provides a texture rendering method during engine migration, comprising the following steps: A dedicated rendering camera is created, which is used to mount and submit rendering texture drawing commands. The pre-event of the dedicated rendering camera is configured with a set of command buffers to be executed, and the post-event of the dedicated rendering camera is configured to remove all command buffers and temporary references mounted to the dedicated rendering camera. Receive the object to be drawn and synchronize the source engine attribute parameters of the object to be drawn to the current engine object through the pre-draw synchronization interface. The source engine attribute parameters include matrix, hierarchy, visibility, texture and material state. Based on the synchronization results of the source engine attribute parameters and according to the source engine rendering logic, a set of rendering command buffers is formed. The rendering command buffer set is added to the command buffer set to be executed, and the dedicated rendering camera submits the command buffers in the command buffer set to be executed to the rendering thread for execution.

[0011] In some embodiments, the rendering command buffer set includes one or more combinations of camera matrix simulation commands, rendering texture target setting commands, screen clearing control commands, batching commands for continuous meshes of the same material, mesh drawing commands, and renderer drawing commands.

[0012] In some embodiments, the process of receiving the object to be drawn for display further includes: Create a rendering texture encapsulation object, which stores one or more combinations of rendering texture width, height, scaling, format, whether it is persistent, root texture, and currently active texture information; Create a command buffer object pool, which is used to store and provide the command buffer required by the texture rendering method.

[0013] In some embodiments, the synchronization result based on the source engine attribute parameters forms a rendering command buffer set according to the source engine rendering logic, including: The renderer collects and sorts the drawable sub-objects in the object to be drawn and displays in hierarchical order to form a renderer sorting queue. The renderers in the renderer sorting queue are sequentially evaluated for and marked as unacceptable. The sorted queue of marked renderers is dynamically batched. If the current renderer can be batched and its material is the same as that of the current batch, the current renderer is added to the current batch. If the current renderer cannot be batched or its material is different from that of the current batch, a new batch is created. Whenever a new batch is created or a batch traversal ends, the current batch is committed. If the batch contains multiple sub-objects, a mesh merge description array is generated, and the multiple meshes are merged into a temporary mesh according to their respective matrices, forming a mesh drawing command added to the rendering command buffer set. If the batch contains a single sub-object, a mesh drawing command or a renderer drawing command is formed and added to the rendering command buffer set.

[0014] In some embodiments, the renderer collects and sorts the drawable sub-objects in the display object to be drawn in hierarchical order to form a renderer sorting queue, including: Traverse the transformation tree of the display objects to be drawn to collect drawable renderers, wherein the transformation tree of the display objects to be drawn is obtained based on the synchronization of the hierarchical attributes of the display objects to be drawn in the source engine; Record the level depth and intra-level sort value of each drawable renderer in the transformation tree of the display object to be drawn; The drawing order of each of the drawable renderers is sorted based on the layer depth, the intra-layer sorting value, and the display tree depth to form a renderer collection sorting command.

[0015] In some embodiments, prior to the renderer collecting and sorting, the following is also included: The target rendering texture to be written is set through the command buffer, and the original content is cleared based on whether the rendering texture is persistent. This forms the rendering texture target setting command and the screen clearing control command, which are then added to the rendering command buffer set. The size of the simulated camera and the camera center point are calculated based on the width and height of the target rendered texture and the original stage coordinate system. Based on the world-to-local transformation matrix, orthogonal dimensions, aspect ratio, near clipping plane, and far clipping plane of the simulated camera, a view matrix and a projection matrix are generated to form a camera matrix simulation command and added to the rendering command buffer set.

[0016] In some embodiments, the method further includes mapping and reusing materials specifically designed for rendering textures. Maintain a dedicated shader mapping table, which has a mapping relationship between the source engine shader name and the resource path of the dedicated shader of the current engine; When the original material and original texture of the object to be drawn meet the mapping conditions, the material instance corresponding to the target shader is obtained from the material object pool according to the dedicated shader mapping table, and the main texture is set after copying the properties of the original material. If consecutive objects to be drawn use the same original material and the same original texture, then the same material instance is reused.

[0017] The present invention also provides a texture rendering apparatus for engine migration, comprising: Initialize the rendering control module and create a dedicated rendering camera. The dedicated rendering camera is used to mount and submit rendering texture drawing commands. The pre-event of the dedicated rendering camera has a set of command buffers to be executed. The post-event of the dedicated rendering camera removes all mounted command buffers and temporary references. The drawing interface module receives the display object to be drawn and synchronizes the source engine attribute parameters of the display object to be drawn to the current engine object through the pre-drawing synchronization interface. The source engine attribute parameters include matrix, hierarchy, visibility, texture and material state. The rendering logic organization module forms a set of rendering command buffers based on the synchronization results of the source engine attribute parameters and the source engine rendering logic. The rendering thread submission module adds the rendering command buffer set to the command buffer set to be executed, and the dedicated rendering camera submits the command buffers in the command buffer set to be executed to the rendering thread for execution.

[0018] The present invention also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the computer program, when executed by the processor, implements the texture rendering method in engine migration as described in any of the above embodiments.

[0019] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the texture rendering method in engine migration as described in any of the above embodiments.

[0020] The above embodiments of the present invention have at least the following beneficial effects: 1. By executing rendering texture drawing commands through a command buffer and a dedicated rendering camera, the full camera immediate rendering process is avoided every time the target object is drawn, reducing culling, interface pre-rendering events and camera lifecycle costs that are unrelated to target drawing.

[0021] 2. This invention improves the consistency of rendering projects during engine migration by synchronizing the object state before drawing and forming a command buffer based on the source engine logic.

[0022] 3. This invention decouples the organization of drawing requests from the actual graphics execution by constructing a command buffer on the logic side and executing the command buffer on the rendering thread. This allows the main logic processing and rendering execution to proceed in parallel within the thread model allowed by the engine, reducing the time the main thread waits for rendering. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this specification 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 recorded in the embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings.

[0024] Figure 1 A schematic diagram of the texture rendering process in existing Flash / Starling-type engines; Figure 2 A schematic diagram illustrating the process of rendering textures using a Unity camera in the existing migration scheme; Figure 3 A diagram illustrating the performance issues of the existing per-render rendering scheme; Figure 4 A schematic diagram of the texture rendering method in engine migration provided by the present invention; Figure 5 This is a schematic diagram illustrating the collaboration between the dedicated rendering camera and the command buffer in this invention; Figure 6 This is a schematic diagram of multi-threaded collaboration between the logic side and the rendering side in this invention; Figure 7 This is a schematic diagram illustrating the collection, sorting, and batch drawing of the display object tree to be drawn in this invention; Figure 8 This is a schematic diagram of the material mapping for rendering textures in this invention; Figure 9 A schematic diagram of the texture rendering device architecture in engine migration provided by the present invention; Figure 10 This is a schematic diagram of the electronic device architecture provided by the present invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. It should be noted that, unless otherwise specified, the implementation methods and features in the implementation methods in this disclosure can be combined, separated, interchanged, and / or rearranged. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] The terminology used herein is for the purpose of describing particular embodiments and is not intended to be limiting. As used herein, unless the context clearly indicates otherwise, the singular forms “a” and “the” are intended to include the plural forms as well. Furthermore, when the terms “comprising” and / or “including” and variations thereof are used in this specification, it indicates the presence of the stated features, integrals, steps, operations, parts, components, and / or groups thereof, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, parts, components, and / or groups thereof. It should also be noted that, as used herein, the terms “substantially,” “about,” and other similar terms are used as approximate terms rather than as terms of degree, thus explaining the inherent biases in measurements, calculated values, and / or provided values ​​that would be recognized by one of ordinary skill in the art.

[0027] This invention relates to game engine migration, real-time graphics rendering, off-screen rendering, rendering textures, command buffering, display object tree conversion, material compatibility, dynamic batching, multi-threaded collaborative rendering, and runtime resource reuse. The embodiments of this invention are primarily described within the context of migrating Flash / Starling-type display engine projects to the Unity engine's built-in rendering pipeline. Therefore, Flash / Starling-type engines are equivalent to the source engine in the following text, while the Unity engine is the current engine. The main objective of this invention is to provide a custom texture rendering method that maintains the original rendering texture drawing semantics while improving runtime performance. It addresses the performance and consistency issues arising from directly migrating behaviors such as display object drawing to rendering textures, batch drawing, persistent drawing, screen clearing, matrix transformation, rendering sorting, special shader preprocessing, and rendering thread submission from the source engine to the Unity standard rendering pipeline.

[0028] The Flash / Starling-like display engine projects mentioned in this invention include, but are not limited to, 2D or pseudo-3D game projects based on display objects, display object containers, image objects, texture objects, and rendering texture drawing interfaces. The Unity engine's built-in rendering pipeline includes, but is not limited to, a standard rendering environment that uses capabilities such as cameras, renderers, meshes, materials, rendering textures, command buffers, and camera events to complete image rendering.

[0029] The present disclosure will now be described through several specific embodiments. To keep the following description of the embodiments of the invention clear and concise, detailed descriptions of known functions and components are omitted.

[0030] This invention provides a texture rendering method in engine migration, such as... Figure 4 As shown, it includes the following steps: S1. Create a dedicated rendering camera, which is used to mount and submit rendering texture drawing commands. The pre-event of the dedicated rendering camera is configured with a set of command buffers to be executed, and the post-event of the dedicated rendering camera is configured to remove all command buffers and temporary references mounted to the dedicated rendering camera.

[0031] This invention creates a "dedicated rendering camera" in the Unity engine. This camera does not participate in normal scene rendering, but instead acts as an execution container, mounting a set of command buffers constructed according to the rendering logic of Flash / Starling-type engines.

[0032] In some embodiments, such as Figure 5 As shown, the dedicated rendering camera can be set to render at an earlier depth, without screen clearing overhead, and by default does not render any layers. It inserts a set of command buffers to be executed in the pre-rendering event of the camera and removes all command buffers and cleans up temporary references in the post-rendering event of the camera.

[0033] In this way, rendering texture drawing commands can be executed by the rendering thread in the standard rendering pipeline, without needing to call the full camera immediate rendering process for each target object.

[0034] In some embodiments, camera events of a dedicated rendering camera can be adjusted according to the rendering sequence of the target project, such as selecting before forward opaque rendering, before image effects, after all rendering, or other adapted events without affecting the rendering results.

[0035] S2. Receive the object to be drawn and synchronize the source engine attribute parameters of the object to be drawn to the current engine object through the pre-drawing synchronization interface. The source engine attribute parameters include matrix, hierarchy, visibility, texture and material state.

[0036] Specifically, when the game logic calls the drawing interface, the system receives the display object to be drawn, matrix parameters, transparency parameters, anti-aliasing parameters, debugging parameters, and the current rendering texture state. If the rendering texture or display object is empty, the current drawing is terminated. If the drawing is valid, the current active texture version number is updated, and the pre-draw synchronization interface of the display object is called to synchronize the matrix, layer, visibility, texture, and material state of the original Flash / Starling class object to the Unity object.

[0037] In some embodiments, matrix synchronization includes, for example, reading the matrix parameters of the Flash object (containing six parameters a, b, c, d, tx, and ty), converting them into a Unity matrix format, and correcting for the axial differences between the Unity coordinate system (origin at the bottom left corner, Y-axis pointing upwards) and the Flash coordinate system (origin at the top left corner, Y-axis pointing downwards), for example, multiplying the row corresponding to the Y-axis by -1.

[0038] Layer synchronization includes, for example, reading the depth value and sibling index of a Flash object in the display list, mapping them to Unity's rendering sort value or Z-axis position, forming a Unity object transformation tree, and ensuring that the parent-child occlusion relationship is consistent with the original engine.

[0039] Visibility synchronization includes: reading the visibility property of the Flash object; if it is false, setting the corresponding Unity object to be invisible and skipping the drawing.

[0040] Texture and material synchronization includes: setting up texture and material mapping tables to map Flash texture objects to Unity's Texture2D objects and bind them to material instance properties; reading parameters such as the Flash object's opacity and blending mode and setting them to the corresponding properties of the Unity material instance.

[0041] S3. Based on the synchronization results of the source engine attribute parameters and according to the source engine rendering logic, form a set of rendering command buffers.

[0042] Based on the above synchronization results, the system forms a rendering command buffer set according to the rendering logic of the source engine (Flash / Starling). In some embodiments, the rendering command buffer set includes, but is not limited to: camera matrix simulation commands, rendering texture target setting commands, screen clearing control commands, batching commands for continuous meshes of the same material, mesh drawing commands, and renderer drawing commands.

[0043] In some embodiments, the formation of the rendering command buffer set includes the following sub-steps: (1) Set the target rendering texture to be written through the command buffer, and determine whether to clear the original content based on whether the rendering texture is persistent. If it is not persistent, write the clear screen command; if it is persistent, do not write the clear screen command and retain the previous drawing result.

[0044] (2) Calculate the orthogonal dimensions (Size = height / 2) and camera center point (width / 2, height / 2) of the simulated drawing camera based on the width and height of the target rendering texture and the original stage coordinate system.

[0045] (3) Generate the view matrix and projection matrix based on the world-to-local transformation matrix of the simulated camera, orthogonal dimensions, aspect ratio, near clipping plane and far clipping plane, and correct the axial differences between the Unity coordinate system and the original display engine coordinate system (such as flipping the Y-axis and adjusting the depth axis), and then write the view matrix and projection matrix into the command buffer.

[0046] (4) Collect and sort the drawable sub-objects in the display object to be drawn in hierarchical order to form a renderer sorting queue.

[0047] (5) Perform dynamic batch traversal of the renderer sort queue, generate batched mesh drawing commands or renderer drawing commands, and write them to the command buffer.

[0048] S4. The rendering command buffer set is added to the command buffer set to be executed, and the dedicated rendering camera submits the command buffer in the command buffer set to be executed to the rendering thread for execution.

[0049] The aforementioned set of rendering command buffers is added to the set of command buffers to be executed for the dedicated rendering camera. Specifically, for example, in the OnPreRender event of the dedicated rendering camera, camera.AddCommandBuffer() is called to attach the command buffers to the dedicated camera.

[0050] During rendering, the dedicated rendering camera submits all command buffers in the set of command buffers to the rendering thread for execution. The graphics card executes them sequentially according to the order in the command buffers: first, bind the rendering target; then, clear the screen (if necessary); then, set the view / projection matrix; and finally, execute the drawing commands (either a batched DrawMesh or a standalone DrawRenderer).

[0051] After rendering is complete, the camera post-event calls remove all command buffers and clean up temporary references. Simultaneously, used command buffers are cleared and returned to the command buffer object pool for reuse in subsequent frames.

[0052] In some embodiments, if the project uses a programmable rendering pipeline, the command collection, material mapping, renderer sorting, dynamic batching, multi-threaded collaboration, and object pool reuse logic in this invention can also be ported to a custom rendering channel. This invention does not limit the specific pipeline entry point.

[0053] In some embodiments, the command buffer submission method can be to use a dedicated rendering camera to mount the command buffer, or, when the platform and rendering timing requirements are met, to use a graphical interface to directly execute the command buffer or other command submission mechanisms.

[0054] It should be noted that the step numbers in the embodiments of the present invention are only for ease of description and do not constitute a strict limitation on the execution order. There can be reasonable parallelism or sequential adjustment between the steps.

[0055] In this embodiment of the invention, the drawing commands of the target display object tree are submitted to the rendering thread for execution through the command buffer. Before submission, the camera matrix simulation, rendering texture target setting, screen clearing control, renderer collection sorting, rendering texture dedicated material mapping, batching of continuous meshes of the same material, and object pool reuse of command buffer, mesh, and material are completed.

[0056] This invention maintains compatibility with Unity's built-in rendering pipeline. This solution does not require a complete project migration to the programmable rendering pipeline, nor does it require restructuring the main scene rendering process. It is suitable for projects with existing Unity standard rendering pipelines to migrate Flash / Starling-like rendering capabilities while preserving their existing material systems and asset structures.

[0057] like Figure 6 As shown, some embodiments of the present invention support multi-threaded collaborative rendering. The system handles display object state synchronization, renderer collection, material mapping, and command organization as the logic side, while the actual execution of the command buffer is handled by the rendering side. After collecting and constructing drawing commands in the current frame, the logic side hands over the command buffer to a dedicated rendering camera; the rendering thread consumes this command buffer in standard rendering pipeline events and completes the rendering texture output. Through this producer-consumer command passing mechanism, the main logic processing and rendering execution can proceed in parallel within the thread model allowed by the engine, thereby reducing the main thread's waiting time for rendering. This allows the logic side to be responsible for collecting and organizing drawing requests, while the rendering side is responsible for executing commands on the rendering thread, forming a multi-threaded collaborative rendering mechanism. This improves performance while maintaining the original Flash / Starling-style rendering texture drawing and batch drawing semantics.

[0058] In some embodiments, the process of receiving the object to be drawn for display further includes: Create a rendering texture encapsulation object, which stores one or more of the following: rendering texture width, height, scaling, format, whether it is persistent, root texture, and currently active texture information.

[0059] The render texture wrapper object is a wrapper around a native Unity texture, storing the following information: Width and Height: Determined by the texture creation parameters of the source engine (Flash / Starling), used to calculate simulated camera dimensions. Scaling: Determined by the texture scaling parameters of the source engine, used for rendering resolution adaptation. Format: Mapped from the source engine's texture format (e.g., RGBA, BGRA, Compressed) to the Unity texture format. Persistence: Determined by the persistent parameter of the source engine texture, used to determine whether to clear the screen. Root Texture: Records a reference to the parent texture when the texture is derived from another texture (e.g., a texture set). Currently Active Texture: A reference to the underlying Unity texture object.

[0060] The rendering texture wrapper object creates a Unity texture instance in its constructor, allocates video memory, and performs format conversion according to platform and performance requirements (such as using the ASTC compression format on mobile devices).

[0061] It also includes creating a command buffer object pool, which is used to store and provide the command buffers required by the texture rendering method.

[0062] The command buffer object pool pre-creates several command buffer instances during initialization and maintains an available queue. When a command buffer is needed, a function is called to retrieve it from the pool; after execution is complete and cleanup is performed, the command buffer is returned to the pool.

[0063] By using the command buffer object pool mechanism, the memory allocation and garbage collection overhead caused by the frequent creation and destruction of command buffer objects are avoided, which significantly reduces the GC peak per frame.

[0064] Specifically, the system provides the migrated display engine with a wrapper object corresponding to the original rendering texture. For each rendering texture wrapper object, the system obtains a command buffer from the command buffer object pool and returns the command buffer to the object pool when the object is released. The rendering texture can be temporarily created by Unity rendering textures or created by other texture allocation mechanisms.

[0065] In some embodiments, in step S3, based on the synchronization results of the source engine attribute parameters, a rendering command buffer set is formed according to the source engine rendering logic, such as... Figure 7 As shown, it includes: S31. Renderer Collection and Sort: The renderer collects and sorts the drawable sub-objects in the display object to be drawn in hierarchical order to form a renderer sort queue.

[0066] In some embodiments, step S31 includes: Traverse the transformation tree of the display objects to be drawn to collect drawable renderers. The transformation tree of the display objects to be drawn is obtained based on the hierarchical attributes of the display objects to be drawn in the source engine.

[0067] Record the level depth and intra-level sort value of each drawable renderer in the transformation tree of the display object to be drawn.

[0068] The drawing order of each of the drawable renderers is sorted based on the layer depth, the intra-layer sorting value, and the display tree depth to form a renderer collection sorting command.

[0069] Specifically, first, the transformation tree of the display objects to be drawn is traversed. The transformation tree of the display objects to be drawn is obtained based on the synchronization of the hierarchical attributes of the display objects to be drawn in the source engine. That is, in the pre-draw synchronization interface, the parent-child hierarchy of Flash / Starling has been synchronized to the Transform hierarchy of Unity, forming a corresponding transformation tree.

[0070] Next, a depth-first search (DFS) traversal is performed on the transformation tree. For each node, its visibility (visible property) is checked; if it is not visible, the node and its subtrees are skipped. For visible nodes with graphical content, their corresponding Unity renderers are added to the collection list, and the following information is recorded: Hierarchical depth: The path length from the root node to the current node.

[0071] Intra-level sorting value: The index of the current node in its parent node's child list.

[0072] Finally, in some embodiments, the collection list is stably sorted sequentially according to the priority order of rendering level identifier, sort value within the level, and display tree depth, forming a renderer sorting queue. The sorted queue ensures that the drawing order is consistent with the drawing order of the original Flash / Starling display list. Through this sorting rule, the drawing order of the child nodes of the original Flash / Starling display object container can be reproduced as much as possible during Unity rendering, avoiding occlusion errors caused by simply relying on the Unity scene traversal order.

[0073] It should be understood that the Unity renderer here refers to the drawable objects or nodes in the transformation tree.

[0074] In some embodiments, the display object sorting rule can be adjusted according to the project engine characteristics to one or more combinations of rendering level identifier, sorting value within level, depth coordinates, sibling node order, display tree traversal sequence number, depth value, or custom rendering priority.

[0075] S32. Sequentially determine and mark whether the renderers in the renderer sorting queue are eligible for censorship.

[0076] Specifically, the sorted renderer queue is sequentially evaluated for batch compatibility, and objects are marked as either batch-compatible or non-batch-compatible. Batch-compatible objects must meet the following conditions: they are mesh renderer types, have a mesh filter, use only a single material, the mesh is not empty, and the number of vertices is within a reasonable range. Renderers that do not meet the above conditions (such as multi-material objects, particle systems, SpriteRenderers, line renderers, etc.) are marked as non-batch-compatible objects.

[0077] S33. Perform dynamic batch traversal on the sorted queue of the marked renderers. If the current renderer can be batched and its material is the same as the current batch, then add the current renderer to the current batch; if the current renderer cannot be batched or its material is different from the current batch, create a new batch.

[0078] S34. Whenever a new batch is created or a batch traversal ends, the current batch is committed. If the batch contains multiple sub-objects, a mesh merging description array is generated, and multiple meshes are merged into a temporary mesh according to their respective matrices, forming a mesh drawing command added to the rendering command buffer set. If the batch contains a single sub-object, a mesh drawing command or a renderer drawing command is formed and added to the rendering command buffer set.

[0079] By combining continuous, single-material, batchable mesh renderers into a temporary merged mesh and drawing it using a single mesh drawing command, the drawing call pressure caused by submitting a large number of small display objects one by one is reduced.

[0080] In some embodiments, for a multi-material renderer, sub-mesh drawing, splitting into multiple batch mesh drawing units, material array mapping, rendering renderer command degradation, or a dedicated multi-material batching strategy can be adopted.

[0081] In some embodiments, dynamic batching can employ runtime mesh merging, pre-batch mesh caching, graphics processor instantiation, material property block grouping, static batching, or other methods that reduce the number of draw submissions while maintaining the display order.

[0082] In some embodiments, when encountering objects that cannot be batched, the system first refreshes the current batch (submitting existing batches) and then uses a compatible drawing path (DrawRenderer or DrawMesh by sub-mesh) to prevent disruption of the display order. This invention supports local degradation and debugging. For objects that do not yet meet the batching conditions, such as those with multiple materials or non-mesh renderers, the system can use a compatible drawing path to ensure the display result and assist developers in locating migration differences through alerts or saving images of rendered textures.

[0083] This invention enables single-draw, batch-draw, clearing, matrix drawing, and persistent texture rendering behaviors found in Flash / Starling projects to continue within the Unity built-in rendering pipeline by encapsulating rendering textures, synchronizing object states before drawing, simulating camera matrices, controlling persistent screen clearing, and using batch drawing blocks. By recursively collecting renderers and sorting them according to rendering level, intra-level sorting values, and display tree depth, it reduces display level errors caused by differences in Unity's transformation node traversal order or renderer order after project migration.

[0084] In some embodiments, prior to the renderer collection sorting, there are also steps for setting target rendering textures, screen clearing control, and simulating camera matrix calculation.

[0085] The target rendering texture to be written is set through the command buffer, and the original content is cleared based on whether the rendering texture is persistent. This forms the rendering texture target setting command and the screen clearing control command, which are then added to the rendering command buffer set.

[0086] The current rendering target is set to the rendering texture to be written via the command buffer, that is, the target rendering texture wrapper object is set as the currently active texture, and the rendering texture target setting command is written. The `isPersistent` property stored in the rendering texture wrapper object determines whether to clear the original content: if it is not persistent mode, a clear screen control command is written, clearing the background with the specified color. If it is persistent mode, no clear screen control command is written, and the previous drawing result is retained to support continuous drawing effects similar to a canvas (such as trailing effects). Preferably, for persistent rendering textures, continuous canvas semantics can be achieved by retaining the target texture content, double buffering, temporary texture compositing, loading and replaying historical drawing commands, or other methods.

[0087] In some embodiments, after determining the rendering texture target, a list of objects to be batched is created for the current rendering texture for subsequent batch rendering.

[0088] The simulation camera matrix calculation includes: first, calculating the size of the simulated camera and the camera center point based on the width and height of the target rendering texture and the original stage coordinate system.

[0089] Then, based on the simulated world-to-local transformation matrix, orthogonal dimensions, aspect ratio, near clipping plane, and far clipping plane of the camera, a view matrix and a projection matrix are generated to form a camera matrix simulation command and added to the rendering command buffer set.

[0090] Specifically, half the texture height is used as the orthographic camera size, and the top left corner of the simulated camera is aligned with the top left corner of the original stage or main camera, so that the coordinates of display objects in the original engine, which are in pixels or stage points, are consistently mapped in Unity.

[0091] Subsequently, the view matrix and projection matrix are generated based on the world-to-local transformation matrix of the simulated camera (i.e., the transformation matrix corresponding to the camera's center point), orthogonal dimensions, aspect ratio, near clipping plane, and far clipping plane. For axial differences between the Unity coordinate system and the original display engine coordinate system (such as opposite Y-axis directions or different depth axis directions), the system corrects the view matrix, for example, by flipping or adjusting the corresponding row of the depth axis. Specifically, the Y-axis corresponding row of the view matrix is ​​multiplied by -1 to achieve Y-axis flipping, and the corresponding row of the depth axis is adjusted as needed.

[0092] After the correction is completed, the function is called to write the view matrix and projection matrix into the command buffer, so that subsequent mesh drawing commands or renderer drawing commands are executed in the camera space that is consistent with the original render texture drawing semantics.

[0093] In some embodiments, the method further includes mapping and reusing materials specifically designed for rendering textures. Maintain a dedicated shader mapping table, which has a mapping relationship between the source engine shader name and the resource path of the dedicated shader of the current engine; When the original material and original texture of the object to be drawn meet the mapping conditions, the material instance corresponding to the target shader is obtained from the material object pool according to the dedicated shader mapping table, and the main texture is set after copying the properties of the original material. If consecutive objects to be drawn use the same original material and the same original texture, then the same material instance is reused.

[0094] Specifically, such as Figure 8 As shown, the dedicated shader map uses the shader name of the source engine (Flash / Starling) as the key and the dedicated shader resource path of the current engine (Unity) as the value, and is loaded from the configuration file during system initialization. When the original material and original texture of the object to be drawn meet the mapping conditions (i.e., the shader used by the original material has a corresponding entry in the map), the system retrieves the material instance corresponding to the target shader from the material object pool. Specifically, the material object pool is linked to the shader map, maintaining the created material instances with "shader path + texture reference" as the key. After retrieving the material instance, the necessary attributes (such as color, transparency, and blending mode parameters) are copied from the original material, and the original texture is set as the main texture.

[0095] In some embodiments, rendering texture-specific material mapping can be implemented using shader names, shader tags, material keywords, resource numbers, material type enumerations, or runtime configuration tables. Material property copying can be done entirely or only the properties required by the current shader can be copied.

[0096] If consecutive objects to be drawn use the same original material and the same original texture, the same material instance is reused, and no new material instance is created. In some embodiments, this reuse mechanism is implemented in the following ways: (1) When traversing the drawing queue, record the unique identifier of the current material (generated by a combination of shader path, texture reference and material parameters).

[0097] (2) When the material identifier of the next object is the same as that of the current object, and the two are consecutive in the sort queue, they will be merged into the same batch during batch traversal.

[0098] (3) Objects in the same batch share the same material instance, thereby satisfying the batching condition and reducing drawing calls.

[0099] This invention enables stable display of effects such as blurring, skeletal animation, outlining, and shading, which have special sampling or pre-rendering requirements in the rendering texture environment, through mapping from the original shader to a dedicated shader for rendering textures, copying material properties, and setting texture properties. The aforementioned material mapping and reuse mechanism avoids the memory allocation and garbage collection pressure caused by creating new material instances for each display object every frame, while preserving the conditions for subsequent batch optimization.

[0100] In some embodiments, for scenarios where it is necessary to prevent the source mesh from being modified by subsequent logic or to maintain a snapshot of the mesh during the execution of drawing commands, the system obtains a temporary mesh from the mesh object pool and copies the necessary data of the source mesh using a pre-allocated list of vertices, texture coordinates, colors, and triangles. During copying, the target mesh data is cleared but its allocated memory is retained, and only the vertices, first sub-mesh triangles, boundaries, texture coordinates, and color data required for the migration project rendering are copied, thereby reducing the cost of temporary allocation and unnecessary data copying per frame.

[0101] In some embodiments, the content of the mesh copy can be expanded to normals, tangents, bone weights, multiple sets of texture coordinates, multiple submeshes, or custom vertex flows, depending on the needs of the project; alternatively, the shared mesh can be directly referenced when the lifecycle of the source mesh is stable, thus avoiding copying.

[0102] This invention reduces the creation of temporary objects and managed memory allocation per frame by reusing command buffers, meshes, and material object pools, as well as statically reusing vertex, texture coordinates, colors, and triangle lists, thereby improving the stability of high-frequency drawing scenes such as combat or interfaces.

[0103] In some embodiments, the present invention can support batch drawing blocks. The system provides a batch drawing interface corresponding to the batch drawing semantics of the source engine. When entering a batch drawing block, the system first performs target setting and necessary screen clearing on the target rendering texture, and then allows multiple calls to the single-object drawing interface in the callback function. During batch drawing, each single-object drawing only collects the renderer and mapped materials and adds them to the batching list, without immediately submitting them to the rendering thread. After the callback ends, the system performs a dynamic batching and a command submission on all collected objects, thereby reducing the number of rendering texture target switching and command buffer submissions.

[0104] In some embodiments, after rendering with a dedicated rendering camera or when a rendered texture encapsulation object is released, the system returns temporary materials, temporary meshes, and command buffers to the corresponding object pool. Before returning materials, specified texture attributes can be cleared to break the reference to the original texture; before returning meshes, their memory is retained for future reuse; when destroying a custom rendering control module, the system removes camera events, destroys the dedicated rendering camera, and clears the entire object pool. Through the above processing, runtime resource leaks and continuous garbage collection jitter are avoided. Preferably, the object pool recycling strategy can be based on frame recycling, recycling upon completion of rendered texture drawing, recycling upon scene switching, or recycling based on memory thresholds. Different sets of texture attributes can be cleared before material recycling; this invention does not limit the specific attribute names.

[0105] In some embodiments, the present invention can provide debugging and compatibility paths. The system can read back the target rendered texture and save it as an image in debug mode for verifying the display effect after migration. For renderers that do not support batching or do not meet current custom rendering limitations, the system provides a degraded drawing path for drawing renderer commands or multi-material mesh drawing commands, and outputs alarm information to help developers locate display differences for specific objects. Preferably, debug output can be achieved through methods such as reading back and saving rendered textures as images, frame debugging markers, command buffer naming, performance counters, drawing call statistics, or comparison of rendering result summaries.

[0106] In one embodiment, the rendering texture class in the migration project inherits from the original display engine's texture abstraction and internally uses Unity rendering textures as active textures. After receiving the display object, the drawing interface first calls the display object's pre-draw synchronization method, then creates or updates the drawing camera parameters according to the target texture size, and subsequently calls the custom rendering control module to complete screen clearing, camera simulation, renderer submission, dynamic batching, and rendering thread submission.

[0107] In another embodiment, the system maintains a dedicated shader mapping table for rendering textures. For ordinary project shaders, interface blur shaders, skeletal animation shaders, stroked bone shaders, or bone shaders with black tinting, if they require rewriting pre-rendered data or texture properties in a rendering texture environment, they are replaced with the corresponding rendering texture version shader. Replacement materials are obtained from the material pool, and the same instance is reused when the original material and original texture are continuous and consistent, to balance display correctness and batching performance.

[0108] In summary, this invention centralizes rendering texture drawing, material mapping, dynamic batching, multi-threaded command submission, object pooling, and resource recycling into a unified custom rendering module, reducing the cost of repeated processing of cameras, rendering textures, materials, and meshes by various business modules.

[0109] In one embodiment, a relatively complete example of a migration rendering project workflow is provided, including: S100: Initialize the custom rendering control module. The system creates a dedicated rendering camera during Unity runtime. This dedicated rendering camera is independent of the main scene camera and the interface camera, and is used to mount and execute rendering texture drawing commands. This dedicated rendering camera can be set to render at an earlier depth, has no screen clearing overhead, and by default does not render any layers. A buffer of commands to be executed is inserted in the pre-rendering event of the camera, and all command buffers are removed and temporary references are cleaned up in the post-rendering event of the camera.

[0110] S110: Create a rendering texture wrapper object. The system provides a wrapper object corresponding to the original rendering texture for the migrated display engine. This wrapper object stores information such as the rendering texture's width, height, scale, format, persistence status, root texture, and currently active texture. For each rendering texture wrapper object, the system retrieves a command buffer from the command buffer object pool and returns the command buffer to the pool when the object is released. The rendering texture can be temporarily created by Unity rendering textures or created by other texture allocation mechanisms.

[0111] S120: Receive display object drawing request. When the game logic calls the drawing interface, the system receives the display object to be drawn, matrix parameters, transparency parameters, anti-aliasing parameters, debugging parameters, and the current rendering texture state. If the rendering texture or display object is empty, the current drawing is terminated. If the drawing is valid, the current active texture version number is updated, and the pre-draw synchronization interface of the display object is called to synchronize the matrix, layer, visibility, texture, and material state of the original Flash / Starling class object to the Unity object.

[0112] S130: Calculate the simulated camera parameters. The system calculates the camera size and camera center point for drawing based on the width and height of the target rendered texture and the original stage coordinate system. For example, half the texture height can be used as the orthogonal camera size, and the top left corner of the simulated camera can be aligned with the top left corner of the original stage or main camera, thus ensuring a consistent mapping of display object coordinates in pixels or stage points in the original engine to Unity.

[0113] S140: Set the target rendering texture and clear the screen. The system sets the current rendering target to the rendering texture to be written via the command buffer, and determines whether to clear the original content based on whether the rendering texture is persistent. If the rendering texture is in non-persistent mode, it is cleared with a specified background color before each drawing; if it is in persistent mode, the previous drawing result is retained to support continuous drawing effects similar to a canvas. The system also creates a list of objects to be batched for this rendering texture for subsequent collection and batch drawing.

[0114] S150: Simulates the camera view matrix and projection matrix. The system does not rely on the target rendering camera for full rendering. Instead, it generates the view and projection matrices based on the rendering camera's world-to-local transformation matrix, orthogonal dimensions, aspect ratio, near clipping plane, and far clipping plane. For axial differences between the Unity coordinate system and the original display engine coordinate system, the system can correct the view matrix, such as by inverting or adjusting the corresponding rows of the depth axis. The view and projection matrices are then written to the command buffer, ensuring that subsequent mesh rendering commands or renderer commands are executed in camera space consistent with the original render texture rendering semantics.

[0115] S160: Recursively collect and sort renderers to be drawn. The system recursively traverses from the root node of the Unity transformation corresponding to the display object to be drawn, skipping inactive or invisible objects, collecting renderers and recording the layer depth of each renderer in the display object tree. After collection, the system sorts the renderers according to the rendering layer identifier, the sort value within the layer, and the display tree depth.

[0116] S170: Mapping and reusing materials dedicated to rendering textures. For shaders that rely on pre-rendered data, special texture sampling, or differences in rendering texture scenes in the original project, the system maintains a mapping table from the original shader name to the resource path of the dedicated rendering texture shader. When the original material and original texture of the image object to be drawn meet the mapping conditions, the system retrieves the material instance corresponding to the target shader from the material object pool, copies the original material properties, and sets the main texture. If consecutive objects use the same original material and the same original texture, the same dedicated rendering texture material instance is reused to reduce material object creation and retain subsequent batching conditions.

[0117] S180: Convert renderers to batchable rendering units. The system converts the sorted renderers into batch mesh rendering units. If the renderer is a mesh renderer, has a mesh filter, uses only a single material, and meets the mesh rendering conditions, it is marked as a batchable object, and its mesh, material, and local-to-world transformation matrix are recorded. If the renderer does not meet the above conditions, such as having multiple materials, being a non-mesh renderer, or lacking a mesh filter, it is marked as a non-batchable object, and a compatible path of either the render renderer command or the sub-mesh render command is used in subsequent rendering.

[0118] S190: Perform low-garbage-collection mesh copying. For scenarios where it's necessary to prevent the source mesh from being modified by subsequent logic or to maintain a mesh snapshot during draw command execution, the system obtains a temporary mesh from the mesh object pool and copies the necessary data from the source mesh using a pre-allocated list of vertices, texture coordinates, colors, and triangles. During copying, the target mesh data is cleared but its allocated memory is retained, and only the vertices, first sub-mesh triangles, boundaries, texture coordinates, and color data required for migration project rendering are copied, thereby reducing the cost of temporary allocation and unnecessary data copying per frame.

[0119] S200: Dynamically batch consecutive drawing units of the same material. The system traverses the list of units to be drawn in sorted order. If a drawing unit can be batched and its material is the same as the material of the current batch, it is added to the current batch. When the material changes, an object that cannot be batched is encountered, or the list ends, the system commits the existing batch. If there is only one object in the batch, the drawing command is written directly through the drawing mesh command. If there are multiple objects in the batch, a mesh merging description array is generated, and multiple meshes are merged into a temporary mesh according to their respective matrices, and then the drawing command is written through a drawing mesh command. When an object that cannot be batched is encountered, the system first refreshes the current batch and then uses a compatible drawing path to prevent disruption of the display order.

[0120] S210: Submit command buffers to the rendering thread for execution. The system adds a command buffer containing commands such as target settings, screen clearing, camera matrix, drawing mesh, and drawing renderer to the execution set of the dedicated rendering camera. The dedicated rendering camera attaches the command buffers in the set to the specified camera event in its pre-render event, and they are subsequently executed by the Unity standard rendering pipeline on the rendering thread. After rendering is complete, the system removes all command buffers from that camera and clears the commands, batch lists, and temporary object references.

[0121] The present invention also provides a texture rendering apparatus for engine migration, such as Figure 9 As shown, it includes: Initialize the rendering control module and create a dedicated rendering camera. The dedicated rendering camera is used to mount and submit rendering texture drawing commands. The pre-event of the dedicated rendering camera has a set of command buffers to be executed. The post-event of the dedicated rendering camera removes all mounted command buffers and temporary references. The drawing interface module receives the display object to be drawn and synchronizes the source engine attribute parameters of the display object to be drawn to the current engine object through the pre-drawing synchronization interface. The source engine attribute parameters include matrix, hierarchy, visibility, texture and material state. The rendering logic organization module forms a set of rendering command buffers based on the synchronization results of the source engine attribute parameters and the source engine rendering logic. The rendering thread submission module adds the rendering command buffer set to the command buffer set to be executed, and the dedicated rendering camera submits the command buffers in the command buffer set to be executed to the rendering thread for execution.

[0122] The present invention also provides an electronic device, such as... Figure 10 As shown, it includes a memory and a processor. The memory stores a computer program, which, when executed by the processor, implements the texture rendering method in engine migration as described in any of the above embodiments.

[0123] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the texture rendering method in engine migration as described in any of the above embodiments.

[0124] Those skilled in the art will further 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 invention.

[0125] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented in hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0126] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A texture rendering method in engine migration, characterized in that, Includes the following steps: A dedicated rendering camera is created, which is used to mount and submit rendering texture drawing commands. The pre-event of the dedicated rendering camera is configured with a set of command buffers to be executed, and the post-event of the dedicated rendering camera is configured to remove all command buffers and temporary references mounted to the dedicated rendering camera. Receive the object to be drawn and synchronize the source engine attribute parameters of the object to be drawn to the current engine object through the pre-draw synchronization interface. The source engine attribute parameters include matrix, hierarchy, visibility, texture and material state. Based on the synchronization results of the source engine attribute parameters and according to the source engine rendering logic, a set of rendering command buffers is formed. The rendering command buffer set is added to the command buffer set to be executed, and the dedicated rendering camera submits the command buffers in the command buffer set to be executed to the rendering thread for execution.

2. The texture rendering method in engine migration according to claim 1, characterized in that: The rendering command buffer set includes one or more combinations of camera matrix simulation commands, rendering texture target setting commands, screen clearing control commands, batching commands for continuous meshes of the same material, mesh drawing commands, and renderer drawing commands.

3. The texture rendering method in engine migration according to claim 1, characterized in that: Before receiving the object to be drawn and displayed, the process also includes: Create a rendering texture encapsulation object, which stores one or more combinations of rendering texture width, height, scaling, format, whether it is persistent, root texture, and currently active texture information; Create a command buffer object pool, which is used to store and provide the command buffer required by the texture rendering method.

4. The texture rendering method in engine migration according to claim 1, characterized in that: The synchronization results based on the source engine attribute parameters form a rendering command buffer set according to the source engine rendering logic, including: The renderer collects and sorts the drawable sub-objects in the object to be drawn and displays in hierarchical order to form a renderer sorting queue. The renderers in the renderer sorting queue are sequentially evaluated for and marked as unacceptable. The sorted queue of marked renderers is dynamically batched. If the current renderer can be batched and its material is the same as that of the current batch, the current renderer is added to the current batch. If the current renderer cannot be batched or its material is different from that of the current batch, a new batch is created. Whenever a new batch is created or a batch traversal ends, the current batch is committed. If the batch contains multiple sub-objects, a mesh merge description array is generated, and the multiple meshes are merged into a temporary mesh according to their respective matrices, forming a mesh drawing command added to the rendering command buffer set. If the batch contains a single sub-object, a mesh drawing command or a renderer drawing command is formed and added to the rendering command buffer set.

5. The texture rendering method in engine migration according to claim 4, characterized in that: The renderer collects and sorts the drawable sub-objects in the object to be drawn in hierarchical order to form a renderer sorting queue, including: Traverse the transformation tree of the display objects to be drawn to collect drawable renderers, wherein the transformation tree of the display objects to be drawn is obtained based on the hierarchical attributes of the display objects to be drawn in the source engine; Record the level depth and intra-level sort value of each drawable renderer in the transformation tree of the display object to be drawn; The drawing order of each of the drawable renderers is sorted based on the layer depth, the intra-layer sorting value, and the display tree depth to form a renderer collection sorting command.

6. The texture rendering method in engine migration according to claim 4, characterized in that: Before the renderer collects and sorts data, it also includes: The target rendering texture to be written is set through the command buffer, and the original content is cleared based on whether the rendering texture is persistent. This forms the rendering texture target setting command and the screen clearing control command, which are then added to the rendering command buffer set. The size of the simulated camera and the camera center point are calculated based on the width and height of the target rendered texture and the original stage coordinate system. Based on the world-to-local transformation matrix, orthogonal dimensions, aspect ratio, near clipping plane, and far clipping plane of the simulated camera, a view matrix and a projection matrix are generated to form a camera matrix simulation command and added to the rendering command buffer set.

7. The texture rendering method in engine migration according to claim 1, characterized in that: This also includes mapping and reusing materials specifically for rendering textures: Maintain a dedicated shader mapping table, which has a mapping relationship between the source engine shader name and the resource path of the dedicated shader of the current engine; When the original material and original texture of the object to be drawn meet the mapping conditions, the material instance corresponding to the target shader is obtained from the material object pool according to the dedicated shader mapping table, and the main texture is set after copying the properties of the original material. If consecutive objects to be drawn use the same original material and the same original texture, then the same material instance is reused.

8. A texture rendering apparatus for engine migration, characterized in that, include: Initialize the rendering control module and create a dedicated rendering camera. The dedicated rendering camera is used to mount and submit rendering texture drawing commands. The pre-event of the dedicated rendering camera has a set of command buffers to be executed. The post-event of the dedicated rendering camera removes all mounted command buffers and temporary references. The drawing interface module receives the display object to be drawn and synchronizes the source engine attribute parameters of the display object to be drawn to the current engine object through the pre-drawing synchronization interface. The source engine attribute parameters include matrix, hierarchy, visibility, texture and material state. The rendering logic organization module forms a set of rendering command buffers based on the synchronization results of the source engine attribute parameters and the source engine rendering logic. The rendering thread submission module adds the rendering command buffer set to the command buffer set to be executed, and the dedicated rendering camera submits the command buffers in the command buffer set to be executed to the rendering thread for execution.

9. An electronic device, characterized in that, It includes a memory and a processor, the memory storing a computer program that, when executed by the processor, implements the texture rendering method in engine migration as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the texture rendering method in engine migration as described in any one of claims 1-7.

Images