A virtual scene construction method, system, device and storage medium

Abstract

This invention provides a method, system, device, and storage medium for constructing a virtual scene. The method includes: acquiring initial data, which includes scene data and at least one differential patch. The scene data defines a set of entities in the virtual scene in a declarative format independent of the engine. The differential patch includes atomic operations on the virtual scene. The method further includes: applying the atomic operations in the differential patch to the scene data to generate a scene state graph; and, based on preset mapping rules, instantiating the entities in the scene state graph into corresponding runtime objects in the target engine to construct the virtual scene. The same scene data can be used as input for different engines without modification, eliminating the repetitive work of constructing scene data for each engine. By applying the atomic operations in the differential patch to the scene data to generate the scene state graph, precise and incremental updates of the scene are achieved without replacing the entire scene file for minor changes, thus improving the efficiency of scene updates.

Description

Technical Field

[0001] This invention belongs to the field of game development technology, and in particular relates to a method, system, device and storage medium for constructing virtual scenes. Background Technology

[0002] One of the core challenges in developing modern video games, digital twins, and metaverse applications lies in efficiently and scalably creating and managing large and complex virtual environments within games.

[0003] In existing technologies, the scene data of virtual scenes is usually deeply bound to the proprietary format and object model of a specific game engine, resulting in high costs for cross-engine reuse, migration and adaptation. Furthermore, the workflow in existing technologies usually relies on binary file locking mechanisms or coarse-grained version control, which can easily lead to workflow blockage when the team is collaboratively editing complex scenes, making collaborative editing difficult and version management inefficient. Summary of the Invention

[0004] In view of this, the present invention provides a virtual scene construction method, system, device and storage medium to solve the technical problems of cross-platform adaptation difficulties caused by the deep binding of virtual scene data with specific game engines, as well as the low efficiency of version merging and conflict handling when multiple people edit scenes in parallel.

[0005] A first aspect of the present invention provides a method for constructing a virtual scene, comprising:

[0006] Acquire initial data, which includes scene data and at least one differential patch. The scene data defines a set of entities in the virtual scene in an engine-independent declarative format. The differential patch includes atomic operations on the virtual scene.

[0007] The atomic operations in the differential patch are applied to the scene data to generate a scene state graph;

[0008] Based on preset mapping rules, the entities in the scene state diagram are instantiated into corresponding runtime objects in the target engine to construct a virtual scene.

[0009] A second aspect of the present invention provides a virtual scene construction system, comprising:

[0010] The core processing layer is used to acquire initial data, which includes scene data and at least one differential patch. The scene data defines a set of entities in the virtual scene in an engine-independent declarative format, and the differential patch includes atomic operations on the virtual scene.

[0011] The core processing layer is also used to apply the atomic operations in the differential patch to the scene data to generate a scene state diagram;

[0012] The engine access layer is used to instantiate the entities in the scene state diagram into corresponding runtime objects in the target engine based on preset mapping rules, so as to construct a virtual scene.

[0013] A third aspect of the present invention provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the virtual scene construction method as described in the first aspect above.

[0014] A fourth aspect of the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the virtual scene construction method as described in the first aspect above.

[0015] Compared with the prior art, the embodiments of the present invention have the following beneficial effects:

[0016] This invention uses a declarative format independent of the engine to describe the scene, allowing the same scene data to be used as input for different engines without modification, eliminating the repetitive work of manually rewriting or transforming scene data for each engine. By applying atomic operations in differential patches to the scene data to generate a scene state graph, precise and incremental updates to the scene are achieved, avoiding the need to replace the entire large scene file for minor changes. Finally, entities in the state graph are automatically instantiated into runtime objects in the engine according to preset mapping rules, automating engine object configuration and improving the efficiency of scene updates. Attached Figure Description

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

[0018] Figure 1 This is a schematic diagram of a virtual scene construction method provided in an embodiment of the present invention;

[0019] Figure 2 This is a flowchart illustrating the application of differential patches to scene data, as provided in an embodiment of the present invention.

[0020] Figure 3 This is a schematic diagram illustrating a mapping process from semantic components to specific engine components provided by an embodiment of the present invention;

[0021] Figure 4This is a schematic diagram of a virtual scene construction system provided in an embodiment of the present invention;

[0022] Figure 5 This is a schematic diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0023] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of the present invention. However, those skilled in the art will understand that the present application may be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, circuits, and methods have been omitted to avoid unnecessary detail that could obscure the description of the present application.

[0024] The technical solution of the present invention will be illustrated below through specific embodiments.

[0025] Reference Figure 1 The diagram illustrates a virtual scene construction method according to an embodiment of the present invention. This method can be executed by a virtual scene construction system, which can be implemented in hardware and / or software. The virtual scene construction system can be configured in an electronic device. Figure 1 As shown, the method may specifically include the following steps:

[0026] S101. Obtain initial data, which includes scene data and at least one differential patch. The scene data defines a set of entities in the virtual scene in an engine-independent declarative format. The differential patch includes atomic operations on the virtual scene.

[0027] Scene data describes the collection of all entities in the virtual scene and is a complete baseline state (snapshot) of the scene at a certain moment.

[0028] The scene data uses a declarative format, which only describes "what is needed" (such as a point light source, its color, and intensity) without specifying "how to implement it" (it does not involve Unity's Light component or Unreal's PointLightComponent class). Furthermore, the declarative format is not dependent on any specific engine; instead, it uses universal semantics to describe the scene. Different target engines or tools can parse this JSON and map the semantics to their own objects according to their own rules. The use of an intermediate language essentially solves compatibility issues by standardizing scene data, freeing game development from the constraints of specific engines.

[0029] Optionally, the declarative format is a user-readable format, such as JSON, which facilitates developer debugging, tool processing, and version control system tracking.

[0030] Specifically, scene data can come from manually edited content by users (such as game designers), procedurally generated content (generated through specific tools or AI), or user-generated content.

[0031] For example, scene descriptions: a light source includes not only color and intensity, but also behaviors such as whether it flickers or is a flashlight. A non-player character includes not only a model and animation, but also an AI behavior tree, dialogue options, etc.

[0032] The scenario description described above can then be used for automated scenario generation, automated testing, and game logic generation. During automated scenario generation, AI can generate a scenario with complete functional objects based on the game design requirements. During automated testing, testing tools can understand the interactive elements in the scenario and automatically perform interaction tests. When generating game logic, game logic code or scripts are automatically generated based on narrative and interactive components, ultimately yielding scenario data.

[0033] An entity is any independent, identifiable object in a scene. Each entity has a unique ID and multiple semantic components. Semantic components are data blocks attached to an entity that describe its specific attributes or functions. An entity is a combination of multiple semantic components; when expanding game content, new component types can be added to support new features.

[0034] For semantic components, the following are examples:

[0035] Transform component: Defines the spatial position, rotation, and scaling of an entity in a virtual scene.

[0036] Geometry: Refer to a model file (such as .glb, .fbx) or define a procedural geometry (such as a sphere, cube).

[0037] Material component: Describes surface appearance properties, following the PBR (Physically-Based Rendering) standard, such as albedo, roughness, metallic, and emissive.

[0038] Physics component: Defines physical behaviors such as is_static (whether it is static), mass (mass), collision (collision body shape, such as box, sphere, mesh), friction (friction force), and bounce (elasticity).

[0039] The Lighting component defines light source properties such as type (point, spot, area), color, intensity, range, and cast_shadow (whether to cast a shadow).

[0040] Interaction component: Defines how to interact with players or other entities, such as type (pickup, button, door), actions (list of actionable actions), and state (current state).

[0041] Narrative component: contains narrative elements such as dialogue_id (dialogue ID), quest_marker (quest marker), and lore_text (background story text).

