Map editing method, map rendering method and computing equipment

Abstract

The embodiment of the invention provides a map editing method, a map rendering method and computing device.The map editing method is applied to a back-end server of an editor, the editor further comprises a plurality of front ends, and the method comprises the steps that a plurality of sub-maps of a to-be-edited map are obtained, and corresponding editing hierarchy files are constructed for the sub-maps, each editing hierarchy file is independently stored on a back-end server; distributing the plurality of sub-maps to each front end in parallel, so that a user performs editing operation on the sub-maps to generate editing data; obtaining editing data of each sub-map in parallel from each front end; and synchronizing the editing data to the editing hierarchy file corresponding to each sub-map in parallel, and obtaining a plurality of target sub-maps under the condition that editing is completed. The method can improve the map making efficiency, and can be widely applied to the fields of digital culture product making software and the like.

Description

TECHNICAL FIELD

[0001] Embodiments of the present specification relate to the field of digital cultural products, and in particular to a map editing method, a map rendering method and a computing device. BACKGROUND

[0002] With the development of digital cultural industries such as virtual reality and digital twin, the number of maps in virtual scenes is gradually increasing. Therefore, there is a higher requirement for the efficiency of map making in the development process of virtual scenes.

[0003] The existing map making method mainly relies on a scene editor, and divides the entire virtual world into multiple independent maps, and then an artist or other production personnel is responsible for the making of one or several independent maps. However, as the project size increases, the size and content density of a single map increase, resulting in a significant decrease in loading, operating and saving speed in the editor, which seriously affects the smoothness of production. Moreover, this method cannot support multiple people to edit the same independent map at the same time. If collaborative editing is forcibly attempted, it may cause different production personnel to modify the same scene resource out of sync, resulting in version conflicts and causing serious data confusion and management costs, which becomes a bottleneck restricting production efficiency.

[0004] Therefore, the existing map making method is not efficient. SUMMARY

[0005] Therefore, the present specification provides a map editing method. One or more embodiments of the present specification also relate to a map rendering method, a computing device, a computer readable storage medium and a computer program product to solve the technical defects in the prior art.

[0006] According to a first aspect of the present specification, a map editing method is provided, applied to a backend server of an editor, the editor further comprising a plurality of front ends, comprising: obtaining a plurality of sub-maps of a to-be-edited map, and constructing a corresponding editing level file for each sub-map, wherein each editing level file is independently saved on the backend server; distributing the plurality of sub-maps in parallel to each front end to enable a user to perform editing operations on the sub-maps to generate editing data; obtaining the editing data of each sub-map in parallel from each front end; synchronizing the editing data to the editing level file corresponding to each sub-map in parallel, and obtaining a plurality of target sub-maps when editing is completed.

[0007] According to a second aspect of the present specification, another map editing method is provided, applied to any one of a plurality of front ends of an editor, the editor further comprising a backend server, comprising: The receiving backend server distributes the sub-maps to the front end, and constructs a corresponding editing level file for each sub-map, wherein the sub-maps are a plurality of sub-maps of the map to be edited obtained by the backend server, and each editing level file is independently saved on the backend server; Based on the editing operation of the user on the sub-map, editing data is generated to enable the backend server to obtain the editing data of each sub-map from each front end in parallel, and to synchronize the editing data to the editing level file corresponding to each sub-map in parallel, until the editing is completed, and a plurality of target sub-maps are obtained.

[0008] According to a third aspect of the embodiments of the present specification, a map rendering method is provided, applied to a client, comprising: receiving a target map, wherein the target map is generated according to the above map editing method; loading and rendering the target map.

[0009] According to a fourth aspect of the embodiments of the present specification, another map rendering method is provided, applied to a client, comprising: receiving a plurality of target sub-maps, wherein the target sub-maps are generated according to the above map editing method; dynamically loading and rendering the target sub-maps.

[0010] According to a fifth aspect of the embodiments of the present specification, a computing device is provided, comprising: a memory and a processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which realize the steps of the above method when executed by the processor.

[0011] According to a sixth aspect of the embodiments of the present specification, a computer readable storage medium is provided, which stores computer programs / instructions, which realize the steps of the above method when executed by the processor.

[0012] According to a seventh aspect of the embodiments of the present specification, a computer program product is provided, comprising computer programs / instructions, which realize the steps of the above method when executed by the processor.

[0013] This specification provides a map editing method according to one embodiment. This method acquires multiple sub-maps of the map to be edited and constructs corresponding editing hierarchy files for each sub-map, with each editing hierarchy file independently stored on a backend server. The multiple sub-maps are distributed in parallel to various frontends, allowing users to perform editing operations on the sub-maps and generate editing data. Editing data for each sub-map is acquired in parallel from each frontend. The editing data is then synchronized in parallel to the corresponding editing hierarchy files for each sub-map until editing is complete, resulting in multiple target sub-maps. By acquiring and distributing multiple sub-maps of the map to be edited, a single large editing task is decoupled from physical space or logical function into multiple independently executable parallel work units. By constructing and independently storing editing hierarchy files for each work unit, different types of object data concentrated in a single scene file are stored and managed separately. This allows multiple editors to focus on modifying specific types of content simultaneously in different work units, thus avoiding direct conflicts caused by simultaneous operations on the same file. By acquiring and synchronizing editing data in parallel, it is ensured that all scattered modifications can be aggregated and persisted to the corresponding independent data units in real time. This reduces the waiting and conflict handling overhead caused by data locking and merging, lowers the complexity of collaboration, and ensures the data quality of the final result. As a result, it improves the efficiency of large-scale virtual scene production, enables efficient, parallel, and collaborative editing of large-scale virtual scenes by multiple people, and eliminates the need for production personnel to repeatedly uninstall and load other maps to see the whole picture. Attached Figure Description

[0014] Figure 1 This is a flowchart illustrating a map editing method provided in one embodiment of this specification; Figure 2 This is a schematic diagram illustrating the division of a map to be edited, provided in one embodiment of this specification. Figure 3 This is a flowchart of another map editing method provided in one embodiment of this specification; Figure 4 This is a flowchart illustrating a map rendering method provided in one embodiment of this specification; Figure 5 This is a flowchart of another map rendering method provided in one embodiment of this specification; Figure 6 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0015] In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present description. However, the present description can be practiced without the specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the present description. The present description can be implemented using a variety of different hardware and software configurations, including hardware and software components specified in the following description.

[0016] The terminology used in this description is for the purpose of describing particular embodiments only and is not intended to be limiting of one or more embodiments of the present description. As used in this description and the appended claims, the singular forms "a," "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

[0017] It will be understood that, although the terms first, second, etc. can be used herein to describe various information, these terms are not intended to denote a temporal or chronological order. Rather, these terms are used solely to distinguish one from another only. For example, without departing from the scope of one or more embodiments of the present description, first can be termed second and, similarly, second can be termed first. The term "if can be construed to mean "when" or "upon" or "in response to determining" depending on the context, as used herein.

[0018] In addition, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in one or more embodiments of the present description are all information and data authorized by the user or authorized by all parties, and the collection, use and processing of related data need to comply with relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation portal for user to choose authorization or refusal.

