A map editing method, a map rendering method, and a computing device

Abstract

The embodiment of the present specification provides a map editing method, a map rendering method and a computing device, wherein the map editing method is applied to a backend server of an editor, and the editor further comprises 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 to each front end in parallel, so that a user generates editing data by performing an editing operation on the sub-maps; obtaining the editing data of each sub-map from each front end in parallel; and synchronizing the editing data to the editing level file corresponding to each sub-map in parallel, until the editing is completed, to obtain a plurality of target sub-maps. The production efficiency of the map can be improved, and the method can be widely applied in the field of digital cultural product production software and the like.

Description

Technical Field

[0001] The embodiments in this 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 Technology

[0002] With the development of digital cultural industries such as virtual reality and digital twins, maps in virtual scenes are gradually increasing. Therefore, higher demands are placed on the efficiency of map production during the development of virtual scenes.

[0003] Current map creation methods primarily rely on scene editors, dividing the virtual world into multiple independent maps, with artists and other developers each responsible for creating one or more of these maps. However, as projects grow larger, the size and content density of individual maps increase, significantly slowing down loading, manipulating, and saving within the editor, severely impacting the smoothness of the creation process. Furthermore, this method cannot support multiple users editing the same independent map simultaneously. Forcing collaborative editing can lead to version conflicts due to asynchronous modifications to the same scene resources by different developers, causing severe data corruption and management costs, thus becoming a bottleneck to production efficiency.

[0004] Therefore, existing map-making methods are inefficient. Summary of the Invention

[0005] In view of this, embodiments of this specification provide a map editing method. One or more embodiments of this specification also relate to a map rendering method, a computing device, a computer-readable storage medium, and a computer program product, to address the technical deficiencies existing in the prior art.

[0006] According to a first aspect of the embodiments of this specification, a map editing method is provided, applied to a backend server of an editor, the editor further including multiple frontends, including: Obtain multiple sub-maps of the map to be edited, and construct corresponding editing level files for each sub-map. Each editing level file is stored independently on the backend server. Multiple sub-maps are distributed in parallel to each front-end, enabling users to perform editing operations on the sub-maps and generate edit data. Editing data for each sub-map is obtained in parallel from each front-end. The edited data is synchronized in parallel to the corresponding editing level files of each sub-map until the editing is completed, resulting in multiple target sub-maps.

[0007] According to a second aspect of the embodiments of this 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 back-end server, including: Receive sub-maps distributed from the backend server to the frontend, 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. Based on the user's editing operations on the sub-map, editing data is generated 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.

[0008] According to a third aspect of the embodiments of this specification, a map rendering method is provided, applied to a client, comprising: Receive the target map, which is generated according to the map editing method described above; Load and render the target map.

[0009] According to a fourth aspect of the embodiments of this specification, another map rendering method is provided, applied to a client, including: Receive multiple target sub-maps, wherein the target sub-maps are generated according to the map editing method described above; Dynamically load and render the target sub-map.

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

[0011] According to a sixth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0012] According to a seventh aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[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] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0016] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0017] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0018] Furthermore, 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 used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0019] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0020] Editor: An editor is a software tool used to create, modify, and manage virtual scene content (such as terrain, models, lighting, scripts, etc.). Examples include the Unity editor and the Unreal Engine editor.

[0021] Editing Level: An editing level is a logical data unit that divides specific types of objects or assets in a virtual scene to facilitate collaborative editing, version management, and data synchronization. Its content is persistently stored as an independent editing level file. For example, an editing level named "Lights" will have a corresponding "Lights Editing Level File" that centrally stores the position, color, intensity, and other parameters of all lights in that area, and is physically independent of "Terrain Editing Level Files," "Vegetation Editing Level Files," etc.

[0022] Editing operations: Editing operations are actions initiated by the user in the editor to change the state of an object in the virtual scene. Editing operations can include actions such as creation, modification, and deletion, as well as changes to their related parameters. For example, moving the position of a model, rotating the direction of a light, or modifying the script parameters of a trigger.

[0023] Frontend: The frontend is a client software component that runs on the user's local computer or workstation, providing a graphical user interface and responsible for direct interaction with the user for map editing. It bears the main responsibility for content creation, including but not limited to loading and displaying scenes, invoking editing tools, placing and modifying assets, and locally saving and submitting editing operations. Examples include scene editing views commonly used in game development integrated development environments such as Unity Editor and Unreal Editor, or specialized editing tools customized for specific projects, focusing on terrain sculpting or vegetation distribution.

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

[0025] This specification provides a map editing method, and 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 in the following embodiments.

[0026] See Figure 1 , Figure 1 The flowchart illustrates a map editing method according to an embodiment of this specification. The map editing method is applied to the backend server of an editor, which also includes multiple frontends, and includes the following specific steps: Step 102: Obtain multiple sub-maps of the map to be edited, and build corresponding editing level files for each sub-map. Each editing level file is stored independently on the backend server.

[0027] The embodiments in this specification apply to digital cultural product scenarios that require editing large-scale maps, such as digital twins, virtual reality, metaverses, and interactive media. For example, in a large-scale open-world digital cultural tourism project, it is necessary to construct a virtual scenic area covering hundreds of square kilometers, which needs to include mountains, rivers, deserts, and towns.

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