[0042] Differential patches are a series of discrete modification instructions applied to the baseline. Differential patches consist of atomic operations, which represent adding, deleting, or modifying a specific attribute. This design allows each modification to be independently recorded, transmitted, applied, or rolled back, forming the cornerstone of version control and multi-user concurrent editing.

[0043] A differential patch file typically contains metadata and a series of atomic operations. For example, a differential patch includes:

[0044] Op: Operation type, including add, update (or replace), and remove.

[0045] Path: A JSONPointer (RFC6901) or a custom path expression used to precisely locate the entity or property to be operated on. For example, / entities / - means appending to the end of the entities array, and / entities / id=road_main_01 / material is a custom, more robust path that locates by entity ID, avoiding problems caused by changes in array order.

[0046] Value: The value required for add and update operations.

[0047] S102. Apply the atomic operations in the differential patch to the scene data to generate a scene state graph.

[0048] Applying atomic operations to scene data is the process of integrating all discrete modification intentions into a unified scene state graph. Starting with the established state of the scene data, it sequentially parses the atomic operations in each differential patch, precisely modifying the corresponding parts of the scene data, and gradually transforming the scene data into a scene state graph.

[0049] After applying all differential patches, the result is a state-of-the-art, complete, and consistent in-memory representation of the scene, namely the scene state graph. Specifically, the scene state graph is built in memory in the form of a scene graph or a list of entities.

[0050] The scene state diagram is no longer the raw declarative format (JSON) text, but a fully processed and optimized data structure built in memory. Scene state diagrams typically possess the following characteristics:

[0051] Completeness: All final attributes of all entities have been parsed and calculated, such as merging the default values ​​of the prototype with the overridden values ​​of the instance.

[0052] Structured: The parent-child relationships and reference relationships between entities have been established as a graph or tree structure that is easy for the program to traverse.

[0053] Queryability: Spatial indexes (such as quadtrees) or categorical indexes may have been built to support efficient queries such as "find nearby objects".

[0054] Consistency: It is the only correct state after all valid patches have been applied, serving as the single source of truth for subsequent processes.

[0055] Differential patches typically consist of a sequence of atomic operations (usually a JSON array), each operation explicitly targeting one or a group of entities. The main operation types are as follows:

[0056] 1. Add Entity: Introduce a brand new entity into the virtual scene.

[0057] 2. Remove Entity: Delete an existing entity from the virtual scene. The specific entity to be deleted is located by its entity ID.

[0058] 3. Update / Modify Entity: Used to change the existing attributes of an entity, specifically by updating a specific component of the entity or updating the entire entity (equivalent to replacing it).

[0059] Differential patches describe only atomic modifications, so their memory footprint is extremely small. By applying differential patches, when updating a scene, it is not necessary to transfer the entire large scene file, but only the extremely small differential patch.

[0060] There can be multiple differential patches, each from different users. In one example, these users could be art designers, scene developers, etc. Each user's modifications to the virtual scene can be converted into a differential patch. Furthermore, the differential patches from different users are independent and can be submitted independently. This provides a clear input and framework for handling multi-user editing conflicts (when multiple patches modify the same place).

[0061] Optionally, let the scene data be a JSON document S, and a differential patch P be represented as a column [op1, op2, ..., op...]. n The differential patch is applied to the scene data using the function Apply(S, P).

[0062] Snew = Apply(S, P) = op n (op n-1 (…op2(op1) ));

[0063] As can be seen, in a differential patch, each atomic operation is also arranged in a certain order. When the differential patch is applied, it is executed according to the order of the atomic operations in the differential patch. Subsequent atomic operations are based on the data after the application of the preceding atomic operations.

[0064] Merging differential patches involves applying the atomic modifications contained in one or more differential patches sequentially to the scene state established from the base scene description data, in a predetermined order, ultimately generating a unified, updated scene state graph. For multiple differential patches (P1, P2…Pn), the merging process is also sequential.

[0065] S103. Based on preset mapping rules, the entities in the scene state diagram are instantiated into corresponding runtime objects in the target engine to construct a virtual scene.

[0066] A mapping rule (which can be multiple) is a configurable rule that is independent of scene content and target engine. It defines the transformation rules from general semantic tags (such as "render") to specific engine components (such as Unity's MeshRenderer). Through mapping rules, all scene state graphs can be converted into runtime objects in the target engine, thereby constructing a virtual scene.

[0067] It should be noted that in this application, when "engine" is mentioned alone, it refers broadly to various game engines, rendering engines, or virtual scene runtime environments, while the target engine specifically refers to a particular engine ultimately used to instantiate and run the virtual scene. The relationship between the two is as follows: the target engine is a specific instance of an engine; the entire process first describes the scene in an engine-independent format, and finally executes it in the selected target engine.

[0068] This invention uses a declarative format independent of the engine to describe the scene, allowing the same scene data to be used as input for different engines without modification, eliminating the repetitive work of manually rewriting or transforming scene data for each engine. By applying atomic operations in differential patches to the scene data to generate a scene state graph, precise and incremental updates to the scene are achieved, avoiding the need to replace the entire large scene file for minor changes. Finally, entities in the state graph are automatically instantiated into runtime objects in the engine according to preset mapping rules, automating engine object configuration and improving the efficiency of scene updates.

[0069] In an optional embodiment, atomic operations from the differential patch are applied to the scene data to generate a scene state graph, including:

[0070] When there are multiple differential patches, obtain the execution order of the differential patches; apply the atomic operations in the differential patches to the scene data according to the execution order to generate a scene state diagram.

[0071] Applying differential patches to scene data is concretized as a controlled, ordered state transition process. The merging operation is primarily based on data dependencies and intent conflicts and adjudication dependencies:

[0072] Data dependency example: User A submitted Patch_A (create entity door 1), and User B submitted Patch_B (set target of entity switch 1 to door 1) based on a scenario containing entity door 1. The logical correctness of Patch_B depends on the execution result of Patch_A. Patch_B must be applied in the order of A first, then B; otherwise, Patch_B will fail or generate an error because door 1 cannot be found.

[0073] Example of conflicting intents and resolution: User A submits Patch_A (changing the color of light 1 to red), and User B submits Patch_B (changing the color of light 1 to blue). Both modify the same attribute, resulting in a direct conflict of intents. In this case, the execution order itself becomes a conflict resolution strategy. The system can decide which result to adopt based on the order (such as the submission timestamp), such as prioritizing the later submission, thereby automatically resolving the conflict or at least deterministically producing a result for subsequent processing.

[0074] This embodiment demonstrates that the generation of a scene state diagram is not a static function calculation, but rather a deterministic state machine evolution process with an initial scene as the state and an ordered sequence of patches as input. Furthermore, by enforcing a defined order, it ensures that the same set of inputs (the same base scene and the same patch set) can be merged at any time and in any system, producing completely consistent outputs, thus providing a foundation for reliable collaboration, version control, and data synchronization.

[0075] In an optional embodiment, the differential patch includes atomic operations and entity localization paths. The atomic operations in the differential patch are applied to scene data to generate a scene state graph, including:

[0076] For each differential patch, locate the target level within an entity in the scene data based on the entity location path; modify the attributes of the target level based on the atomic operations of the differential patch; after the differential patch traversal is completed, generate a scene state graph based on the updated entity and the relationships between entities in the scene data.

[0077] An entity location path is a convenient locator that can uniquely identify any node in a scene data tree structure, for example:

[0078] / entities / [id=door_01] : Locates the entire entity;

[0079] / entities / [id=door_01] / components / transform / position: Position property to locate the transform component)

[0080] / entities / [id=door_01] / components / health / current_value: Locates the current value of the health component.

[0081] In existing technologies, coarse-grained operations are performed only through entity IDs. However, the entity location path design supports extremely fine-grained modifications to nested attributes, array elements, and specific components. This makes the patch size smaller, the intent clearer, avoids directly locking the entire entity, and is more conducive to achieving efficient collaboration. For example, if user A modifies component A in entity 1, user B can modify component B in entity 1.