[0019] First, the nomenclature involved in one or more embodiments of the present description is explained.

[0020] Editor: Editor is a software tool used to create, modify and manage virtual scene content such as terrain, models, lights, scripts, etc. For example, Unity Editor, Unreal Engine Editor, etc.

[0021] Editor Hierarchy: Editor Hierarchy is a logical data unit that divides specific types of objects or assets in a virtual scene, facilitating collaborative editing, version management, and data synchronization of specific types of objects or assets. Its content is stored as an independent editor hierarchy file. For example, an editor hierarchy named "Lighting" will store the positions, colors, intensities, and other parameters of all light objects in that area in the corresponding "Lighting Editor Hierarchy File", which is independent of the "Terrain Editor Hierarchy File" and "Vegetation Editor Hierarchy File" in physical storage.

[0022] Editor Operation: Editor Operation is a behavior initiated by the user in the editor to change the state of an object in the virtual scene. Editor operations can include creation, modification, deletion, and related parameter changes. For example, moving a model, rotating a light, or modifying a trigger script parameter.

[0023] Frontend: Frontend is a client-side software component running on the user's local computer or workstation, providing a graphical user interface and directly interacting with the user for map editing. It carries out the main work of content creation, including but not limited to scene loading and display, editor tool invocation, asset placement and modification, and local staging and submission of editor operations. For example, the scene editing view in integrated development environments such as Unity Editor and Unreal Editor, or specialized editing tools focused on terrain sculpting or vegetation distribution for specific projects.

[0024] Backend Server: Backend Server is a software system deployed in a remote or local network, responsible for coordinating multiple frontends and centrally managing project data. It communicates with the front end through a defined interface, performing collaborative and management tasks such as task scheduling, version control, conflict detection and merging, data persistent storage, and final result integration. For example, a map collaborative production platform that includes task management services, real-time synchronization services, and data processing pipeline services.

[0025] In this specification, a map editing method is provided, and this specification also relates to an image processing method, a text correction method, a computing device, a computer-readable storage medium, and a computer program product, which are described in detail one by one in the following embodiments.

[0026] Reference Figure 1 , Figure 1 A flowchart of a map editing method provided by an embodiment of the present specification is shown, the map editing method is applied to a backend server of an editor, and the editor also includes multiple frontends, including the following specific steps: Step 102: Obtain a plurality of sub-maps of the to-be-edited map, and construct a corresponding editing level file for each sub-map, wherein each editing level file is independently saved on a backend server.

[0027] Embodiments of the present specification are applied to digital cultural product scenarios such as digital twins, virtual reality, metaverse, and interactive media that require editing of large-scale maps. For example, in a large open-world digital tourism project, a virtual scenic area with an area of hundreds of square kilometers needs to be constructed, which includes mountains, rivers, deserts, and towns.

[0028] The to-be-edited map is a structured data representation of a virtual scene that needs to be edited. For example, a scene data package that defines geographical range, underlying terrain, initial asset distribution, and object classification information.

[0029] The sub-map is a local scene data unit that is relatively independent in physical space or logical function after the to-be-edited map is divided according to certain rules. For example, a large world map is divided into 100 blocks according to a 10km x 10km grid, and each block is a sub-map.

[0030] Optionally, one implementation of obtaining a plurality of sub-maps of the to-be-edited map can be to directly load pre-divided and stored sub-map data from a pre-configured database. Another implementation of obtaining a plurality of sub-maps of the to-be-edited map can be to dynamically call a division algorithm to generate in real time according to the number of currently online collaboration front ends. For example, the server detects that there are 8 front ends online, and then dynamically divides the map into 8 approximately equal work areas. Another implementation of obtaining a plurality of sub-maps of the to-be-edited map can be to receive a user's manually uploaded or specified sub-map set through a management interface. The present specification does not limit this.

[0031] The editing level file is a data file used to store and manage a certain type of editing operation and its results in a specific sub-map, and its content is associated with specific editing level logic. For example, a light editing level file specifically stores the type, position, color, and intensity information of all light objects in the region.

[0032] Independent saving means that each editing level file has an independent storage path and version control information in the file system of the server, and its modification and update operations do not affect other editing level files. For example, modification of the terrain layer is only submitted to the terrain layer file, and does not trigger version change of the building layer file.

[0033] Optionally, one way to construct corresponding editable hierarchical files for each sub-map is to automatically generate initially empty hierarchical files based on a preset hierarchical template (such as a basic hierarchical structure containing terrain, vegetation, buildings, and lighting). For example, automatically creating five hierarchical files for lighting, weather, ground, buildings, and vegetation for each sub-map. Another way to construct corresponding editable hierarchical files for each sub-map is to analyze the initial assets in the sub-map and automatically summarize and create hierarchical files based on asset types. For example, scanning the sub-map and grouping all objects of type lighting into the lighting hierarchical file. Yet another way to construct corresponding editable hierarchical files for each sub-map is to manually define and create them according to the project specification configuration file. For example, reading the project document configuration and creating files according to the hierarchical structure defined therein. This specification does not limit the scope of this embodiment.

[0034] For example, after the server obtains the map "Forest World" to be edited, it divides it into three sub-maps: "North Forest Area," "Central Lake Area," and "South Hill Area" according to preset rules. Subsequently, it creates a "Terrain Editing Layer File," a "Vegetation Editing Layer File," and a "Building Editing Layer File" for each sub-map, totaling nine independent layer files stored in the server's version repository.

[0035] Step 102 involves obtaining multiple sub-maps of the map to be edited and constructing corresponding editing level files for each sub-map. Each editing level file is stored independently on the backend server, providing a data foundation for the subsequent parallel distribution of multiple sub-maps to various frontends.

[0036] Step 104: Distribute multiple sub-maps in parallel to each front-end so that users can perform editing operations on the sub-maps to generate edit data.

[0037] Parallel distribution is a backend server strategy that uses task scheduling to simultaneously assign different sub-maps to the execution processes of multiple frontends. For example, the backend server simultaneously sends loading instructions and data indexes for three sub-maps, namely "Region-East", "Region-South", and "Region-North", to the frontends of artists A, B, and C via message queues.

[0038] Editing operations are state-changing commands executed by the user in the front-end editor for a specific object within a certain editing level of the currently processed submap. For example, in the "Terrain" editing level, the brush tool can be used to increase the terrain height of a certain coordinate area by 2 units; or in the "Light" editing level, the illumination angle parameter of the spotlight identified as "light_001" can be modified from 45 degrees to 60 degrees.

[0039] Editing data is structured data describing the content of the editing operation, including the unique identifier of the object being edited, the operation type, and the operation parameters. For example, {"Object Identifier": "Tree_045", "Operation Type": "Move", "New Location": [120, 50, 80]}.

[0040] Alternatively, one approach to distributing multiple sub-maps to various front-ends in parallel is to use a message queue to broadcast task packages to all registered front-ends, allowing each front-end to claim the task based on its own load. Another approach is to perform intelligent scheduling based on front-end performance indicators, distributing content-intensive sub-maps to high-performance front-ends.