[0029] A submap is a local scene data unit that is relatively independent in physical space or logical function, obtained by dividing the map to be edited according to specific rules. For example, a large world map can be divided into 100 blocks using a 10km×10km grid, and each block is a submap.

[0030] Optionally, one way to obtain multiple submaps of the map to be edited is to directly load pre-divided and stored submap data from a pre-configured database. Another way is to dynamically call a partitioning algorithm to generate them in real time based on the number of currently online collaborative front-ends. For example, if the server detects that there are 8 front-ends online, it dynamically divides the map into 8 work areas with approximately the same area. Yet another way is to receive a set of submaps that the user manually uploads or specifies through a management interface. This specification does not limit this approach in the embodiments.

[0031] An edit hierarchy file is a data file used to store and manage a specific type of editing operation and its results within a particular submap. Its content is logically linked to the specific edit hierarchy. For example, a light edit hierarchy file might specifically store the type, location, color, and intensity information of all light objects in that area.

[0032] Each editable layer file is saved independently and has its own storage path and version control information in the server's file system. Modifications and updates to these layers do not affect other editable layers. For example, changes to the terrain layer will only be committed to the terrain layer file and will not trigger version changes to 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 in that, The backend server is used for the editor, which also includes multiple frontends, including: Multiple sub-maps of the map to be edited are obtained, and corresponding editing level files are constructed for each sub-map. Each editing level file is independently stored on the backend server. The editing level file is a data file used to store and manage specific types of editing operations in a specific sub-map and the results of the specific types of editing operations. The multiple sub-maps are distributed in parallel to each of the front-ends, so that users can perform editing operations on the sub-maps to generate edit data; Editing data for each of the sub-maps is obtained in parallel from each of the aforementioned front-ends; The edited data is synchronized in parallel to the edit level files corresponding to each sub-map until the editing is completed, thus obtaining multiple target sub-maps.

2. The method according to claim 1, characterized in that, The process of 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 a preset division rule to obtain multiple sub-maps of the map to be edited. The division rule includes at least one of a preset size regular region division and a custom size irregular region division.

3. The method according to claim 2, characterized in that, The process of 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.

4. The method according to claim 1, characterized in that, The construction of corresponding editing hierarchy files for each of the sub-maps includes: Obtain the visual feature correlation and logical feature correlation among the sub-maps; Based on the visual feature correlation and logical feature correlation, construct corresponding editing level files for each of the sub-maps.

5. The method according to claim 1, characterized in that, The step of synchronizing the edited data in parallel to the edit-level files corresponding to each of the sub-maps includes: According to a preset time interval or a synchronization command sent by the front end, the edited data is synchronized in parallel to the edit level files corresponding to each of the sub-maps.

6. The method according to any one of claims 1-5, characterized in that, After obtaining multiple target sub-maps, the process also includes: Based on the regional relationships of the multiple target sub-maps, the multiple target sub-maps are merged to obtain the target map; The target map is sent to the client so that the client can load and render the target map.

7. The method according to claim 6, characterized in that, The process of merging the multiple target sub-maps based on their regional relationships to obtain a target map includes: Based on the regional relationships of the multiple target sub-maps, adjacent target sub-maps are determined and data conflicts are detected in the contact area of ​​the adjacent target sub-maps. If so, based on the conflict type of the data conflict, query from the preset merging rule set whether there is a target merging rule corresponding to the conflict type, wherein the preset merging rule set includes sub-map merging rules configured for data conflicts of different conflict types; Using the target merging rule, the map data within the conflict area of ​​the adjacent target sub-maps are fused to obtain the corrected multiple target sub-maps; Based on the regional relationships of the multiple target sub-maps, the corrected multiple target sub-maps are merged to obtain the target map.

8. The method according to claim 7, characterized in that, If so, after querying the preset merging rule set to see 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, the merging is interrupted, and a prompt message is sent 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.

9. The method according to any one of claims 1-5, characterized in that, After obtaining multiple target sub-maps, the process also includes: The multiple target sub-maps are sent to the client so that the client can dynamically load and render the target sub-maps at runtime.

10. A map editing method, characterized in that, The editor is applied to any one of multiple front-ends, and the editor also includes a back-end server, including: The system receives sub-maps distributed from the backend server to the frontend and constructs 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. Each editing level file is stored independently on the backend server. The editing level file is a data file used to store and manage specific types of editing operations in a specific sub-map and the results of the specific types of editing operations. Based on the user's editing operations on the sub-map, editing data is generated so that the backend server can obtain the editing data of each sub-map in parallel from each of the frontends, and synchronize the editing data in parallel to the editing level file corresponding to each sub-map until the editing is completed, thus obtaining multiple target sub-maps.

11. A map rendering method, characterized in that, Applied to the client side, including: Receive a target map, wherein the target map is generated by the method according to any one of claims 6-8; Load and render the target map.

12. A map rendering method, characterized in that, Applied to the client side, including: Receive multiple target sub-maps, wherein the target sub-maps are generated according to the method of claim 9; The target sub-map is dynamically loaded and rendered.

13. A computing device, characterized in that, include: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the method according to any one of claims 1 to 12.

14. A computer-readable storage medium, characterized in that, It stores a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 12.

15. A computer program product, characterized in that, Includes a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 12.

Images