[0082] First, the system needs to maintain a queryable scene data structure. By merging the path through the merging engine, it navigates within the scene data representation in memory and precisely locates the data nodes that need to be modified.

[0083] Modifying attributes involves performing specific actions based on the atomic operation type, including:

[0084] add: Inserts new data at the target level (such as an array).

[0085] update / replace: Replace the current value of the target node with the new value.

[0086] remove: Deletes the target node, such as deleting a component.

[0087] This process minimizes changes; the system does not need to understand or parse the entire entity, but only needs to update the specific data block pointed to by the path in place, which is extremely efficient.

[0088] The system only constructs a new scene state graph after processing all atomic operations for all differential patches. This ensures that the construction process is based on fully updated, consistent, and up-to-date scene data, rather than intermediate states.

[0089] The generation of the scene state diagram involves a structured transformation and optimization of the updated scene data, which includes the following parts:

[0090] Updated entities: the final set of all entities that have been modified by the patch and those that have not been modified.

[0091] Relationships between entities: These relationships (such as parent-child hierarchy, spatial references) also originate from the scenario data and may be modified by patches during the merging process (such as changing the parent field of an entity). When generating the scenario state graph, the system will rebuild an efficient index and graph structure based on this latest relationship data.

[0092] In an optional embodiment, the virtual scene construction method further includes:

[0093] Determine whether the differential patches are compatible; if not, generate a conflict report based on the identifier of the incompatible differential patch and the preset conflict resolution strategy and provide it to the user; if yes, execute the step of applying the atomic operations in the differential patch to the scene data to generate a scene state diagram.

[0094] This embodiment adds a decision element to the differential merging process. It clarifies that the system must perform a feasibility analysis before modifying the data, and determine whether to wait for modification or continue execution based on the analysis results.

[0095] Conflict resolution strategies can specifically include the following:

[0096] A conflict occurs when multiple patches modify the same property of the same object. The system must provide a conflict resolution strategy, such as:

[0097] Last-Write-Wins (LWW): Based on timestamps, the latest changes overwrite the older ones. Simple but may lose its intended purpose.

[0098] Three-Way Merge: Compares common ancestor versions (Base), version A, and version B, automatically merges conflict-free changes, and marks conflicts for manual resolution. This is a common strategy in version control systems such as Git.

[0099] SemanticMerge: Defines special merging logic for specific component types. For example, if two users both add tags to a tags array, semantic merging will add both tags instead of simply replacing one array with the other.

[0100] Specifically, determining whether differential patches are compatible includes: identifying the entity targeted by each differential patch to obtain the target entity; and determining whether differential patches are compatible based on the spatial relationships and / or reference relationships between the target entities.

[0101] Conflicts between differential patches are essentially discordant changes in the relationships between the entities they operate on. Therefore, determining whether differential patches are compatible is equivalent to analyzing whether unacceptable contradictory relationships will arise between the entities involved in the differential patches.

[0102] First, extract the target entities, traverse each differential patch, parse all its atomic operations (add, update, remove), and collect the set of entity IDs directly affected by these operations. This set is the target entity set of the differential patch. Then, determine whether the differential patches are compatible based on the spatial relationships and / or reference relationships between the target entities.

[0103] In an optional embodiment, determining whether differential patches are compatible based on spatial and / or referential relationships between target entities includes:

[0104] Determine whether the preset spatial conflict conditions are met based on the spatial relationship between the target entities, and / or determine whether the preset reference conflict conditions are met based on the reference relationship between the target entities; if either conflict condition is met, then it is determined that there is a conflict between the differential patches and the corresponding conflict type is determined; otherwise, it is determined that the differential patches are compatible.

[0105] Spatial conflict conditions refer to the mutual exclusion of target entities in space. Mutual exclusion means that they cannot coexist logically or functionally. Geometrically, this may manifest as the intersection of bounding boxes or the blocking of navigation grids. From a business logic perspective, it is defined by domain rules, such as: the overlap of the base of a building entity and the road surface area of ​​a road entity constitutes mutual exclusion; the overlap of a safe zone and a danger zone constitutes mutual exclusion; and two buildings being too close together constitutes mutual exclusion.

[0106] The system needs to design a spatial semantic rule base to define the mutual exclusion relationships between different entity types. During the inspection, it is necessary not only to calculate the geometric intersection, but also to query the rule base to determine whether the intersection is allowed.

[0107] A reference conflict occurs when the target entity has a dependency on the data flow or reference chain, and the execution of the differential patch invalidates the dependency.

[0108] A reference conflict condition contains two sub-conditions that must be satisfied simultaneously:

[0109] Condition A (Dependency Exists): The target entities have a dependency relationship in the data flow or reference chain. For example, an attribute of one entity (such as a switch) references the ID or state of another entity (such as a door), which establishes a directed dependency edge from the switch to the door.

[0110] Condition B (Operational Break): The execution of the differential patch invalidates the dependency. This means that another patch contains a destructive operation on the referenced entity (gate), such as:

[0111] Delete: Directly remove the door entity.

[0112] Key modification: Changing the ID or type of the door causes the original reference target to disappear or its meaning to change.

[0113] The reference conflict condition is triggered only when both conditions A and B are true, which precisely defines whether the modification is feasible.

[0114] Reference conflict triggering example 1: Quest system (item dependency).

[0115] Initial scenario state: Entity K1 (the referenced party) is a key with ID key_01 and type "quest item". Entity K2 (the dependent party) is a treasure chest with ID chest_01.

[0116] Condition A (Dependency Exists): The opening logic of the treasure chest (K2) explicitly references the ID of the key (K1). This is an unlocking logic dependency: when a player attempts to open the chest, the game engine checks if the item with ID key_01 exists in their inventory.

[0117] Differential Patch (Destructive Operation): The developers decided to remove the old key model and replace it with a new key via a "balance adjustment" patch. The patch includes the atomic operation: Delete entity: item_key_01.

[0118] Condition B (Dependency Failure): After the patch is applied, entity K1 (Ancient Key) disappears from the game world. The required_key attribute of entity K2 (Mysterious Chest) still points to the non-existent item_key_01.

[0119] Conditions A and B are both met, thus triggering a reference conflict. After this differential patch is applied, players will never be able to obtain item_key_old, causing chests to become unopenable and the questline to be permanently blocked—a serious game flaw.

[0120] Reference conflict trigger example 2: level mechanism (trigger dependency).

[0121] Initial game state: Entity P1 (the referenced party): a "pressure plate" trap, ID=trap_pressure_plate. Entity P2 (the dependent party): a "stone wall", ID=wall_falling_rocks. Its attribute includes: "triggered_by":"trap_pressure_plate".

[0122] Condition A (Dependency Exists): The triggering logic of the stone wall (P2) depends on the signal emitted by the pressure plate (P1). This is an event listener dependency.

[0123] Differential Patch (Destructive Action): The level designers decided to replace the pressure plate with a more aesthetically pleasing "magic rune" through a "level optimization" patch and modified its ID.

[0124] Condition B (Dependency Failure): After the patch is applied, the entity with ID `trap_pressure_plate` no longer exists in the system. Entity P1 (Stonewall) is still listening for signals from an entity that no longer exists.

[0125] Conditions A and B are both met, thus triggering a reference conflict. Conflict result: The player steps on a new magical rune, but the stone wall doesn't react; the expected puzzle logic completely fails, and the player cannot pass through this area.

[0126] This embodiment establishes clear and computable formal rules (spatial mutual exclusion, dependency invalidation) to enable the differential merging engine to perform static analysis and conflict prediction on parallel-edited patches, just like a compiler performs syntax and semantic checks. This allows it to intercept erroneous differential patches before the modifications actually take effect, thus ensuring data quality.

[0127] To clearly illustrate the stages of merging differential patches, please refer to [reference needed]. Figure 2 The flowchart illustrates a differential patching process applied to scene data, such as... Figure 2 As shown, the application of differential patching includes the following stages:

[0128] Phase 1: Initial Synchronization Phase.

[0129] Users A and B obtain the latest base scene file Scene_V1, ensuring that all collaborators start working from a consistent starting point.

[0130] Phase Two: Parallel Editing Phase.

[0131] User A's editing workflow: A1 (editing the scenario) -- A2 (schema validation) -- A3 (validation passed) -- A4 (generating Patch_A and submitting);

[0132] User B's editing process: B1 (editing the scenario) -- B2 (schema verification) -- B3 (verification passed) -- B4 (generating Patch_B and submitting).

[0133] User A and User B edit their respective local copies of the base scene file (Scene_V1) independently. User A edits "Building Group A," while User B edits "Road B." Before generating and submitting patches, a schema validator checks whether the locally modified scene data conforms to the predefined JSON schema specification. This upfront data validity check prevents invalid or incorrectly formatted data (such as incorrect types or missing required fields) from contaminating the data source. Ultimately, users do not submit the entire massive scene JSON file; they only submit Patch_A.json and Patch_B.json, recording the changed portions—that is, only differential patches. Differential patches are small in size, resulting in high efficiency in network transmission and version storage. Furthermore, the uniform format of differential patches provides a foundation for subsequent automated merging.

[0134] Phase 3: Automatic Merging Phase.

[0135] In this phase, the merge engine (ME) is triggered, which may be triggered by a commit event, a scheduled task, or a manual command. The merge engine retrieves the base scene file (Scene_V1), differential patches Patch_A, and Patch_B from the repository.

[0136] Then, patch compatibility is analyzed, specifically including:

[0137] Check for spatial conflicts: Even if two patches modify different entities, if the bounding box of the newly created building complex in Patch_A significantly overlaps with the road area modified in Patch_B in physical space, the system will consider this to be a design conflict (such as a house being built in the middle of the road), which requires manual review.

[0138] Dependency check: If Patch_B modifies or deletes an entity, and Patch_A happens to reference that entity, this will also be identified as a conflict.

[0139] Conflict handling path: If a conflict is detected, the engine will not force a merge. Instead, it will generate a detailed Conflict_Report.json file, which will contain conflict details and may provide suggested solutions (such as "Please ask User A to adjust the building location" or "Please ask User B to modify the road route"). The relevant users will then be notified for them to resolve the issue through negotiation.

[0140] Conflict-free merge path: If the patches do not affect each other (building group A and road B do not conflict spatially and have no logical dependency), the engine will apply the patches in the order of submission or in a certain set strategy (such as sorting by patch ID).

[0141] For example, first apply Patch_A to the base scene (Scene_v1) to apply the modifications of A, generating an intermediate state Scene_v1+A. Then, continue to apply the modifications of Patch_B to the intermediate state to generate a new complete scene Scene_v2.json.

[0142] Verify the final scenario: Perform a comprehensive schema validation on Scene_v2.json to ensure the final consistency and validity of the merged result.

[0143] Submit a new version: After verification, the merged complete scene will be submitted back to the repository as version v2.

[0144] Step 4: Synchronization and Update Phase.

[0145] The system broadcasts a new version of the scene, and users can choose to pull Scene_v2.json. This v2 scene contains all valid modifications made by User A and User B. From now on, v2 will become the new base version for the next parallel editing loop.

[0146] The workflow described above forms a production pipeline for updating entities in the scenario through pulling, editing, submitting patches, automatic merging, and synchronous updates. This allows multiple users to modify the same base version simultaneously, and the system automatically attempts to merge the changes in the backend, greatly improving the efficiency of parallel work within the team.

[0147] In an optional embodiment, the initial data further includes a prototype library that defines at least one object template; and before applying atomic operations from the differential patch to the scene data to generate a scene state graph, it also includes:

[0148] For each entity in the scene data, determine the object template referenced by the entity from the prototype library based on the prototype reference field in the entity; merge the object template with the entity's attributes to obtain the entity's complete attributes.

[0149] This step occurs before the differential patch is applied, ensuring that the atomic operations of the differential patch are performed on the complete properties of the entity.

[0150] Among them, the prototype library is an independent and editable resource library. The prototype library can define different types of prototypes (object templates). Each object template defines all the default and common properties of a certain type of entity (such as basic mesh, material, physical parameters, script logic).

[0151] Entities in the scene data are concrete instances, each containing a prototype reference field (archetype), which points to a template, and the overrides field declares personalized modifications relative to that template.

[0152] First, a key-value template lookup is performed. The system uses the value of the `archetype` field in the entity as the key to search the prototype library, find the corresponding object template, and establish a link between the instance and the class definition. Next, attribute merging is performed. For example, for each level, attribute values ​​declared in the instance's `overrides` section unconditionally replace the default values ​​with the same names in the prototype template; newly added attributes in `overrides` are added; attributes existing in the prototype but not mentioned in `overrides` are retained. Finally, a complete set of attributes for the entity is generated. This set is the final and complete list of all configurable items for the entity, and all subsequent system operations (difference merging, scene graph construction, engine instantiation) will be based on this list.

[0153] Optionally, attribute merging typically employs a recursive, overwrite-first dictionary merging algorithm.

[0154] The final complete property P of an (entity) instance fi It is through its prototype property P ar and the instance's own overridden property P ov The result is obtained through calculation. This merging process can be represented as:

[0155] P fi =DeepMerge(P ar P ov );

[0156] The DeepMerge(A, B) function recursively merges two objects. If the key exists in B, the value in B (whether a simple value or an object) will completely replace the value of the corresponding key in A.

[0157] This embodiment achieves the following technical effects by setting up a prototype library and merging the attributes of object templates and entities in the prototype library:

[0158] First, in traditional scenarios, each entity must store all its attribute values, resulting in exceptionally large scene files containing thousands of similar objects (such as trees, streetlights, and soldiers). In this embodiment, entities only need to store incremental information that distinguishes them from their prototypes (such as location and modified attributes). This significantly compresses the size of scene data files, greatly reducing disk storage requirements and increasing the speed of network transmission (such as downloading updates and synchronous collaboration) by orders of magnitude.

[0159] Secondly, during collaborative editing or online game synchronization, only very small differential patches (containing only modifications to entity overrides) need to be transmitted, rather than synchronizing the entire massive entity state. This not only greatly saves bandwidth but also allows for precise control over the intent and scope of each modification, avoiding unnecessary data disturbances and overwriting that could result from full synchronization, thus enabling real-time, fine-grained parallel collaboration.

[0160] Third, when entity attributes are fully recorded, version differences (diff) can become chaotic due to a large number of duplicate default attribute values. In this embodiment, the version control system tracks clear and concise prototype reference changes and modifications to overridden attributes, rather than dealing with massive underlying numerical changes, greatly improving the maintainability of the code (data).

[0161] Fourth, when it's necessary to globally adjust the attributes of a certain type of object (such as dimming the brightness of all "purple streetlights" by 20%), the traditional method requires finding and modifying thousands of entities one by one. In this embodiment, only the corresponding template in the prototype library needs to be modified once. All entities referencing that template will automatically inherit this update the next time it is loaded or parsed. This not only improves the efficiency of game updates but also avoids omissions or errors that may be caused by manually modifying each entity one by one, ensuring a high degree of consistency in the visual style and game logic of the virtual world.

[0162] In an optional embodiment, the object template and the entity are merged to obtain the entity's complete attributes, including:

[0163] For each entity, parse the entity and obtain its overridden attributes; determine if the overridden attributes are empty; if so, use the default attributes of the object template as the complete attributes of the entity; otherwise, merge the default attributes of the object template with the overridden attributes to obtain the complete attributes of the entity.

[0164] Overriding properties are specific properties in the prototype-instance mechanism that an instance object can override the default value of its prototype template.