[0041] For example, the server simultaneously sends the "North Forest Area" submap and related hierarchical file information to artist A's front end, and the "Central Lake Area" submap and related hierarchical file information to artist B's front end. Both artists can start editing their respective areas simultaneously.

[0042] Step 104 distributes multiple submaps to each front-end in parallel, enabling users to perform editing operations on the submaps and generate editing data. This parallelizes the task and significantly improves the overall editing throughput.

[0043] Step 106: Obtain the editing data of each sub-map from each front-end in parallel.

[0044] Optionally, one way to acquire editing data from each sub-map in parallel is for the server to periodically poll the editing status of each front-end and pull incremental data. For example, requesting modifications since the last synchronization from each front-end every 5 seconds. Another way to acquire editing data from each sub-map in parallel is for each front-end to actively push data to the server after completing an editing unit (such as placing a building complex). Yet another way to acquire editing data from each sub-map in parallel is to implement real-time streaming upload of editing data based on a Web real-time communication protocol. This specification does not limit this approach.

[0045] For example, artist A placed 10 trees in the "North Forest Area," while artist B adjusted the water texture in the "Central Lake Area." The server simultaneously received both batches of edit data via a Web real-time communication protocol and temporarily stored them in a memory queue.

[0046] Step 106, by acquiring the editing data of each sub-map in parallel from each front-end, can promptly aggregate the work results of all collaborators, providing a data foundation for subsequently synchronizing the editing data in parallel to the corresponding editing level files of each sub-map.

[0047] Step 108: Synchronize the edited data in parallel to the corresponding editing level files of each sub-map until the editing is completed, and obtain multiple target sub-maps.

[0048] Parallel synchronization refers to the process where a backend server simultaneously writes editing data from different frontends into their corresponding editing-level files. For example, the backend server uses multithreading or distributed processing techniques to write editing data from different frontends into their corresponding editing-level files.

[0049] Optionally, one way to synchronize edit data in parallel to the edit-level files corresponding to each sub-map is to first cache the edit data in memory at each level buffer, and then write it to the file in batches after reaching a certain threshold. For example, every 100 terrain modification operations are written to the terrain-level file at once. Another way to synchronize edit data in parallel to the edit-level files corresponding to each sub-map is to use an optimistic locking mechanism to directly write to the file concurrently, and if a write conflict occurs, retry or merge based on the version number. Yet another way to synchronize edit data in parallel to the edit-level files corresponding to each sub-map is to convert the editing operation into a database transaction, using the database's concurrency control capabilities to ensure data consistency. This specification does not limit this approach.

[0050] The target submap is the final version of the submap after editing, and its content is determined by the latest status of all corresponding editing level files.

[0051] For example, the server writes the tree placement data submitted by artist A into the "North Forest Area_Vegetation.layer" file, and the lake water texture data submitted by artist B into the "Central Lake Area_Terrain.layer" file. After multiple rounds of editing and synchronization, when the server detects that all the edited layer files of the sub-maps are marked as "approved", it determines that the editing is complete and generates target sub-map files such as "North Forest Area_final" and "Central Lake Area_final" based on the layer files.

[0052] Step 108 obtains multiple target sub-maps by synchronizing the editing data in parallel to the editing level files corresponding to each sub-map until the editing is completed, which ensures that all editing results are persistently and versioned.

[0053] In this embodiment, multiple sub-maps of the map to be edited are acquired, and corresponding editing hierarchy files are constructed for each sub-map. Each editing hierarchy file is independently stored on a backend server. Multiple sub-maps are distributed in parallel to various frontends, allowing users to perform editing operations on the sub-maps and generate editing data. Editing data for each sub-map is acquired in parallel from each frontend. The editing data is then synchronized in parallel to the corresponding editing hierarchy files for each sub-map until editing is complete, resulting in multiple target sub-maps. By acquiring and distributing multiple sub-maps of the map to be edited, a single large editing task is decoupled from physical space or logical function into multiple independently executable parallel work units. By constructing and independently storing editing hierarchy files for each work unit, different types of object data concentrated in a single scene file are stored and managed separately. This allows multiple editors to focus on modifying specific types of content simultaneously in different work units, thus avoiding direct conflicts caused by simultaneous operations on the same file. By acquiring and synchronizing editing data in parallel, it is ensured that all scattered modifications can be aggregated and persisted to the corresponding independent data units in real time. This reduces the waiting and conflict handling overhead caused by data locking and merging, lowers the complexity of collaboration, and ensures the data quality of the final result. As a result, it improves the efficiency of large-scale virtual scene production, enables efficient, parallel, and collaborative editing of large-scale virtual scenes by multiple people, and eliminates the need for production personnel to repeatedly uninstall and load other maps to see the whole picture.

[0054] In one optional embodiment of this specification, obtaining multiple sub-maps of the map to be edited includes: Get the map to be edited; The map to be edited is divided into regions using preset division rules to obtain multiple sub-maps. The division rules include at least one of the following: a preset-size regular region division and a custom-size irregular region division.

[0055] The method for obtaining the map to be edited has been introduced above and will not be repeated here.

[0056] The partitioning rules are pre-defined strategies or criteria used to guide the decomposition of a map to be edited into multiple sub-maps. They define the basis, granularity, or target shape for the partitioning.

[0057] Regional division is the process of decomposing a continuous space or logical set of a map to be edited into multiple parts according to division rules.

[0058] The preset size of the regular area is divided into a way that uses a fixed size (such as a square grid with a fixed side length) to evenly divide the map to be edited.

[0059] Custom-sized irregular areas can be divided into non-uniform, irregular shapes based on map content characteristics (such as terrain boundaries and functional blocks) or project requirements.

[0060] For example, refer to Figure 2 The diagram illustrates a method for dividing a map to be edited in one embodiment of this specification. The map to be edited is a "cultural tourism city," with "building complexes" in the upper left, "mountains" in the upper right, "forests" in the lower left, and "grasslands" in the lower right. After the server obtains the map, it divides it into 16 rectangular sub-maps using the "irregular area division" rule.

[0061] In the embodiments of this specification, by obtaining the map to be edited, and using preset division rules, the map to be edited is divided into regions to obtain multiple sub-maps of the map to be edited, which can flexibly adapt to the needs of different projects for task granularity and workload balancing.

[0062] In one optional embodiment of this specification, obtaining the map to be edited includes: Get the initial map; The initial map is expanded proportionally according to preset expansion parameters to obtain the map to be edited.

[0063] The initial map is an unexpanded, raw map frame, which may be smaller than the final edit size required.

[0064] The default expansion parameters define the expansion factor or the target size after expansion.

[0065] Proportional expansion uses the geometric center or specified anchor point of the map to be edited as a reference, and according to preset expansion parameters (such as expansion factor), it uniformly enlarges all the terrain, assets and spatial structures contained therein while maintaining their relative positions and scale relationships, thereby directly generating a map to be edited that is enlarged in both spatial range and content density.

[0066] Optionally, one way to scale the initial map proportionally according to preset scaling parameters to obtain the map to be edited is through global coordinate transformation: A global scaling transformation is performed on the world coordinate system of the initial map, recalculating all vertex coordinates, object positions, and terrain sampling points proportionally, thereby generating a magnified map visually and logically. For example, multiplying all coordinates of a 1km×1km map by a coefficient of 2 directly yields a 2km×2km map. A tree that was originally 10 meters tall will have its model size and spatial position correspondingly enlarged in the magnified map. Another way to scale the initial map proportionally according to preset scaling parameters to obtain the map to be edited is through data resampling and interpolation: The underlying data of the initial map (such as terrain height maps and texture maps) is resampled and interpolated to generate continuous data with higher resolution and larger coverage, thereby achieving proportional scaling and smooth filling of content. For example, a 512×512 resolution terrain elevation map can be upsampled to 1024×1024 resolution using a bilinear interpolation algorithm, resulting in a new map with a fourfold increase in area and continuously magnified terrain features. This specification does not limit the scope of the embodiments described herein.

[0067] For example, consider a meticulously crafted 1km x 1km map of an ancient town, with precise proportions of streets, houses, and bridges. The design requires scaling this map up to a 4km x 4km main city area. The server reads the initial map and, based on preset scaling parameters, performs a global coordinate transformation, scaling up the coordinates and dimensions of all assets and terrain within the map by a factor of four. Simultaneously, through data resampling and interpolation, the details of the terrain grid and basic textures are smoothly expanded. Through these operations, the server quickly generates a larger-scale map, but with the same overall layout and proportions, based on a high-precision "seed" map. This provides a precise macro-framework for subsequent regional refinement and content filling.

[0068] In the embodiments of this specification, by acquiring an initial map and scaling it proportionally according to preset expansion parameters, a map to be edited is obtained. This allows the verified local design to be enlarged into the macroscopic skeleton of a large-scale scene, ensuring a high degree of consistency and rationality in the basic layout, spatial scale, and proportional relationships of the large-scale map. This provides a unified and reliable coordinate and scale benchmark for subsequent multi-person parallel refinement work, and facilitates the division of the map to be edited. It avoids the proportional imbalance and spatial logic confusion that can easily occur when planning a large-scale layout from scratch, thereby significantly improving the overall production efficiency and spatial design quality of large-scale virtual scenes.

[0069] In one optional embodiment of this specification, constructing corresponding editing hierarchy files for each sub-map includes: Obtain the visual and logical feature correlations between each sub-map; Based on the correlation of visual features and the correlation of logical features, corresponding editing level files are constructed for each sub-map.

[0070] Visual feature correlation is a representation of the similarity of the external visual attributes corresponding to each sub-map. For example, sub-maps Figure 1 Zhizidi Figure 5 All five sub-maps are desert regions. By calculating the cosine similarity or Euclidean distance of their main color histogram, average brightness, texture complexity, and other features, it was found that the visual features of these five sub-maps are highly correlated.

[0071] Logical feature relevance is a representation of the similarity of semantic information corresponding to objective entities in each sub-map. Semantic information can include directional information, topological structure information, distance information, and causal information (such as causal information arising from geographical environment or causal information arising from climate environment). For example, by analyzing the type labels of objects within a sub-map (such as "task release point," "resource gathering point," and "monster lair") and based on a pre-defined semantic association graph, the correlation strength between the sub-maps and the gameplay logic can be calculated.

[0072] Optionally, one way to obtain the visual and logical feature correlations between sub-maps is to perform offline rendering or feature extraction on each sub-map to generate corresponding feature vectors, and then perform pairwise comparison calculations on the server side for all sub-map feature vectors. For example, a pre-trained convolutional neural network can be used to extract the visual feature vectors of each sub-map snapshot, and the visual correlation can be calculated through the vector inner product. Another way to obtain the visual and logical feature correlations between sub-maps is to parse the project metadata or user-annotated tags of each sub-map, and calculate the correlation based on the tag co-occurrence frequency or semantic network. For example, if sub-map A and sub-map B are both labeled with "night scene" and "city block", their logical feature correlation is high. Yet another way to obtain the visual and logical feature correlations between sub-maps is to analyze the editing history data of each sub-map, and determine that sub-maps that are frequently modified by the same user or the same batch of editing tasks have workflow correlation, and use this as a dimension of logical correlation. The embodiments in this specification do not limit this approach.

[0073] Optionally, one implementation of constructing corresponding editing-level files for each sub-map based on visual and logical feature relevance is to create a shared editing-level file for sub-map groups whose visual and / or logical relevance is higher than a preset threshold. For example, a shared editing-level file could be created for all "snowfield terrain" sub-map groups with high visual relevance, used to uniformly manage global visual parameters such as snow surface material and snow particle effects. Another implementation of constructing corresponding editing-level files for each sub-map based on visual and logical feature relevance is to dynamically adjust the structure and granularity of the editing-level files based on the relevance analysis results, constructing a more macroscopic and unified control level for highly relevant sub-maps and a more independent and subdivided professional level for low-relevance sub-maps. For example, a "task logic control layer" could be constructed for multiple sub-maps belonging to the same task chain (high logical relevance), while each sub-map could still independently construct a "terrain decoration layer," "lighting layer," etc. The embodiments in this specification do not limit this approach.

[0074] For example, refer to Figure 2 The server retrieved the "Cultural Tourism City" map to be edited. This map was divided into 16 rectangular sub-maps. The upper left of the map was designated as "Building Cluster," the upper right as "Mountain Range," the lower left as "Forest," and the lower right as "Grassland." Specifically, the "Building Cluster" occupied the two upper left sub-maps, the "Mountain Range" the two upper right, the "Forest" the two lower left, and the "Grassland" the two lower right. Analysis by the backend server revealed that the two sub-maps within the "Building Cluster" area exhibited a high degree of visual correlation (e.g., similar building materials and urban lighting models) and logical correlation (e.g., sharing the same transportation network and virtual character behavior logic). Therefore, the server created a shared "City Core Area Editing Hierarchy File" for these two sub-maps to uniformly manage building lighting parameters, street signs, and public event triggers. Meanwhile, for the two sub-maps in the "forest" area, although their visual features are related (both are covered by vegetation), their logical features are quite different (one is a regular forest, and the other is a forest edge bordering the mountains). The server has built independent "vegetation editing level files" for them to facilitate differentiated and fine-grained editing of their respective vegetation density and tree species composition.

[0075] In the embodiments described in this specification, by intelligently constructing editing hierarchy files based on the visual and logical correlation between sub-maps, it is possible to centrally and uniformly manage highly related content while retaining the editing flexibility of independent content. This improves cross-regional editing consistency while optimizing data organization structure and collaborative workflow efficiency.

[0076] In one optional embodiment of this specification, the editing data is synchronized in parallel to the editing hierarchy files corresponding to each sub-map, including: Based on preset time intervals or synchronization instructions sent from the front end, the edited data is synchronized in parallel to the corresponding edit level files of each sub-map.

[0077] The preset time interval is the period at which the backend server automatically triggers the synchronization operation. For example, it can be configured to automatically perform a full or incremental synchronization every 30 seconds, every 5 minutes, or every hour to balance data real-time performance with system performance overhead.

[0078] Synchronization commands are initiated by the front-end editor to request the upload of locally edited data to the server. For example, a user clicking the "Save and Sync" button on the editor interface, or a "Resynchronize" command automatically sent by the front-end after detecting network recovery.