[0165] An empty override attribute indicates that the entity has not defined any attributes in its overrides field, or that the overrides field itself does not exist. This means that the entity is equivalent to the prototype without any personalized modifications. This is a special merge operation, essentially a reference operation. The system can directly assign a pointer to the prototype's default attribute data structure to the entity as its complete attribute. This avoids the computational overhead of dictionary traversal merging, and can bring significant performance improvements for a large number of standard objects in the scene (such as identical streetlights on a street).

[0166] If the override property is not empty, the entity's overrides field contains one or more property definitions. This indicates that the entity is a personalized variant based on the prototype. Therefore, the default properties of the object template can be merged with the override properties, specifically using a deep merging algorithm.

[0167] In large-scale scenarios, entities that fully inherit from the prototype often constitute the vast majority. This optimization avoids performing unnecessary merging calculations for these entities, significantly reducing the average complexity of the algorithm and greatly accelerating scene loading and parsing speed.

[0168] Optionally, overridden attributes may include transformation information, which is a set of basic data describing the position, orientation, and size of an object in three-dimensional space. This is a basic attribute that every object (whether an instance or an independent object) possesses, and it determines the object's specific behavior in the world.

[0169] In the prototype-instance mechanism, the prototype usually does not contain transformation information (or contains a default transformation, such as position at origin, rotation of zero, and scaling of 1). Since the position, orientation, and size of each instance in the scene are independent, the instance must store its own transformation information in order to be correctly placed in the scene.

[0170] For example, a prototype of a "tree" defines the tree's model, materials, colliders, etc., but there may be 1000 trees in the scene, each with a different position, rotation, and scale. Therefore, each instance only needs to store the transformation information relative to the prototype, without repeatedly storing model, material, and other data.

[0171] Transformation information is the most fundamental part of instance data, and each instance typically has its own transformations. In some cases, transformation information can be overridden; for example, an instance can override the prototype's default scaling value.

[0172] Transformation information is described through the Transform component, which defines the spatial position, rotation, and scaling of an entity in the virtual scene. The final transformation matrix M of an instance in the virtual scene is... w M is the world transformation matrix of its parent entity (if it exists in the scene graph). pThe local transformation matrix M of the instance itself l The product of.

[0173] M l Calculated from the Position, Rotation, and Scale of the instance transform component:

[0174] M l =T(Px,Py,Pz)×Rz(γ)Ry(β)Rx(α)×S(Sx,Sy,Sz);

[0175] Where T, R, and S are translation, rotation, and scaling matrices, respectively. This hierarchical transformation structure, combined with the prototype mechanism, can efficiently construct complex scenes composed of repetitive elements.

[0176] In an optional embodiment, the default and overridden properties of the object template are merged to obtain the complete properties of the entity, including:

[0177] Using overridden properties as the highest priority, the default and overridden properties of the object template are merged to obtain the complete properties of the entity.

[0178] The rule of giving the highest priority to overridden properties means that if and only if an entity explicitly declares a modification to a property value in its overrides, that declaration will unconditionally and completely replace any default value inherited from the prototype. This is the basis for achieving personalized customization of entities.

[0179] In an optional embodiment, the default and overridden attributes of the object template are merged with the overridden attributes as the highest priority to obtain the complete attributes of the entity, including:

[0180] For each key in each overridden property, determine if the current key of the overridden property exists in the initial property. If it does, replace the value of the corresponding key in the initial property with the value of the current key of the overridden property. If not, add the key-value pair of the overridden property to the initial property. Use all the updated initial properties as the complete properties of the entity.

[0181] Each default property of the object template is used as the initial property of the entity. This step performs a full copy, where the system copies all properties (key-value pairs) defined in the prototype template to form a temporary, modifiable dictionary, which serves as the baseline for the merge operation, making all default values ​​candidate results. Then, the system iterates through each entry in the overridden property dictionary and determines how to modify the baseline dictionary based on a key condition: whether the current key of the overridden property exists in the initial property.

[0182] Branch 1 (Overwrite): If so, the value of the current key in the overwrite attribute replaces the value of the corresponding key in the initial attribute. This operation directly modifies the value corresponding to the key that already exists in the baseline dictionary, which forcibly applies the personalized settings to the entity, achieving the highest priority for overwrite attributes.

[0183] Branch 2 (Extension): If not, add key-value pairs of overriding attributes to the initial properties. This operation inserts the new attribute and its value into the baseline dictionary, allowing entities to have unique attributes not present in their prototype class, thus enabling flexible extension of functionality.

[0184] Once all entries in the overwrite dictionary have been processed, the initial attribute dictionary, which served as the baseline, now contains all default attributes, the overwritten new values, and any newly added attributes. At this point, this dictionary is defined as the entity's complete attribute dictionary.

[0185] In an optional embodiment, the virtual scene construction method further includes:

[0186] The validity of the initial data is verified according to the preset data specifications; when the initial data is valid, the atomic operations in the differential patch are applied to the scene data to generate a scene state diagram.

[0187] A predefined data specification is typically a formalized, machine-readable data contract, implemented as a JSON Schema file. It precisely defines the following:

[0188] Structure: Which fields are required (e.g., each entity must have an id), and the nesting relationships between fields.

[0189] Type: The data type of each field value (string, number, array, object).

[0190] Constraints: Valid range of values ​​(e.g., RGB color values ​​are between 0 and 1, and the position is not infinity or NaN);

[0191] Relationships: Dependencies between fields (e.g., the mass property must be included when the physics component exists).

[0192] The system (Schema validator) compares the received initial data (scene data, differential patches, prototype library) with this data contract. The validation is comprehensive, including syntax (format) and some semantics (value range). It can intercept all erroneous data that does not conform to the agreement in the first instance, preventing it from polluting downstream processing flows.

[0193] In an optional embodiment, the entity includes at least one semantic component; the instantiation of entities in the scene state graph into corresponding runtime objects in the target engine based on preset mapping rules to construct a virtual scene includes:

[0194] For each entity in the scene state diagram, a corresponding engine object is created in the target engine; according to the preset mapping rules, the component type of each semantic component in the entity is determined in the engine object; a runtime component of each component type is created in the engine object; the runtime component is configured according to the semantic component to construct the virtual scene.

[0195] Runtime components refer to modular, reusable software units that exist during program execution and encapsulate specific data and behaviors. They are typically instantiated as objects, serving as part of larger entities (such as game objects or business entities), and providing them with specific functionalities or characteristics.

[0196] In the target engine, a corresponding engine object is created. Specifically, the target engine's API is called to create the most basic, empty container object. For example, in Unity, this is a GameObject; in Unreal Engine, it is an AActor or an empty Uobject. By creating this object, a physical link is established between the data entity and the runtime world. Then, each semantic component of the entity (such as render, physics, light) is traversed, and the mapping rule library is queried. This is a lookup table operation that converts platform-independent semantic tags into specific class names or component type identifiers specific to the target engine. For example, the semantic tag physics is mapped to the UnityEngine.Rigidbody class, or point_light is mapped to ULightComponent and its type is specified as Point. Through configurable mapping rules, the same scene data can drive the creation of functionally equivalent but differently implemented components in different engines. The attribute values ​​(such as color, intensity, and quality) defined in the semantic component are transformed and assigned to the corresponding attributes of the runtime component created in the previous step through attribute mapping rules (property_map and value_map). This transforms the design intent (data) into specific runtime behavior and performance, enabling the object to change from having capabilities to running with specific parameters.

[0197] The Engine Access Layer (EAL) is the "last mile" of this invention. It transforms abstract, engine-independent scene descriptions into renderable and interactive entities within the engine. Specifically, it examines each semantic tag and creates a corresponding component. Most component creation can be performed in parallel, with each component type determined independently and without interference.

[0198] like Figure 3 The diagram illustrates the mapping process from semantic components to specific engine components, which includes the following steps:

[0199] 1. After the scene construction begins, the system iterates through each entity (Loop) in the scene.

[0200] 2. For each entity, check if it contains a Physics component. If so, create a RigidBody and a Collider (the concrete engine component).

[0201] 3. Check if a Lighting component is included. If so, create Light and Shadow components.

[0202] 4. Check if a rendering component is included. If so, create the MeshRenderer and Material components.

[0203] 5. Next, check if an audio component is included. If so, create an AudioSource component.

[0204] 6. Add the configured entity to the engine object, and then continue processing the next entity.

[0205] 7. Once all entities have been processed, the scene construction is complete.

[0206] By traversing entities and creating corresponding concrete components in the engine based on the semantic component types possessed by each entity, the semantic components serve as intermediate descriptions. Through mapping rules and component factories, specific runtime components are instantiated in the target engine. Scene data is not dependent on a specific engine; only the mapping rules need to be modified to adapt to different engines, achieving decoupling between content and engine. Furthermore, new semantic component types can be easily added, and how to create new engine components can be defined within the mapping rules.

[0207] It should be noted that, Figure 3 This is just an example. In the actual process of mapping semantic tags to engine components, it may also be necessary to consider the dependencies between components. For example, the rendering component may depend on the transformation component, and the transformation component is usually essential for every entity.

[0208] Mapping rules are stored in a mapping rule library, and each mapping rule includes the following:

[0209] Semantic_component: The component name in the JSON.

[0210] Engine_component: The class name of the corresponding component in the engine.

[0211] Property_map: A direct mapping between property names.

[0212] Value_map: A mapping between enumerated values.

[0213] Post_create_logic: Points to a script or function for handling more complex logic, such as based on...

[0214] Collision shape strings create different types of Collider components.

[0215] The instantiation process includes the following steps:

[0216] 1. The EAL (Engine Access Layer) receives the scene state diagram.

[0217] 2. For each entity in the graph, EAL creates an empty engine object (such as Unity's GameObject or Unreal's AActor).

[0218] 3. It iterates through every semantic component in the entity's JSON.

[0219] 4. For each semantic component, it looks up the corresponding rule in the mapping rule base.

[0220] 5. According to the rules, it calls the component factory to add the corresponding engine components to the engine object.

[0221] 6. It uses property_map and value_map to assign values ​​from JSON to the properties of engine components.

[0222] 7. If post_create_logic is defined, this logic will be executed to perform complex settings.

[0223] 8. Once all components have been added and configured, entity instantiation is complete.

[0224] The instantiation process can be completed all at once when the game starts, or it can be performed dynamically and asynchronously as needed during runtime, thus achieving streaming loading.

[0225] To clearly illustrate the virtual scene construction method of this invention, the following examples will be used for explanation. Figure 4 The overall architecture diagram of the virtual scene construction system is shown, and the virtual scene construction method is implemented through the virtual scene construction system. For example... Figure 4 As shown, the virtual scene construction system includes: content creation layer 401, data representation layer 402, core processing layer 403, engine access layer 404, and target engine 405.

[0226] Content Creation Layer 401: This layer is the source of scene data, which can be manually edited by designers, generated by the PCG algorithm, or UGC content from end users. All sources are uniformly output in semantic JSON format.

[0227] Data representation layer 402: Defines the core data structure of this invention.

[0228] Semantic scene: that is, scene data, describes the collection of all entities in the scene, and is a "snapshot" of the scene.

[0229] Archetype library: one or more JSON files that define reusable object templates.

[0230] Differential patch: Describes one or more atomic modifications to a scene, used for version updates and collaboration.

[0231] Core processing layer 403: Responsible for processing and calculating the input JSON data to build the final scene logic view.

[0232] Schema validator: Ensures that all input data conforms to the predefined JSON Schema specification, guaranteeing data consistency and validity.

[0233] Prototype / Instance Resolver: Reads the instance's archetype reference and merges the prototype's properties with the instance's own overrides property to calculate the instance's final complete properties.

[0234] Differential merging engine: Applies differential patches to the base scene sequentially, performs add / update / remove operations, and handles any conflicts that may occur.

[0235] Scene State Graph Builder: It constructs all processed entities and their relationships into an in-memory, easily queryable Scene Graph or entity list, which is then delivered as a data structure to the next layer.

[0236] Engine Access Layer 404: Serves as a bridge connecting abstract data and concrete engines.

[0237] Mapping rule base: Defines the mapping rules from semantic tags (such as "physics", "lighting") to target references.

[0238] The mapping rules for specific components (such as RigidBody, PointLight).

[0239] Component Factory: Responsible for actually creating and configuring component instances in the engine according to the mapping rules.

[0240] Object Lifecycle Manager: Manages the creation, destruction, and updating of objects in the engine, keeping them synchronized with the scene state graph.

[0241] Scene streaming loader: Loads and unloads scene parts on demand and asynchronously based on player position or other logic, enabling seamless construction of virtual worlds.

[0242] Target Engine 405: The runtime environment that ultimately hosts and renders the virtual world. The access layer design of this invention allows it to be adapted to any mainstream or self-developed game engine.

[0243] The specific applications of this invention are illustrated below through concrete examples:

[0244] Example 1: Building a large modular city.

[0245] Scenario requirement: Procedurally generate a race containing tens of thousands of buildings and countless street facilities (streetlights, benches, trash cans).

[0246] A cyberpunk-style city. Directly storing each object would result in terabytes of scene data and extremely low editing efficiency.

[0247] Application of this invention:

[0248] 1. Create a prototype library: The designer or AI creates a rich prototype library, cyberpunk_archetypes.json.

[0249] Define 10 different styles of skyscraper prototypes (arc_skyscraper_A to arc_skyscraper_J).

[0250] Define 5 commercial building prototypes (arc_shop_neon_A...).

[0251] Define prototypes for street facilities such as streetlights, vehicles, and billboards. Each prototype contains complete semantic components for geometry, material, lighting, and physics.

[0252] 2. Procedural Layout: A PCG script is responsible for the macro-layout of the city. It does not concern itself with the specific details of the buildings, but only with generating instances.

[0253] The script generates a huge city_scene.json file, in which the entities array contains hundreds of thousands of instance objects.

[0254] For example, a typical building example might only have a few lines of code:

[0255] {

[0256] "id":"bld_financial_district_0123",

[0257] "archetype":"arc_skyscraper_G",

[0258] "transform":{

[0259] "position":[1234.5,0.0,5678.9],

[0260] "rotation":[0,90,0]

[0261] },

[0262] "overrides":{

[0263] "material":{"emissive_color":"#00FFFF"}

[0264] }

[0265] }

[0266] Therefore, the description file for the entire city might only be a few hundred MB, rather than TB.

[0267] 3. Engine Loading: During game runtime, the scene streaming loader loads only entity descriptions within a 1-kilometer radius of the player's location.

[0268] The Engine Access Layer (EAL) reads these instance descriptions, parses complete properties from the prototype library in real time, and creates AActors or GameObjects in the engine. For example, seeing a lighting component, UnityEAL adds a Light component to the GameObject and sets its color and intensity. Once the player is away, these objects are safely unloaded from the engine, freeing up memory.

[0269] This example significantly reduces data storage and memory footprint through a prototype / instance mechanism, making it possible to build and run extremely large-scale worlds. At the same time, modifying a class of objects becomes exceptionally simple; just modify the prototype file, and all instances will be automatically updated.

[0270] Example 2: Multiplayer collaborative level design and UGC.

[0271] Scenario Requirements: A level design team (planner, artist, and technician) needs to simultaneously edit a complex indoor level. Planner A is responsible for placing enemy patrol paths (AI-related), artist B is responsible for adjusting the lighting atmosphere, and technician C is responsible for optimizing physics collisions. Meanwhile, beta testers are allowed to add decorations to the level using UGC tools.

[0272] 1. Parallel editing.

[0273] Everyone started working based on the same base version, level_03_v2.json.

[0274] When Designer A adds a patrol point, their editor generates a differential patch file, `patch_A.json`, which adds an entity with an AI component. When Artist B adjusts a light color, their tool generates `patch_B.json`, which updates the `color` property of a lighting component. After Technician C optimizes a model's collider, they generate `patch_C.json`, which updates the `collision` property of a physics component. Beta tester D adds a bonsai using the UGC tool, and the client generates `patch_UGC_D.json`.

[0275] 2. Version merging.

[0276] Everyone submits their patches to the version control system. The CI / CD pipeline or level manager triggers the merge process. The differential merge engine applies patches A, B, C, and UGC_D in sequence. Since everyone is modifying different components of different entities, there are no conflicts, and the merge completes smoothly, generating level_03_v3.json. If designer A and artist B happen to modify the name attribute of the same entity, the merge engine will detect the conflict, mark it, and notify the relevant personnel to make a manual decision, ensuring data consistency.

[0277] This example achieves true parallel, non-blocking collaboration through a differential merging mechanism. Each commit is a lightweight, readable patch, greatly improving the efficiency of version tracking and code review (here, SceneReview). UGC content can also be safely and atomically integrated into the main world in the same way.

[0278] Compared with the prior art, the present invention has the following significant advantages:

[0279] 1. Productivity: Through engine decoupling and unified semantic description, content creators can focus on creation without being bound by the implementation details of a specific engine. The prototyping mechanism improves the efficiency of building and modifying large-scale scenes by several orders of magnitude.

[0280] 2. Collaboration and Scalability: The differential patch-based workflow fundamentally solves the bottleneck of multi-person collaboration, enabling fine-grained version control, change tracking, and conflict-free merging, making collaborative development of large-scale, distributed teams and the construction of a UGC ecosystem possible.

[0281] 3. Performance and Optimization: The prototyping / instance mechanism significantly reduces data redundancy and lowers storage, network transmission, and memory overhead. Streaming and loading engine-independent data formats also provide a foundation for extreme runtime performance optimization.

[0282] 4. Asset Lifespan and Value: Scene data exists in an open and universal format, no longer a "one-off" asset. They can be easily used for sequel development, ported to new platforms or engines, and even used in fields outside of gaming (such as film rendering and simulation), greatly extending the lifespan and value of digital assets.

[0283] 5. AI and Programmatic Friendliness: Structured and semantic scene descriptions provide a favorable environment for AI to understand and generate the world. AI can directly read and generate JSON containing physical, interactive, and narrative logic, rather than just meaningless geometric shapes, truly achieving end-to-end, fully functional world generation.

[0284] It should be noted that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0285] Reference Figure 4 The diagram illustrates a virtual scene construction system provided by an embodiment of the present invention, which may specifically include the following modules:

[0286] The core processing layer 403 is used to acquire initial data, which includes scene data and at least one differential patch. The scene data defines a set of entities in the virtual scene in an engine-independent declarative format, and the differential patch includes atomic operations on the virtual scene.

[0287] The core processing layer 403 is also used to apply the atomic operations in the differential patch to the scene data to generate a scene state diagram;

[0288] Engine access layer 404 is used to instantiate the entities in the scene state diagram into corresponding runtime objects in the target engine based on preset mapping rules, so as to construct a virtual scene.

[0289] Optionally, the core processing layer 403 includes a scene state graph builder, which is used for:

[0290] When there are multiple differential patches, obtain the execution order of the differential patches;

[0291] The atomic operations in the differential patch are applied to the scene data in the order of execution to generate a scene state graph.

[0292] Optionally, the differential patch includes atomic operations and entity positioning paths, and the core processing layer 403 includes a scene state graph builder, which is used for:

[0293] For each differential patch, the target level within the entity is located in the scene data according to the entity localization path therein;

[0294] The properties of the target level are modified according to the atomic operations of the differential patch;

[0295] After the differential patch traversal is completed, a scene state diagram is generated based on the updated entities and the relationships between the entities in the scene data.

[0296] Optionally, the core processing module 403 further includes a differential merging engine, which is used for:

[0297] Determine whether the differential patches are compatible;

[0298] If not, a conflict report is generated and fed back to the user based on the identifier of the incompatible differential patch and the preset conflict resolution strategy;

[0299] If so, then the step of applying the atomic operations in the differential patch to the scene data to generate a scene state graph is performed.

[0300] Optionally, when determining whether the differential merging engine is compatible between the differential patches, it is used to:

[0301] The entity targeted by each differential patch is determined to obtain the target entity;

[0302] The compatibility between the differential patches is determined based on the spatial and / or referential relationships between the target entities.

[0303] Optionally, when the differential merging engine determines whether the differential patches are compatible based on the spatial relationships and / or reference relationships between the target entities, it is used to:

[0304] Determine whether the preset spatial conflict conditions are met based on the spatial relationship between the target entities, and / or determine whether the preset reference conflict conditions are met based on the reference relationship between the target entities;

[0305] If any conflict condition is met, it is determined that there is a conflict between the differential patches and the corresponding conflict type is determined.

[0306] If not, then determine that the differential patches are compatible;

[0307] The spatial conflict condition is that the target entities are mutually exclusive in space, and the reference conflict condition is that the target entities have a dependency relationship in the data flow or reference chain, and the execution of the differential patch makes the dependency relationship invalid.

[0308] Optionally, the initial data may also include a prototype library that defines at least one object template;

[0309] The core processing layer 403 also includes a differential merging engine, which is used for:

[0310] For each entity in the scene data, the object template referenced by the entity is determined from the prototype library based on the prototype reference field in the entity;

[0311] The object template and the entity are merged to obtain the complete attributes of the entity.

[0312] Optionally, when the differential merging engine merges the attributes of the object template and the entity to obtain the complete attributes of the entity, it is used to:

[0313] For each entity, parse the entity and obtain the overridden attributes of the entity;

[0314] Determine whether the overwrite attribute is empty;

[0315] If so, the default properties of the object template shall be used as the complete properties of the entity;

[0316] If not, the default properties of the object template are merged with the overridden properties to obtain the complete properties of the entity.

[0317] Optionally, when the differential merging engine merges the default attributes of the object template with the overridden attributes to obtain the complete attributes of the entity, it is used to:

[0318] The default attributes of the object template and the overridden attributes are merged with the overridden attributes as the highest priority to obtain the complete attributes of the entity.

[0319] Optionally, when the differential merging engine merges the default attributes of the object template and the overridden attributes with the overridden attributes as the highest priority to obtain the complete attributes of the entity, it is used to:

[0320] Each default property of the object template is used as the initial property of the entity;

[0321] For each key in each of the overridden attributes, determine whether the current key of the overridden attribute exists in the initial attribute;

[0322] If so, the value of the corresponding key in the initial attribute is replaced with the value of the current key of the overriding attribute;

[0323] If not, add the key-value pair of the overriding property to the initial property;

[0324] All the updated initial attributes are used as the complete attributes of the entity.

[0325] Optionally, the core processing layer 403 further includes a schema validator, which is used for:

[0326] The validity of the initial data is verified according to the preset data specifications;

[0327] When the initial data is valid, the step of applying the atomic operations in the differential patch to the scene data is performed to generate a scene state graph.

[0328] Optionally, the entity includes at least one semantic component; the engine access layer 404 is used for:

[0329] For each entity in the scene state diagram, a corresponding engine object is created in the target engine;

[0330] According to the preset mapping rules, determine the component type of each semantic component in the entity in the engine object;

[0331] Create a runtime component for each of the component types in the engine object;

[0332] The runtime components are configured according to the semantic components to construct a virtual scene.

[0333] Optionally, when configuring the runtime component according to the semantic component, the engine access layer 404 is used to:

[0334] The attribute values ​​in the semantic component are transformed and then assigned to the attributes of the runtime component.