[0079] For example, the server is configured to perform a scheduled synchronization every minute. Artist A, while editing the "Forest Area" submap, places multiple trees consecutively; these edits are temporarily stored locally on their front-end. One minute later, the timer triggers, and the server proactively retrieves all edit data from A's front-end within this interval and synchronizes it in parallel to the "Vegetation Layer File" of the "Forest Area." Simultaneously, artist B, after completing fine-tuning of a building complex, does not want to wait for the scheduled synchronization and actively clicks the "Publish Now" button in the editor. This action generates a synchronization command sent to the server. Upon receiving this command, the server immediately processes B's edit data and synchronizes it to the corresponding layer file.

[0080] In the embodiments described in this specification, the editing data is synchronized in parallel to the editing level files corresponding to each sub-map according to a preset time interval or a synchronization command sent from the front end. This ensures the regular persistence of editing results and the visibility of team progress, reduces the risk of accidental data loss, and gives users the control to make key modifications take effect immediately. It meets the requirements of high real-time collaboration and version release, and can flexibly adapt to the collaborative editing needs in different scenarios.

[0081] In one optional embodiment of this specification, after obtaining multiple target sub-maps, the method further includes: Based on the regional relationships of multiple target sub-maps, merge the multiple target sub-maps to obtain the target map; Send the target map to the client so that the client can load and render the target map.

[0082] Regional relationships refer to the relative positions, connections, and splicing rules of multiple target sub-maps in the virtual world coordinate system.

[0083] Optionally, based on the regional relationships of multiple target submaps, one approach to merging multiple target submaps is to load the contents of all corresponding editing-level files into the same root scene node according to the order of the submaps' identifiers or coordinate information, and handle data fusion at the seams. For example, smooth interpolation can be performed on the boundary terrain of adjacent submaps. Another approach to merging multiple target submaps based on their regional relationships is to generate a global index file that records the paths and transformation information of each submap file, which is dynamically streamed by the client at runtime. Yet another approach to merging multiple target submaps based on their regional relationships is to bake all the submap data into a larger topographic map and a series of asset sets, generating a single, optimized, complete map file.

[0084] For example, after the server obtains three target sub-maps, "North Forest Area_final," "Central Lake_final," and "South Hills_final," it merges all hierarchical data (terrain, vegetation, buildings, etc.) of the three sub-maps into a new scene project according to a predefined layout (north, central, and south connected in sequence). It then performs density transition processing on the vegetation along the lake edge at the boundary between "North Forest Area" and "Central Lake," generating the complete target map "Forest World_Final." Subsequently, this target map is published to the resource server, and the game client can download, load, and render this complete world.

[0085] In the embodiments described in this specification, multiple target sub-maps are merged based on the regional relationships of multiple target sub-maps to obtain a target map; the target map is then sent to the client so that the client can load and render the target map. This enables the efficient integration of distributed results generated by parallel editing into a final, runnable complete product, realizing a value loop from collaborative production to final application.

[0086] In one optional embodiment of this specification, based on the regional relationships of multiple target sub-maps, multiple target sub-maps are merged to obtain a target map, including: Based on the regional relationships of multiple target sub-maps, adjacent target sub-maps are identified and data conflicts are detected in the contact area of ​​adjacent target sub-maps. If so, based on the conflict type of the data conflict, query from the preset merge rule set whether there is a target merge rule corresponding to the conflict type. The preset merge rule set contains sub-map merge rules configured for data conflicts of different conflict types. By employing target merging rules, map data within conflict areas of adjacent target sub-maps are fused to obtain multiple corrected target sub-maps. Based on the regional relationships of multiple target sub-maps, the corrected target sub-maps are merged to obtain the target map.

[0087] Adjacent target submaps are two or more submaps that are physically connected or logically closely related in the world coordinate system. For example, a large map is divided into four quadrant submaps: East, West, South, and North. The "East Submap" and the "South Submap" share a common boundary and are adjacent target submaps.

[0088] The contact area is a finite-width strip or area near the shared boundary of adjacent target sub-maps. Map data within this area may require special processing during merging to ensure continuity. For example, the contact area can be defined as a region extending 50 meters on each side of the boundary line between two adjacent sub-maps.

[0089] Data conflicts arise when different target sub-maps assign incompatible map data attributes to the same spatial location or logical entity, making direct stitching impossible. For example, at the same coordinate point on the boundary, sub-map A defines this location as "water," while sub-map B defines it as "land," creating a terrain type conflict; or sub-map A places a tree here, while sub-map B places a rock here, creating an object occupancy conflict.

[0090] Optionally, one approach to determining adjacent target sub-maps and detecting data conflicts in their contact areas based on the regional relationships of multiple target sub-maps could be to traverse the bounding boxes of all target sub-maps, calculate their spatial overlap or adjacency, and then, for each pair of adjacent sub-maps, extract the terrain height map and object distribution data within their contact area for differential comparison. For example, the server calculates the rectangular bounding boxes of the "Southern Forest" and "Northern Forest" sub-maps, finds that they are adjacent in the Y-axis direction, and then extracts the terrain height data within a 10-meter-wide strip at the boundary for pixel-by-pixel comparison. If the height difference exceeds a threshold, a terrain continuity conflict is determined. Another approach to determining adjacent target sub-maps and detecting data conflicts in their contact areas based on the regional relationships of multiple target sub-maps could be to rely on a predefined sub-map adjacency table and analyze, based on the editing history submitted by each sub-map, whether there are similarly timed modification operations from different editors near the contact area. For example, according to the project planning document, "Region_1" and "Region_2" are adjacent. The server checked the version logs and found that within the past hour, artist A modified the terrain at the boundary of "Region_1," while artist B modified the terrain near the same coordinates in "Region_2," thus issuing a warning of a potential conflict. Another way to determine adjacent target submaps and detect data conflicts in their contact areas based on the regional relationships of multiple target submaps is to launch a visual pre-check tool before final merging. This tool renders the contact areas of adjacent submaps and automatically marks visually discontinuous or logically inconsistent areas for reviewers to confirm. This specification does not limit the scope of this embodiment.

[0091] Merging rule sets are pre-configured rule bases containing various conflict resolution strategies, with each rule associated with one or more conflict types. For example, a JSON-formatted rule set file might contain entries such as {"conflict_type":"heightmap_discontinuity","rule":"blend_with_gaussian"}.

[0092] Submap merging rules are configuration data units associated with a specific conflict type within a pre-defined set of merging rules, used to guide the resolution of data conflicts of that type. They define the conflict resolution strategy and necessary parameters. For example, a merging rule for a "terrain height discontinuity" conflict might include the strategy identifier "height mixing" and the algorithm parameter "Gaussian filter radius = 5 meters," among other things.

[0093] The target merging rule is one or more directly applicable submap merging rules retrieved from the merging rule set for the specific type of conflict detected in the data. For example, if the detected conflict type is "abrupt vegetation density", the retrieved target merging rule may include the strategy "gradual density" and the parameter "interpolation algorithm = linear".

[0094] Optionally, one way to query whether a target merging rule corresponding to a conflict type exists in a preset merging rule set based on the conflict type of data conflict can be to use the string encoding of the conflict type as the key and perform a direct lookup in the hash table of the rule set. For example, if the conflict type is defined as "Texture_Mismatch", then this string is used as the key to query the rule dictionary. Another way to query whether a target merging rule corresponding to a conflict type exists in a preset merging rule set based on the conflict type of data conflict can be to use a similarity matching algorithm (such as cosine similarity) to find the closest rule in the rule set based on the vector representation of the conflict features. For example, the conflict features (such as the average height difference, object type difference, etc.) can be numericalized and matched with the applicable conditions of each rule. Yet another way to query whether a target merging rule corresponding to a conflict type exists in a preset merging rule set based on the conflict type of data conflict can be to call a rule reasoning engine to dynamically derive or combine applicable rules based on the contextual information of the conflict (such as scene type, art style). The embodiments in this specification do not limit this approach.

[0095] Merging is the process of calculating and adjusting conflict data from different sub-maps within a conflict area according to target merging rules. For example, for terrain conflicts, merging might involve recalculating the height value of each vertex within the conflict area; for object conflicts, it might involve removing one of the objects or adjusting its position.

[0096] The revised target submaps are submaps where conflict data within the contact area has been eliminated.

[0097] Optionally, one way to fuse map data within conflict areas of adjacent target sub-maps using target merging rules is to create a temporary, high-precision fusion buffer in memory, load the conflict data from both sub-maps into it, apply rule-based algorithms to generate new data, and then write it back to the boundary areas of each sub-map. For example, to handle terrain seams, a terrain patch twice the width is created, a smoothing algorithm is applied, and the left half of the resulting data is written back to sub-map A, and the right half is written back to sub-map B. Another way to fuse map data within conflict areas of adjacent target sub-maps using target merging rules is to generate a separate "transition area asset" file. This file contains the fused data and is inserted as a separate layer between the two sub-maps during the final merging. For example, a "River_Transition.asset" file is generated, containing the processed transition model and textures for the river and its banks. Another way to merge map data within conflict areas of adjacent target sub-maps using target merging rules is to directly modify the data of one sub-map in the conflict area to match the data of the other sub-map. Typically, the older or less authoritative version is chosen for modification. This specification does not limit this approach in its embodiments.

[0098] Optionally, based on the regional relationships of multiple target sub-maps, one way to merge and correct the multiple target sub-maps is to arrange all corrected sub-map files according to their world coordinates and generate a global scene description file referencing the world coordinate arrangement, thus achieving a logical merge. Another way to merge and correct the multiple target sub-maps based on their regional relationships is to import the data of all sub-maps into a new, unified map project file for final optimization and baking. For example, an offline merging tool can be launched to merge the asset and terrain data of all sub-maps into a single .uproject file. Yet another way to merge and correct the multiple target sub-maps based on their regional relationships is to utilize the game engine's streaming loading system, configuring each sub-map as a streamable level and setting the correct streaming volume. This specification does not limit the scope of this method in the embodiments.

[0099] For example, when merging two target sub-maps, "Snowy Mountain Area" and "Green Forest Area," the server detected a data conflict in the contact area due to "inconsistent snowline height" (the snowline at the boundary of the Snowy Mountain Area is at an altitude of 1500 meters, while the snowline at the boundary of the Green Forest Area is at an altitude of 1200 meters). Based on the conflict type "Environment_Biome_Transition," the server retrieved the target merging rule from the rule set: "Create a gradient elevation transition zone, where the snowline linearly decreases from 1500 meters to 1200 meters within a 10-kilometer range, and blends snow and grassland textures." Using this rule, the server recalculated the terrain texture blending weights and vegetation distribution within a 5-kilometer-wide area at the boundaries of each of the two sub-maps, generating a corrected sub-map. Finally, the two corrected sub-maps were stitched together by coordinates to generate a complete mountain-forest target map with a natural transition effect.

[0100] In the embodiments described in this specification, by introducing intelligent conflict detection and rule-based fusion processing in the final merging stage, the problem of inconsistent sub-map boundaries that may occur due to parallel editing by multiple people can be solved, which significantly improves the quality and visual coherence of the final synthesized map, reduces a large amount of manual work in repairing seams, and ensures the professional level of large-scale collaborative production results.

[0101] In one optional embodiment of this specification, after querying a preset set of merging rules to determine if a target merging rule corresponding to the conflict type exists based on the conflict type of the data conflict, the method further includes: If not, interrupt the merge and send a prompt message to the front-end corresponding to the adjacent target sub-map so that the front-end can perform editing operations on the adjacent target sub-map.

[0102] Interruption of the merge occurs when a data conflict that cannot be resolved automatically is detected. In this case, the backend server halts the current automatic merging and final merge process and rolls back its state to a safe point before the conflict detection. For example, the server marks the current merge task as "paused" and releases the relevant sub-map data loaded into memory, awaiting manual intervention.

[0103] For example, when merging the "Ancient Ruins Area" and "Dense Forest Area" sub-maps, the server detected a rare type of conflict in the contact area: the "halo effect of the Ruins Magic Barrier" and the "growth range of the Dense Forest Magic Plants" create an irreconcilable rule conflict in physical simulation. The server could not find a solution for this type of "magic field interference" conflict in the preset merging rule set. Therefore, the server immediately interrupted the automatic merging process, generating a prompt message: "A magic field conflict has been detected at the boundary between the 'Ancient Ruins Area' and the 'Dense Forest Area.' The rule base cannot handle it. Please have the relevant editors coordinate adjustments." This message was then sent to the front-end editors responsible for the two sub-maps. Upon receiving the prompt, the two artists or technical artists can be online simultaneously, communicating via voice or sharing views to negotiate and adjust the range or attributes of the magic effects, resolving the conflict at its source, and then re-triggering the merging process.

[0104] In the embodiments described in this specification, by introducing an interruption and feedback mechanism when rule matching fails, it is possible to ensure that the system will not blindly merge data that could lead to data corruption or quality degradation when faced with complex and novel conflict scenarios. This not only guarantees the integrity and accuracy of the final map data, but also provides timely and accurate feedback to the production personnel on complex issues that require professional human judgment and creativity. This achieves effective integration and clear division of responsibilities between automated processes and artificial intelligence, improving the reliability and fault tolerance of the entire production system.

[0105] In one optional embodiment of this specification, after obtaining multiple target sub-maps, the method further includes: Multiple target submaps are sent to the client so that the client can dynamically load and render the target submaps at runtime.

[0106] Dynamic loading is the process by which the client loads the necessary sub-map resources from local storage or network streams in real time based on the player's current location, view direction, and movement trend, while simultaneously unloading resources that have moved away from the area. For example, in an open-world game, when a player character moves towards a city, the client gradually loads the city's building and street models, and gradually unloads the wilderness terrain and vegetation behind them.