[0335] The present invention provides a virtual scene construction system, which can be used to implement the steps in the aforementioned virtual scene construction method embodiments.

[0336] It should be noted that the module division in the various virtual scene construction systems provided in the above embodiments is illustrative and only represents a logical functional division. In actual implementation, other division methods may also be used. Furthermore, the functional modules in the various embodiments of this invention can be integrated into a single processor, exist as separate physical entities, or be integrated into a single module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0337] If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the technical solution of the embodiments of the present invention can be embodied in the form of a computer program product, which is stored in a computer storage medium and includes several instructions to cause an electronic device or processor to execute all or part of the steps of the methods in the various embodiments of the present invention. The aforementioned computer storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0338] Furthermore, the virtual scene construction system and the virtual scene construction method provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0339] Reference Figure 5 The diagram illustrates an electronic device according to an embodiment of the present invention. Figure 5 As shown, the electronic device in this embodiment of the invention includes: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps in the above-described virtual scene construction method embodiment. Alternatively, when the processor executes the computer program, it implements the functions of each module in the above-described virtual scene construction system embodiment.

[0340] For example, the computer program may be divided into one or more modules, which are stored in the memory and executed by the processor to complete this application. The one or more modules may be a series of computer program instruction segments capable of performing a specific function, which can be used to describe the execution process of the computer program in the electronic device.

[0341] The electronic device may be a desktop computer, a cloud server, or other computing device. The electronic device may include, but is not limited to, a processor and memory. Those skilled in the art will understand that... Figure 5 This is merely one example of an electronic device and does not constitute a limitation on the electronic device. It may include more or fewer components than illustrated, or combine certain components, or different components. For example, the electronic device may also include input / output devices, network access devices, buses, etc.

[0342] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0343] The memory can be an internal storage unit of the electronic device, such as a hard drive or RAM. Alternatively, it can be an external storage device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, Flash Card, etc. Furthermore, the memory can include both internal and external storage units. The memory is used to store the computer program and other programs and data required by the electronic device. The memory can also be used to temporarily store data that has been output or will be output.

[0344] This invention also discloses an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the virtual scene construction method as described in the foregoing embodiments.

[0345] This invention also discloses a computer-readable storage medium storing a computer program that, when executed by a processor, implements the virtual scene construction method as described in the foregoing embodiments.

[0346] This invention also discloses a computer program product that, when run on a computer, causes the computer to execute the virtual scene construction method described in the foregoing embodiments.

[0347] The embodiments described above are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for constructing a virtual scene, characterized in that, include: Acquire initial data, which includes scene data and at least one differential patch. The scene data defines a set of entities in the virtual scene in an engine-independent declarative format. The differential patch includes atomic operations on the virtual scene. The atomic operations in the differential patch are applied to the scene data to generate a scene state graph; Based on preset mapping rules, the entities in the scene state diagram are instantiated into corresponding runtime objects in the target engine to construct a virtual scene.

2. The method according to claim 1, characterized in that, The step of applying the atomic operations in the differential patch to the scene data to generate a scene state graph includes: When there are multiple differential patches, obtain the execution order of the differential patches; The atomic operations in the differential patch are applied to the scene data in the order of execution to generate a scene state graph.

3. The method according to claim 1, characterized in that, The differential patch includes atomic operations and entity positioning paths. Applying the atomic operations in the differential patch to the scene data to generate a scene state graph includes: For each differential patch, the target level within the entity is located in the scene data according to the entity localization path therein; The properties of the target level are modified according to the atomic operations of the differential patch; After the differential patch traversal is completed, a scene state diagram is generated based on the updated entities and the relationships between the entities in the scene data.

4. The method according to claim 1, characterized in that, Also includes: Determine whether the differential patches are compatible; If not, a conflict report is generated and fed back to the user based on the identifier of the incompatible differential patch and the preset conflict resolution strategy; If so, then the step of applying the atomic operations in the differential patch to the scene data to generate a scene state graph is performed.

5. The method according to claim 4, characterized in that, The step of determining whether the differential patches are compatible includes: The entity targeted by each differential patch is determined to obtain the target entity; The compatibility between the differential patches is determined based on the spatial and / or referential relationships between the target entities.

6. The method according to claim 5, characterized in that, The step of determining whether the differential patches are compatible based on the spatial relationships and / or reference relationships between the target entities includes: Determine whether the preset spatial conflict conditions are met based on the spatial relationship between the target entities, and / or determine whether the preset reference conflict conditions are met based on the reference relationship between the target entities; If any conflict condition is met, it is determined that there is a conflict between the differential patches and the corresponding conflict type is determined. If not, then determine that the differential patches are compatible; The spatial conflict condition is that the target entities are mutually exclusive in space, and the reference conflict condition is that the target entities have a dependency relationship in the data flow or reference chain, and the execution of the differential patch makes the dependency relationship invalid.

7. The method according to claim 1, characterized in that, The initial data also includes a prototype library that defines at least one object template; Before applying the atomic operations in the differential patch to the scene data to generate the scene state graph, the method further includes: For each entity in the scene data, the object template referenced by the entity is determined from the prototype library based on the prototype reference field in the entity; The object template and the entity are merged to obtain the complete attributes of the entity.

8. The method according to claim 7, characterized in that, The step of merging the attributes of the object template and the entity to obtain the complete attributes of the entity includes: For each entity, parse the entity and obtain the overridden attributes of the entity; Determine whether the overwrite attribute is empty; If so, the default properties of the object template shall be used as the complete properties of the entity; If not, the default properties of the object template are merged with the overridden properties to obtain the complete properties of the entity.

9. The method according to claim 8, characterized in that, The step of merging the default attributes of the object template with the overridden attributes to obtain the complete attributes of the entity includes: The default attributes of the object template and the overridden attributes are merged with the overridden attributes as the highest priority to obtain the complete attributes of the entity.

10. The method according to claim 9, characterized in that, The method of merging the default attributes of the object template and the overridden attributes with the highest priority to obtain the complete attributes of the entity includes: Each default property of the object template is used as the initial property of the entity; For each key in each of the overridden attributes, determine whether the current key of the overridden attribute exists in the initial attribute; If so, the value of the corresponding key in the initial attribute is replaced with the value of the current key of the overriding attribute; If not, add the key-value pair of the overriding property to the initial property; All the updated initial attributes are used as the complete attributes of the entity.

11. The method according to any one of claims 1-10, characterized in that, Also includes: The validity of the initial data is verified according to the preset data specifications; When the initial data is valid, the step of applying the atomic operations in the differential patch to the scene data is performed to generate a scene state graph.

12. The method according to any one of claims 1-10, characterized in that, The entity includes at least one semantic component; The method, based on preset mapping rules, instantiates the entities in the scene state graph into corresponding runtime objects in the target engine to construct a virtual scene, including: For each entity in the scene state diagram, a corresponding engine object is created in the target engine; According to the preset mapping rules, determine the component type of each semantic component in the entity in the engine object; Create a runtime component for each of the component types in the engine object; The runtime components are configured according to the semantic components to construct a virtual scene.

13. The method according to claim 12, characterized in that, The configuration of the runtime component based on the semantic component includes: The attribute values ​​in the semantic component are transformed and then assigned to the attributes of the runtime component.

14. A virtual scene construction system, characterized in that, include: The core processing layer is used to acquire initial data, which includes scene data and at least one differential patch. The scene data defines a set of entities in the virtual scene in an engine-independent declarative format, and the differential patch includes atomic operations on the virtual scene. The core processing layer is also used to apply the atomic operations in the differential patch to the scene data to generate a scene state diagram; The engine access layer is used to instantiate the entities in the scene state diagram into corresponding runtime objects in the target engine based on preset mapping rules, so as to construct a virtual scene.

15. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the virtual scene construction method as described in any one of claims 1-13.

16. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the virtual scene construction method as described in any one of claims 1-13.

Images