[0107] Optionally, one implementation of dynamically loading target submaps can be streaming loading based on spatial grid partitioning. For example, the game world is divided into grids of fixed size, and the client maintains a "loading circle" centered on the player, calculating in real time the grids adjacent to the player's grid and asynchronously loading the target submap data corresponding to these grids. Another implementation of dynamically loading target submaps can be on-demand loading based on view frustum culling and level of detail. For example, the client rendering pipeline calculates the visible area based on the camera's view frustum, prioritizing the loading of visible submaps with high level of detail, while loading lower-detail versions or not loading submaps for distant or invisible areas. Yet another implementation of dynamically loading target submaps can be scripted loading based on predefined paths or scene logic. For example, in story-driven games, submaps related to the next mission scene are loaded in advance according to the mission progress script, achieving a seamless transition. The embodiments in this specification do not limit this approach.

[0108] For example, the server packages and publishes multiple target sub-maps, such as the "Main City Commercial Area," "City Wall Defense Area," and "Outer Forest Area," to the content delivery network. Players launch the game client and enter this world. When the player character is in the "Main City Commercial Area," the client only loads data for that area and a portion of the adjacent "City Wall Defense Area." As the player moves through the city gate to the outskirts, the client predicts their movement trajectory and begins asynchronously loading terrain and vegetation data for the "Outer Forest Area." Simultaneously, it gradually unloads detailed models in the "Main City Commercial Area" that are far from the player, replacing them with low-poly models or completely unloading them. This allows the player to experience a nearly infinite and smooth continuous world with limited hardware resources.

[0109] In the embodiments described in this specification, by sending multiple target sub-maps to the client, the client can dynamically load and render the target sub-maps at runtime. This allows the modular results generated by backend collaborative editing to be directly applied to the end user experience, effectively solving the stringent requirements of large-scale virtual scenes on client memory and computing power.

[0110] Corresponding to the map editing methods described above, Figure 3 The flowchart illustrates another map editing method provided in one embodiment of this specification, applied to any one of multiple front-ends of an editor. The editor also includes a back-end server, and includes the following specific steps: Step 302: Receive the sub-maps distributed to the front end by the backend server, and build corresponding editing level files for each sub-map. The sub-maps are multiple sub-maps obtained by the backend server from the map to be edited, and each editing level file is stored independently on the backend server.

[0111] The meanings of submaps and editing hierarchical files have been explained above and will not be repeated here.

[0112] The method for creating corresponding editing hierarchy files for each sub-map has been explained above and will not be repeated here.

[0113] For example, after an artist launches their front-end editor and logs into the project, the editor automatically receives and downloads the assigned sub-map data file from the back-end server, such as Region A_Gulf.asset. Once downloaded, the editor parses the file and, based on configuration files or user preferences, automatically constructs multiple logical views in the local interface, such as "Terrain Editing Layer," "Vegetation Editing Layer," and "Building Editing Layer." These layered views logically correspond to independent files on the server, such as Region A_Terrain.layer and Region A_Vegetation.layer, but their creation and display management are entirely performed locally on the front end.

[0114] Step 304: Based on the user's editing operations on the sub-map, generate editing data so that the backend server can obtain the editing data of each sub-map in parallel from each frontend, and synchronize the editing data to the corresponding editing level file of each sub-map in parallel until the editing is completed, thus obtaining multiple target sub-maps.

[0115] The meaning of editing data has been explained above and will not be repeated here.

[0116] Optionally, one way to generate edit data based on user editing operations on the submap is to listen to the editor's internal event system and immediately generate an incremental edit data record each time an object attribute changes. For example, when a user drags a model, a record containing the object ID, new location, and timestamp is generated for each unit distance moved. Another way to generate edit data based on user editing operations on the submap is to establish an operation buffer locally, aggregating high-frequency, subtle operations (such as brush drawing) into a logical operation unit before generating edit data. For example, if a user continuously sculpts with a terrain brush for 10 seconds, the front end merges all vertex modification records within those 10 seconds into an edit data package called "Terrain Region Height Field Update". Yet another way to generate edit data based on user editing operations on the submap is to generate a complete edit data snapshot of all changes at the current level only when the user performs an explicit commit action (such as clicking the "Save" button) or switches to another editing level. This specification does not limit this approach.

[0117] For example, in the "Vegetation Editing Layer," an artist drags and drops five oak tree models from the asset library and places them in a specific location. The front-end editor captures these five "create" operations, generates an edit data package containing complete initialization data for the five objects, and places it in a send queue. When send conditions are met (such as the queue size reaching 10 entries or 30 seconds having passed since the last send), the front-end uploads the data package to the back-end server. The server then synchronizes this data to the Zone_A_Foliage.layer file and may notify other front-ends that are monitoring this area.

[0118] In this embodiment, the system receives sub-maps distributed from the backend server to the frontend and constructs corresponding editing hierarchy files for each sub-map. Each sub-map is a collection of sub-maps obtained by the backend server from the map to be edited, and each editing hierarchy file is independently stored on the backend server. Based on user editing operations on the sub-maps, editing data is generated. The backend server then retrieves the editing data of each sub-map from each frontend in parallel and synchronizes it to the corresponding editing hierarchy files for each sub-map until editing is complete, resulting in multiple target sub-maps. This clearly decomposes global collaborative tasks into localized, focused creations. The frontend only needs to process the assigned sub-maps and their corresponding hierarchy views, without needing to be aware of the overall project's scale or the existence of other collaborators, thus significantly reducing the cognitive load and operational complexity for individual editors. Through a standardized editing data generation and submission mechanism, local creative results are efficiently and accurately aggregated to the server, becoming part of the global project data flow. This maximizes the creative freedom and productivity of individual editors while ensuring data consistency and overall project progress.

[0119] Corresponding to the map editing methods described above, Figure 4 This specification illustrates a flowchart of a map rendering method provided in one embodiment, applied to a client, and includes the following specific steps: Step 402: Receive the target map, which is generated according to the method described above.

[0120] Step 404: Load and render the target map.

[0121] For example, the game client downloads the complete target map file generated by the above method from the server. The client loads the target map file, parses all resource information such as terrain data, lightmaps, static model instances, and colliders, and sends it to the graphics rendering pipeline and physics simulation engine, ultimately rendering a unified virtual world on the screen for players to explore or review.

[0122] In the embodiments described in this specification, by receiving, loading and rendering the target map, the final, integrated data results generated by collaborative editing can be directly converted into visual content that end users can experience, thus completing the value transfer from production data to consumer products. This is the final link in the entire technical solution serving practical applications.

[0123] Corresponding to the map editing methods described above, Figure 5 This specification illustrates a flowchart of another map rendering method provided in one embodiment, applied to a client, and includes the following specific steps: Step 502: Receive multiple target sub-maps, wherein the target sub-maps are generated according to the method described above.

[0124] Step 504: Dynamically load and render the target sub-map.

[0125] For example, during client runtime, the streaming loading system determines that the player is about to enter the boundary between "Area 1" and "Area 2" based on the player character's real-time coordinates. Therefore, the system asynchronously loads the high-precision model of "Area 2" and the low-precision model of "Area 3" in a background thread, while simultaneously unloading the "Area 1" resources behind the player. The rendering engine then renders a continuous world scene based on the currently loaded resources.

[0126] In the embodiments described in this specification, by receiving multiple target sub-maps, dynamically loading and rendering them, the performance bottlenecks of terminal device memory and input / output (IO) in large-scale scenes can be effectively solved. By combining the physical organization of map data (sub-maps) with efficient runtime scheduling, the modular map results produced based on this method can be utilized by a high-performance rendering engine, ultimately providing users with a vast and smooth virtual environment experience far exceeding the device's single-load capacity. This maximizes the value of modular production results on the delivery side.

[0127] It should be noted that the map editing methods provided in this manual can be applied to various industries or scenarios, including virtual reality processing software, home entertainment product software, digital cultural product production software, digital cultural creative software, digital cultural creative design, education, news, cultural content industry software, digital publishing software, digital music development and production, and digital mobile multimedia development and production. In some cases, they can also be applied to fields such as animation and game production engine software and development systems, game and animation software, animation and game digital content services, digital film and television development and production, and digital performance development and production.

[0128] Figure 6A structural block diagram of a computing device according to one embodiment of this specification is shown. The components of the computing device 600 include, but are not limited to, a memory 610 and a processor 620. The processor 620 is connected to the memory 610 via a bus 630, and a database 650 is used to store data.

[0129] The computing device 600 also includes an access device 640, which enables the computing device 600 to communicate via one or more networks 660. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 640 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Controller (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0130] In one embodiment of this specification, the above-described components of the computing device 600 and Figure 6 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 6 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0131] The computing device 600 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 600 can also be a mobile or stationary server.

[0132] The memory 610 is used to store computer programs / instructions, and the processor 620 is used to execute the following computer programs / instructions, which, when executed by the processor, implement the steps of the above-mentioned map editing method or map rendering method.

[0133] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device belongs to the same concept as the technical solutions of the map editing method and map rendering method described above. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solutions of the map editing method or map rendering method described above.

[0134] An embodiment of this specification also provides a computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the map editing method or map rendering method described above.

[0135] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium belongs to the same concept as the technical solutions of the map editing method and map rendering method described above. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solutions of the map editing method or map rendering method described above.

[0136] An embodiment of this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described map editing method or map rendering method.

[0137] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product belongs to the same concept as the technical solutions of the map editing method and map rendering method described above. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solutions of the map editing method or map rendering method described above.

[0138] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0139] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0140] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0141] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0142] The preferred embodiments disclosed above are merely illustrative of this specification. The optional 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 embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A map editing method characterized by comprising: The application is applied to a backend server of an editor, and the editor further comprises a plurality of front ends, comprising: a plurality of sub-maps of a to-be-edited map are acquired, and a corresponding editing level file is constructed for each of the sub-maps, wherein each of the editing level files is independently saved on the backend server; the plurality of sub-maps are distributed in parallel to each of the front ends, so that a user performs an editing operation on the sub-maps to generate editing data; editing data of each of the sub-maps is acquired in parallel from each of the front ends; the editing data is synchronously written into the corresponding editing level file of each of the sub-maps in parallel until a plurality of target sub-maps are obtained in the case of editing completion.

2. The method of claim 1, wherein, the plurality of sub-maps of the to-be-edited map are acquired, comprising: a to-be-edited map is acquired; a preset division rule is used to divide the to-be-edited map into a plurality of sub-maps, wherein the division rule comprises at least one of a rule area division of a preset size and an irregular area division of a custom size.

3. The method of claim 2, wherein, the to-be-edited map is acquired, comprising: an initial map is acquired; the initial map is proportionally expanded according to a preset expansion parameter to obtain the to-be-edited map.

4. The method of claim 1, wherein, the corresponding editing level file is constructed for each of the sub-maps, comprising: visual feature correlation and logical feature correlation between each of the sub-maps are acquired; the corresponding editing level file is constructed for each of the sub-maps according to the visual feature correlation and the logical feature correlation.

5. The method of claim 1, wherein, the editing data is synchronously written into the corresponding editing level file of each of the sub-maps in parallel, comprising: the editing data is synchronously written into the corresponding editing level file of each of the sub-maps in parallel according to a preset time interval or a synchronization instruction sent by the front end.

6. The method according to any one of claims 1 to 5, characterized in that, after the plurality of target sub-maps are obtained, further comprising: the plurality of target sub-maps are merged based on a region relationship of the plurality of target sub-maps to obtain a target map; the target map is sent to a client, so that the client loads and renders the target map.

7. The method of claim 6, wherein, the plurality of target sub-maps are merged based on the region relationship of the plurality of target sub-maps to obtain a target map, comprising: adjacent target sub-maps are determined based on the region relationship of the plurality of target sub-maps, and it is detected whether there is a data conflict in a contact area of the adjacent target sub-maps; if yes, whether there is a target merging rule corresponding to a conflict type of the data conflict is queried from a preset merging rule set based on the conflict type of the data conflict, wherein the preset merging rule set contains a sub-map merging rule configured for a data conflict of different conflict types; map data in a conflict area of the adjacent target sub-maps is fused and processed using the target merging rule to obtain the plurality of target sub-maps after correction; the plurality of target sub-maps after correction are merged based on the region relationship of the plurality of target sub-maps to obtain a target map.

8. The method of claim 7, wherein, after the if yes, whether there is a target merging rule corresponding to a conflict type of the data conflict is queried from a preset merging rule set based on the conflict type of the data conflict, further comprising: If not, interrupt the merging and send a prompt message to the front end corresponding to the adjacent target sub-map to make the front end perform editing operation on the adjacent target sub-map.

9. The method according to any one of claims 1 to 5, characterized in that, After the plurality of target sub-maps are obtained, further comprising: sending the plurality of target sub-maps to the client to make the client dynamically load the target sub-maps and render at runtime.

10. A map editing method characterized by comprising: applicable to any one of a plurality of front ends of an editor, the editor further comprising a back-end server, comprising: receiving sub-maps distributed by the back-end server to the front end, and constructing a corresponding editing hierarchy file for each of the sub-maps, wherein the sub-maps are a plurality of sub-maps of a map to be edited obtained by the back-end server, and each of the editing hierarchy files is independently saved on the back-end server; generating editing data based on user editing operations on the sub-maps, so that the back-end server obtains editing data of each of the sub-maps from each of the front ends in parallel, and synchronizes the editing data to the editing hierarchy file corresponding to each of the sub-maps in parallel until the editing is completed, to obtain a plurality of target sub-maps.

11. A method of map rendering, characterized by, applicable to a client, comprising: receiving a target map, wherein the target map is generated according to the method of any one of claims 6-8; loading and rendering the target map.

12. A map rendering method, characterized by, applicable to a client, comprising: receiving a plurality of target sub-maps, wherein the target sub-maps are generated according to the method of claim 9; dynamically loading the target sub-maps and rendering.

13. A computing device, comprising: comprising: a memory and a processor; the memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which realize the steps of the method of any one of claims 1-12 when executed by the processor.

14. A computer-readable storage medium, characterized in that, having stored computer programs / instructions, which realize the steps of the method of any one of claims 1-12 when executed by the processor.

15. A computer program product, characterised in that, comprising computer programs / instructions, which realize the steps of the method of any one of claims 1-12 when executed by the processor.

Images