Node graph curved surface modeling collaborative design method and device, equipment and medium

Abstract

The invention discloses a node graph curved surface modeling collaborative design method and device, equipment and a medium, and the method comprises the steps: obtaining a main branch and a first curved surface modeling graph of node graph curved surface modeling design, the main branch comprises a first node and a plurality of nodes behind the first node, the first curved surface modeling graph is formed by designing all nodes on the main branch; receiving a first merging request sent by a first client, generating a second node and sending the second node; if the priority of the first user is the highest priority, detecting whether the second node conflicts with a plurality of nodes behind the first node; if all the nodes do not conflict, combining the second node to the plurality of nodes on the main branch, generating a third node, and obtaining an updated main branch; and a second curved surface modeling graph is generated according to all the nodes on the updated main branch, so that a collaborative design mode of node graph curved surface modeling is realized, and the working efficiency of multi-person design is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of 3D modeling, and particularly to a collaborative design method, device, electronic device and medium for node graph surface modeling. Background Art

[0002] Surface modeling systems are widely used in the fields of industrial design and manufacturing. Among them, the node graph surface modeling method is a relatively advanced method. However, existing surface modeling systems that are supported have the problems of being unable to provide collaborative design capabilities based on design history, and it is difficult to distinguish the modeling operations performed by different users on the same project for binary surface data. This makes it impossible for designers to effectively manage and trace design changes, thus affecting the design efficiency and quality. Summary of the Invention

[0003] Therefore, to solve the problems that existing surface modeling systems that are supported are unable to provide collaborative design capabilities based on design history, and it is difficult to distinguish the modeling operations performed by different users on the same project for binary surface data, embodiments of the present invention provide a collaborative design method, device, electronic device and medium for node graph surface modeling, and specifically disclose the following technical solutions:

[0004] In a first aspect, embodiments of the present invention disclose a collaborative design method for node graph surface modeling. The method includes: obtaining a main branch of node graph surface modeling design and a first surface modeling graph, where the main branch includes: a first node and several nodes located after the first node, and the first surface modeling graph is formed after all nodes on the main branch are designed; receiving a first merge request sent from a first client, where the first merge request is a request sent after a first user performs a surface modeling design modification on the first node on the first client and generates a second node; if the priority of the first user is the highest priority, detecting whether there is a conflict between the second node and the several nodes located after the first node; if there is no conflict, merging the second node after the several nodes on the main branch to generate a third node, and obtaining an updated main branch; generating a second surface modeling graph according to all nodes on the updated main branch.

[0005] The method provided by this aspect first obtains the main branch of the current surface modeling design and the corresponding surface modeling diagram. Then, when a merge request from the client is received, the priority of the request initiator is detected. If the priority of the request initiator is the highest, it further checks whether there are conflicts between its modified content and other nodes on the main branch. On the premise of ensuring no conflicts, the new design node will be merged into the main branch to form a new node, and the entire main branch will be updated accordingly. This merge mechanism ensures version control and conflict resolution in collaborative design. Finally, based on the updated main branch, the surface modeling diagram is updated and generated, realizing the visualization of the collaborative design results. Through this method, designers can work together in a unified and coordinated environment, promoting the continuous evolution and improvement of the design.

[0006] In addition, this method realizes that in the process of multi-person participation in the design, each modification and iteration can be accurately recorded and managed. This improves work efficiency for complex design projects, especially for surface modeling design projects involving multiple designers and multiple versions.

[0007] Combined with the first aspect, in a possible implementation manner, the method further includes: receiving a second merge request sent by a second client, where the second merge request is a request sent after a second user performs surface modeling design modification on the first node in the second client and generates a fourth node; obtaining the priority of the second user; comparing the priority of the second user with the priority of the first user; if the priority of the first user is higher than the priority of the second user, then perform the step of detecting whether there is a conflict between the second node and several nodes located after the first node.

[0008] In this implementation manner, in addition to receiving the merge request from the first client, the system can also receive a second merge request from the second client. Each second merge request is sent after a first user performs surface modeling design modification on the first node in the client and generates a third node. After receiving the second merge request, the system will first obtain the priority of the second user. This priority may also be set based on the user's role, experience, or other criteria in the team. Then, if the priority of the first user is the highest, the system will detect whether there is a conflict between the second node and several nodes located after the first node. The conflict here can be understood as that the design content of the second node conflicts or contradicts with the existing design nodes on the main branch and needs to be resolved. This implementation manner further expands the scope and complexity of collaborative design by introducing the second client and the second merge request. It enables multiple users to modify and contribute to the main branch simultaneously on different clients, and ensures the coordination and consistency of the design through the priority detection and conflict resolution mechanism.

[0009] In combination with the first aspect, in a possible implementation, the comparison of the priority of the second user with the priority of the first user further includes: if the priority of the first user is lower than the priority of the second user, detecting whether there is a conflict between the fourth node and several nodes after the first node; if there is no conflict, merging the fourth node after the several nodes on the main branch to generate a fifth node, and obtaining an updated main branch; generating a third surface modeling diagram according to all the nodes on the updated main branch.

[0010] In this implementation, if the priority of the first user is lower than the priority of the second user, the system will detect whether there is a conflict between the third node and several nodes after the first node. If there is no conflict, the system will merge the third node after the several nodes on the main branch to generate a fourth node and obtain an updated main branch. Then, the system will generate a third surface modeling diagram according to all the nodes on the updated main branch. This implementation can be used in a collaborative design system to determine the processing order by comparing the priorities of users to avoid conflicts and data inconsistencies. By merging the third node onto the main branch and generating a fourth node, the system can maintain data integrity and consistency and generate a third surface modeling diagram for users to view and further operate.

[0011] In combination with the first aspect, in a possible implementation, the comparison of the priority of the second user with the priority of the first user further includes: if the priority of the first user is the same as the priority of the second user, comparing the sequence of the first timestamp of the first merge request and the second timestamp of the second merge request; if the first timestamp is before the second timestamp, performing the step of detecting whether there is a conflict between the second node of the first user and several nodes after the first node on the main branch.

[0012] In combination with the first aspect, in a possible implementation, if the priority of the first user is the same as the priority of the second user, it further includes: if the first timestamp is after the second timestamp, performing the step of detecting whether there is a conflict between the fourth node of the second user and several nodes after the first node on the main branch.

[0013] This embodiment is about a situation of processing user requests with the same priority. In this case, if the priority of the first user is the same as that of the second user, the node for detecting conflicts will be determined according to the timestamp. If the first timestamp is before the second timestamp, then it will be detected whether there is a conflict between the second node of the first user and several nodes after the first node located on the main branch. This means that if the request of the first user arrives before the request of the second user, the request of the first user will be processed first, and the conflict situation between its second node and the subsequent nodes will be checked. If the first timestamp is after the second timestamp, then it will be detected whether there is a conflict between the third node of the second user and several nodes after the first node located on the main branch. This means that if the request of the second user arrives before the request of the first user, the request of the second user will be processed first, and the conflict situation between its third node and the subsequent nodes will be checked. This mechanism may be used in a system. When multiple users submit requests simultaneously, it is necessary to determine the processing order according to their priorities and submission times to avoid conflicts and data inconsistencies.

[0014] In combination with the first aspect, in a possible implementation, detecting whether there is a conflict between the second node and several nodes after the first node includes: obtaining at least one preset format file of the second node and several nodes after the first node. Each of the preset format files includes: key-value pairs composed of a modification path and modification content; determining whether the modification paths in the preset format file corresponding to the second node are the same as the modification content in each of the preset format files of the several nodes after the first node; if so, it is determined that there is a conflict between the second node and the several nodes after the first node; if not, it is determined that there is no conflict between the second node and the several nodes after the first node.

[0015] In this embodiment, when detecting conflicts, the system obtains the JASON Patch files of the second node on the sub-branch and several nodes after the first node on the main branch, and compares the path information to determine whether there is a conflict. If there is a conflict, the system will generate a conflict detection report and notify the client, and the user can view and resolve the conflict. In this way, the system can coordinate and manage the design operations among multiple people to achieve efficient collaborative design. The server provides a more efficient and flexible collaborative design environment for users by means of retaining the design history of users, supporting multi-person simultaneous design, adopting appropriate merging strategies, and conflict detection and resolution mechanisms.

[0016] In combination with the first aspect, in a possible implementation manner, it further includes: when it is determined that there is a conflict between the second node and several nodes after the first node, generating a conflict detection report and sending the conflict detection report to the first client.

[0017] In this implementation manner, after the first user performs surface modeling design modification on the first node at the client, a second node is generated and a first merge request is sent to the design server. This process can be understood as that after the user modifies the design at the client, the client will generate a new second node and send this new node and related modification information to the server. In addition, if there is a conflict, a conflict detection report is generated and the conflict report is sent to the client. This process can be understood as that when the client sends a merge request to the server, the server will check whether there are files identical to several nodes after the first node. If so, the server will determine that there is a conflict in the nodes and generate a conflict detection report. This conflict detection report will be sent to the client so that the user can know which nodes of which files have conflicts and thus perform corresponding processing. In this node graph surface modeling design system, when multiple users modify the same design simultaneously, the system needs to detect and resolve conflicts to ensure data integrity and consistency. The user can submit a modification request through the client, and the server is responsible for coordinating and managing these requests and generating a conflict detection report for the user to process.

[0018] In a second aspect, an embodiment of the present invention discloses a node graph surface modeling collaborative design device, which includes:

[0019] An acquisition module, configured to acquire a main branch of a node graph surface modeling design and a first surface modeling graph, where the main branch includes: a first node and several nodes after the first node, and the first surface modeling graph is formed after all nodes on the main branch are designed;

[0020] A receiving module, configured to receive a first merge request sent from a first client, where the first merge request is a request sent after a second node is generated after the first user performs surface modeling design modification on the first node at the first client;

[0021] A processing module, configured to detect whether there is a conflict between the second node and several nodes after the first node if the priority of the first user is the highest priority;

[0022] A judgment module, configured to merge the second node after the several nodes on the main branch to generate a third node and obtain an updated main branch if there is no conflict;

[0023] A generation module, configured to generate a second surface modeling diagram according to all nodes on the updated main branch.

[0024] In a third aspect, an embodiment of the present invention further discloses an electronic device, including a processor and a memory, the memory being coupled to the processor; a computer-readable program instruction is stored on the memory, and when the instruction is executed by the processor, a node diagram surface modeling collaborative design method according to the foregoing first aspect or any implementation manner of the first aspect is implemented.

[0025] In a fourth aspect, an embodiment of the present invention further discloses a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, a node diagram surface modeling collaborative design method according to the first aspect or any embodiment of the first aspect is implemented. Description of the Drawings

[0026] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings required for use in the description of the specific embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0027] Figure 1 is a flowchart of a node diagram surface modeling collaborative design method provided by an embodiment of the present invention;

[0028] Figure 2 is a schematic diagram of a node diagram surface modeling collaborative design method provided by an embodiment of the present invention;

[0029] Figure 3 is a schematic diagram of another node diagram surface modeling collaborative design method provided by an embodiment of the present invention;

[0030] Figure 4 is a flowchart of another node diagram surface modeling collaborative design method provided by an embodiment of the present invention;

[0031] Figure 5 is a flowchart of another node diagram surface modeling collaborative design method provided by an embodiment of the present invention;

[0032] Figure 6 is a flowchart of another node diagram surface modeling collaborative design method provided by an embodiment of the present invention;

[0033] Figure 7 is a structural block diagram of a node diagram surface modeling collaborative design processing device provided by an embodiment of the present invention;

[0034] Figure 8It is a schematic diagram of the hardware structure of an electronic device provided by an embodiment of the present invention. Detailed implementation manners

[0035] Next, the technical solutions of the present invention will be described clearly and completely with reference to the accompanying drawings. Apparently, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0036] An embodiment of the present invention provides a technical solution for a collaborative design method of node graph surface modeling, which is used to solve the problem that the existing surface modeling system does not provide the ability of collaborative design based on design history.

[0037] According to an embodiment of the present invention, an embodiment of a collaborative design method of node graph surface modeling is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order from here.

[0038] In this embodiment, a collaborative design method of node graph surface modeling is provided, which can be used for the above-mentioned mobile terminals, such as PCs, tablets, etc. Figure 1 It is a flowchart of a collaborative design method of node graph surface modeling according to an embodiment of the present invention, as Figure 1 shown, and the process includes the following steps:

[0039] Step 101: Obtain the main branch of the node graph surface modeling design and the first surface modeling graph.

[0040] Among them, the main branch includes: a first node and several nodes after the first node, and the first surface modeling graph is formed after all the nodes on the main branch are designed.

[0041] The main branch is a design history sequence. The design history sequence (DHS) is an important tool in the product design process, used to record and track the order and relevance of design decisions. It can help designers, engineers, and other relevant personnel understand the evolution process of the design, and support the evaluation, comparison, and improvement of the design. The design history sequence is usually represented in the form of a graph or a list, where each node represents a design decision or state, and the edges between the nodes represent the dependency or causal relationship between the design decisions. By analyzing the design history sequence, the key events, turning points, and decision paths in the design process can be understood, so as to better understand the formation process of the design.

[0042] In a collaborative design environment, the design history sequence can be used to coordinate design decisions among different designers, ensuring design continuity and consistency. It can also be used to evaluate the feasibility and rationality of the design, as well as to guide future design decisions. By integrating the design history sequence with version control, change management, and other related tools, the efficiency and accuracy of collaborative design can be further improved.

[0043] As an embodiment of the present invention, it is necessary to obtain the design history sequence of a surface modeling system. This sequence stores the historical nodes that have been designed previously. Through these historical nodes, the corresponding historical design operations and modification times can be found. These historical nodes are saved in the JSON (JavaScript Object Notation) format. The historical design operations and modification times are both recorded in a JSON Patch file. One design history node corresponds to one JSON Patch file, and the design history sequence can also be regarded as a JSON Patch collection.

[0044] A surface modeling system is a computer-aided design software used to create, modify, and analyze surfaces. The surface modeling system is usually based on the principles of computer graphics and uses mathematical and geometric methods to represent and model surfaces. In the field of architecture, the surface modeling system is used to create the appearance and detailed design of buildings. The surface modeling system is usually integrated with CAD software to achieve a more efficient design and manufacturing process. For example, CAD software can be used to create the initial geometric model of an object and then import it into the surface modeling system for further design and modification. The surface modeling system is a powerful computer-aided design tool that can be used to create, edit, analyze, and visualize complex surfaces to improve design efficiency and quality.

[0045] Among them, JSON is a lightweight data exchange format. It is based on a subset of ECMAScript (the JavaScript specification formulated by the European Computer Manufacturers Association) and uses a text format that is completely independent of programming languages to store and represent data. The simple and clear hierarchical structure makes JSON an ideal data exchange language. It is easy for humans to read and write, and at the same time, it is also easy for machines to parse and generate, effectively improving the network transmission efficiency.

[0046] JSON Patch is a format for describing changes made to a JSON document. JSON Patch itself is also a JSON structure. When only part of the document is changed, it can be used to avoid sending the entire document. When combined with the HTTP PATCH method, it allows for partial updates to HTTP APIs in a standards-compliant way. JSON Patch is specified in RFC6902 of the IETF.

[0047] Step 102: Receive a first merge request sent from a first client. The first merge request is sent after a first user performs surface modeling design modifications on a first node in the first client and generates a second node.

[0048] Specifically, when a first user modifies the design in the client, the client generates a new second node and sends this new node and the related first merge request to the server. After receiving this merge request, the server will perform corresponding processing.

[0049] The server includes the capabilities to accept create-from-branch requests, accept merge-from-branch requests, and detect merge conflicts. The client includes the capabilities to initiate create-from-branch requests, initiate merge-from-branch requests, detect merge conflicts, display conflict details including corresponding surface modeling operation information, and submit conflict-free design history.

[0050] The principles of merging include: Merging can only occur when merging the design history of a from-branch into the main branch; Merging is initiated by the user in the design client and implemented by the design server for branch merging; The design server only supports one merge request at a time. If the server is processing a merge request, a new merge request will fail and needs to wait until the server finishes processing the previous merge request before accepting a new merge request; The user of the branch currently being processed for a merge request can submit the merge request multiple times during the process of handling merge conflicts until the conflicts are resolved and the merge request is completed.

[0051] Step 103: If the priority of the first user is the highest priority, detect whether there are conflicts between the second node and several nodes located after the first node.

[0052] In a computer system, there are usually multiple user accounts, and the priorities of these accounts are different. From high to low, the priorities of common computer accounts are usually as follows: The system administrator account, also known as the superuser account. This is the highest-level account. The ordinary user account. This is the second-highest-level account and has certain permissions. The guest account. This is the lowest-level account.

[0053] Specifically, if the priority of the first user is set to the highest priority, then when receiving and processing the first merge request, the server will pay special attention to the conflict situation between the second node and subsequent nodes. This means that even if the priorities of other users may be the same as that of the first user, since the priority of the first user is the highest, the server will give priority to processing the request of the first user and check whether the second node conflicts with several nodes after the first node located on the main branch.

[0054] As an embodiment of the present invention, conflict detection is to determine whether there is the same file information between the file information of the branch node and several nodes after the first node. The file information is the JASON Patch file in the design history sequence. JASON usually stores data in the form of key:value key-value pairs. Among them, the path file is equivalent to the key in the JASON file, and the path records the file name and file path modified by this merge request. The system will determine whether the merge request of this application has the same file information as the requests that have been merged later.

[0055] Specifically, as Figure 2 shown, Figure 2 The main branch shown represents the design history sequence, Figure 2 The sub-branch shown represents the merge request. Design change A1 represents the second node, and design change A2 represents the fourth node. Among them, the design history sequence of the main branch is the design changes arranged according to the order of merging, and the design changes of the sub-branch are the order of merging arranged according to the user priority. For example, if it is preferred to merge design change A1 and it is applied to merge in from design change 3, then the system will check whether there is the same path in the JASON Patch file in design change A1 as the path in the JASON Patch file after design change 3.

[0056] Step 104: If there are no conflicts, then merge the second node after the several nodes on the main branch to generate a third node and obtain an updated main branch.

[0057] As an embodiment of the present invention, as Figure 3As shown, if the file information of the path in the JASON Patch file in Design Change A1 is not the same as that in the JASON Patch file after Design Change 3, it proves that there is no conflict between the files modified by Design Change A1 and those modified by Design Change 4, indicating that there is no conflict in this merge. Design Change A1 will then be merged into the tail of the main branch, i.e., after Design Change 4. Similarly, after Design Change A1 is merged, the system will re-check whether there is a conflict in Design Change A2. If there is no conflict, Design Change A2 will be merged into the end of the main branch to become the fourth node, as Figure 3 shown, Design Change A2 is merged behind Design Change A1 to become the fifth node.

[0058] The main branch is usually the default branch and is typically used for the release of stable versions. It usually contains the stable design of the entire project, and as the project continues to be developed, designs are continuously added to it. The updated main branch includes: the first node, several nodes, and the third node. The main branch is the final design result of the project. The main branch stores the design history of the project, which is the combined design history of multiple branches, i.e., the design histories of multiple users.

[0059] A feature branch is a branch created based on the main branch and is usually used for designing new features or conducting experimental designs. Feature branches allow developers to design outside the main branch, thus avoiding interference with the main branch. When the new feature design is completed, the feature branch can be merged into the main branch. For a feature branch, multiple users of the project can start from a certain design change in the main branch to create their own feature branches. A feature branch can only be created starting from a certain design change in the main branch.

[0060] During the design process, usually a new feature branch is created from a node in the main branch, and then development is carried out on the feature branch. When the design is completed, the feature branch can be merged into the main branch. During the merge process, if there is a conflict between the feature branch and the main branch, conflict resolution is required.

[0061] Step 105: Generate a second surface model diagram based on all the nodes on the updated main branch.

[0062] Specifically, when the server receives and finishes processing the first merge request, it will generate a second surface model diagram based on all the nodes on the updated main branch. This process can be understood as the server reconstructing a surface model diagram according to all the node information on the latest main branch, and this surface model diagram is the second surface model diagram. This second surface model diagram can be sent to the client so that users can see the latest design result on the client. Users can further modify or view the design result based on this surface model diagram.

[0063] As an embodiment of the present invention, this mechanism can be used in a 3D design system. When multiple users modify the same design, the system can determine the processing order according to the priorities of the users and the submission time, and generate the latest surface modeling diagram for users to view and further operate.

[0064] Optionally, in another embodiment, referring to Figure 4 , step 102 above specifically includes:

[0065] Step 401, receiving a second merge request sent by a second client. The second merge request is a request sent after a second user performs a surface modeling design modification on the first node in the second client and generates a fourth node.

[0066] Specifically, the server can accept one or more merge requests sent by the second client to meet the collaborative design requirements. The second merge request sent by the second client will generate a third node, which is in a parallel relationship with the second node. As Figure 2 shown in the design change A2, it is the second merge request sent by the second client.

[0067] This mechanism can be used in a multi-terminal interaction system. When multiple users modify the same design on different clients, the system can coordinate and manage these modifications by receiving and merging these merge requests to ensure data integrity and consistency. Each client can send a merge request to the server, and the server will determine the processing order according to the priority and submission time, and generate the latest design result.

[0068] Step 402, obtaining the priority of the second user.

[0069] Specifically, the server will obtain the user priority of the second user to prepare for subsequent judgments.

[0070] Step 403, comparing the priority of the second user with the priority of the first user.

[0071] Specifically, it is a process of comparing the priority of the second user with the priority of the first user.

[0072] Step 404, if the priority of the first user is higher than the priority of the second user, then perform the step of detecting whether there is a conflict between the second node and several nodes located after the first node.

[0073] This embodiment further includes: if the priority of the first user is lower than that of the second user, detecting whether there is a conflict between the fourth node and several nodes after the first node; if there is no conflict, merging the fourth node after the several nodes on the main branch to generate a fifth node, and obtaining an updated main branch; generating a third surface modeling diagram according to all the nodes on the updated main branch.

[0074] Specifically, when the priority of the first user is set to the highest priority, the system will perform specific conflict detection. If the priority of the first user is set to the highest, the system will detect whether there is a conflict between the second node generated by him and several nodes after the first node. As Figure 2 shown, if the design change A1 where the second node is the highest priority, the design change A1 will be compared with the path in the JASON file of the design change 4. Similarly, if the design change A2 where the fourth node is the highest priority, the design change A2 will be compared with the path in the JASON file of the design change 4.

[0075] As an embodiment of the present invention, this setting can be understood as a special treatment of the system for high-priority users. Since the priority of the first user is the highest, his modification request will be processed first. However, at the same time, to avoid conflicts between his modifications and those of other users, the system will perform additional conflict detection to check whether his second node conflicts with subsequent nodes on the main branch. This mechanism helps to ensure that the system can still maintain data consistency and integrity in the case of multiple users modifying simultaneously, preventing data errors or losses caused by conflicts. At the same time, by providing priority processing for high-priority users, the system can also meet the special needs of certain users or tasks.

[0076] Optionally, in another embodiment, referring to Figure 5 , step 402 above specifically includes:

[0077] Step 501, if the priority of the first user is the same as that of the second user, comparing the order of the first timestamp of the first merge request and the second timestamp of the second merge request.

[0078] A timestamp refers to a time-related number, usually representing the number of milliseconds elapsed from a certain fixed point in time to the current moment. Timestamps are usually used to record the time when an event occurs, calculate time intervals, perform time sorting, etc. It is a complete and verifiable piece of data that can represent that a piece of data has existed at a specific point in time. In this embodiment, the timestamp refers to the time when the first user and the second user send merge requests, and is used to determine which request arrives at the server first.

[0079] Specifically, obtain the first merge request and the first timestamp of the first user, and the second merge request and the second timestamp of the second user.

[0080] Step 502, if the first timestamp is before the second timestamp, then perform the step of detecting whether there is a conflict between the second node of the first user and several nodes after the first node located in the main branch.

[0081] This embodiment further includes: if the first timestamp is after the second timestamp, then perform the step of detecting whether there is a conflict between the fourth node of the second user and several nodes after the first node located in the main branch.

[0082] This embodiment is a special case. That is, when the priorities of the first user and the second user are the same, the system will perform specific conflict detection. If the priority of the first user is the same as that of the second user, and the request of the first user arrives at the server before the request of the second user, that is, the first timestamp is earlier than the second timestamp, then the system will detect whether there is a conflict between the second node of the first user and several nodes after the first node located in the main branch. This means that the request of the second user arrives later, but because their user priorities are the same, the system will still process the request of the first user first and check whether his modification conflicts with the modifications of other nodes. On the contrary, if the request of the second user arrives at the server before the request of the first user, and the priorities of the two requests are the same, then the system will detect whether there is a conflict between the third node of the second user and several nodes after the first node located in the main branch. This means that because their priorities are the same, the system will process the request of the second user first and check whether his modification conflicts with the modifications of other nodes.

[0083] As an implementation manner of the present invention, this first-come, first-served mechanism can be used in a node graph surface collaborative design system. When multiple users modify the same design, the system can determine the processing order by comparing the timestamps and priorities of user requests to avoid conflicts and data inconsistencies. Through this mechanism, the system can ensure that data consistency and integrity are still maintained when multiple users modify simultaneously.

[0084] Optionally, in another implementation manner, as Figure 6 shown, the above step 103 specifically further includes:

[0085] Step 601, obtain at least one preset format file of the second node and several nodes after the first node.

[0086] Among them, each of the preset format files includes: key-value pairs composed of a modification path and modification content.

[0087] The preset format file is a JASON Patch format file. Each node represents a design atomic change. The design atomic change refers to that in the process of implementing a node graph modeling system that supports design history, in each design change JSON Patch, each JSON Patch with only one operation action is defined as a design atomic change. Each slave branch is designed independently. After the user makes a design change, the user adds his own design change to form the design history of this slave branch. Each design change of the slave branch consists of smaller design atomic changes.

[0088] Specifically, in the collaborative design system, when generating nodes, the system will generate these JASON files according to certain rules and algorithms. The system can generate JASON Patch files regularly or when a specific event occurs. For example, when the user performs a modification operation on a branch, the system will record the modified file path in the path and the modification content in the value.

[0089] Step 602, determine whether the modification content of the modification path in the preset format file corresponding to the second node is the same as the modification content of the modification paths in the preset format files of several nodes after the first node.

[0090] Specifically, after obtaining the JASONPatch files of the second node of the slave branch and several nodes after the first node of the master branch, the system can further compare the Path and value information in these files to detect whether there are conflicts or other inconsistencies. For example, the system can determine whether the same file has been modified by two nodes by comparing whether there are the same paths in the Path.

[0091] Before the current atomic design change is merged into the current design history, use the TEST test operation to detect whether the Path path in the atomic design change exists in the current design history. If the path does not exist, return a conflict result.

[0092] Step 603, if so, determine that there is a conflict between the second node and several nodes after the first node.

[0093] Step 604, if not, determine that there is no conflict between the second node and several nodes after the first node.

[0094] Specifically, the system can determine whether the same file has been modified by two nodes by comparing whether there are the same paths in the comparison Path. If the same file has been modified by two nodes simultaneously, it is determined that there is a conflict between the two nodes. If the same file has not been modified by two nodes, it means that there is no conflict between the two nodes.

[0095] Optionally, in another embodiment, the above steps 101 to 105 specifically further include:

[0096] After the client makes a styling design modification operation on the first node of the copied main branch from the branch, a second node is generated, and a first merge request is sent to the design server.

[0097] Specifically, if there is a conflict, report the conflict situation of the design client and the candidate design history sequence. The design client starts from the conflicting design change and redesigns, and submits a design merge request.

[0098] The client will copy a copy from the main branch, and then make a styling design modification operation on the first node on this copied branch. This modification operation can be adding, deleting, or modifying design elements on the node, etc. After the modification is completed, the client will generate a new node, that is, the second node, and send a first merge request to the design server. This merge request usually contains detailed information about the modification, such as which nodes have been modified and what the modification content is. After receiving this merge request, the design server will update the corresponding nodes according to the information in the request and merge the updated branch into the main branch.

[0099] Optionally, in another embodiment, as Figure 1 shown, the above step 105 specifically includes:

[0100] Step 106, when it is determined that there is a conflict between the second node and several subsequent nodes of the first node, generate a conflict detection report and send the conflict detection report to the first client.

[0101] Specifically, when processing the merge request, if the system detects that there is the same path or file name as the JASON file of several nodes after the first node, this means that there may be a conflict. To solve this conflict, the system will generate a conflict detection report, which usually contains detailed information about the conflict, such as which nodes have conflicts and what the conflict content is. Once the conflict detection report is generated, the system will send the report to the client. After receiving the report, the user can view and resolve these conflicts. After resolving the conflicts, the user can submit the resolution results to the server, and the server will update the corresponding nodes and merge the updated branch into the main branch.

[0102] As an embodiment of the present invention, such a mechanism can be used in a node graph surface modeling collaborative system. When multiple users modify the same design on different clients, the system can detect whether the file exists and whether there are conflicts among the nodes to solve possible problems, so as to ensure the integrity and consistency of the data. Users can view and resolve conflicts through the client and submit the resolution results to the server to complete the merge operation.

[0103] The technical method of node graph surface modeling collaborative design provided in this embodiment has the following beneficial effects for surface modeling collaborative design:

[0104] 1. It realizes the design mode of node graph surface modeling collaborative design that supports multiple people to design simultaneously. Compared with binary surface data, it is difficult to distinguish the modeling operations performed by different users under the same project. This method improves the work efficiency of multi-person collaboration.

[0105] 2. This method enables node graph surface modeling collaborative design to support multiple people to design simultaneously, provides a visual conflict handling solution, and improves the efficiency of engineers in obtaining information.

[0106] In this embodiment, a device for node graph surface modeling collaborative design is also provided. This device is used to implement the node graph surface modeling collaborative design method in the above embodiment, and the parts that have been described will not be repeated. As used below, the term "unit" or "module" can be a combination of software and / or hardware that realizes a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0107] This embodiment provides a device for node graph surface modeling collaborative design, as Figure 7 shown. This device includes: an acquisition module 701, a reception module 702, a processing module 703, a judgment module 704, and a generation module 705. In addition, this device may further include more or fewer other units / modules, such as a storage module, etc., and this embodiment does not limit this.

[0108] Among them, the acquisition module 701 is used to acquire the main branch of the node graph surface modeling design and the first surface modeling graph. The main branch includes: a first node and several nodes located after the first node. The first surface modeling graph is formed after all the nodes on the main branch are designed.

[0109] The reception module 702 is used to receive a first merge request sent from a first client. The first merge request is a request sent after a first user performs a surface modeling design modification on the first node on the first client and generates a second node.

[0110] A processing module 703, configured to detect whether there is a conflict between the second node and several nodes located after the first node if the priority of the first user is the highest priority.

[0111] A judgment module 704, configured to, if there is no conflict, merge the second node after the several nodes on the main branch to generate a third node, and obtain an updated main branch.

[0112] A generation module 705, configured to generate a second surface modeling diagram according to all the nodes on the updated main branch.

[0113] In some alternative embodiments, the receiving module 702 is specifically configured to receive a second merge request sent by a second client, where the second merge request is a request sent after a second user generates a fourth node after performing a surface modeling design modification on the first node on the second client; obtain the priority of the second user; compare the priority of the second user with the priority of the first user; if the priority of the first user is higher than the priority of the second user, then perform the step of detecting whether there is a conflict between the second node and several nodes located after the first node.

[0114] In some alternative embodiments, the receiving module 702 is specifically further configured to detect whether there is a conflict between the fourth node and several nodes located after the first node if the priority of the first user is lower than the priority of the second user.

[0115] In some alternative embodiments, the receiving module 702 is specifically further configured to compare the sequence of the first timestamp of the first merge request and the second timestamp of the second merge request if the priority of the first user is the same as the priority of the second user; if the first timestamp is before the second timestamp, then perform the step of detecting whether there is a conflict between the second node of the first user and several nodes located after the first node on the main branch

[0116] In some alternative embodiments, the receiving module 702 is specifically further configured to, after the client performs a modeling design modification operation on the first node of the copied main branch on the sub-branch, generate a second node, and send a first merge request to the design server.

[0117] In some alternative embodiments, the processing module 703 is further specifically configured to obtain at least one preset format file of the second node and several nodes after the first node. Each preset format file includes key-value pairs composed of a modification path and modification content. It is determined whether the modification paths in the preset format file corresponding to the second node are the same as the modification paths in each preset format file of the several nodes after the first node. If so, it is determined that there is a conflict between the second node and the several nodes after the first node. If not, it is determined that there is no conflict between the second node and the several nodes after the first node.

[0118] In some alternative embodiments, the determination module 704 is further specifically configured to generate a conflict detection report and send the conflict detection report to the first client when it is determined that there is a conflict between the second node and the several nodes after the first node.

[0119] Please refer to Figure 8 , Figure 8 FIG. is a schematic structural diagram of an electronic device provided by an alternative embodiment of the present invention. As Figure 8 shown, the electronic device includes one or more processors 10, a memory 20, and interfaces for connecting various components, including a high-speed interface and a low-speed interface. Each component communicates with each other using different buses and can be installed on a common main board or installed in other ways as needed. The processor can process instructions executed within the electronic device, including instructions stored in the memory or on the memory to display graphical information of the GUI on an external input / output device. In some alternative embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple electronic devices can be connected, and each device provides some necessary operations. Figure 8 In

[0120] FIG., a single processor 10 is taken as an example.

[0121] The memory 20 stores instructions executable by at least one processor 10, so that the at least one processor 10 executes the methods shown in the above embodiments.

[0122] The memory 20 may include a program storage area and a data storage area. Among them, the program storage area can store an operating system and application programs required for at least one function; the data storage area can store data created according to the use of a computer device for collaborative design of a node graph surface model, etc. In addition, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state storage devices. In some alternative embodiments, the memory 20 may optionally include a memory remotely disposed relative to the processor 10, and these remote memories can be connected to the computer device through a network. Examples of the above-mentioned network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0123] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, a hard disk, or a solid-state drive; the memory 20 may further include a combination of the above types of memory.

[0124] The computer device further includes an input device 30 and an output device 40. The processor 10, the memory 20, the input device 30, and the output device 40 can be connected through a bus or other means. Figure 8 Taking connection through a bus as an example.

[0125] The input device 30 can receive input digital or character information and generate key signal inputs related to user settings and function controls of the computer device, such as a touch screen, a keypad, a mouse, a trackpad, a touchpad, a pointing stick, one or more mouse buttons, a trackball, a joystick, etc. The output device 40 may include a display device, an auxiliary lighting device, a tactile feedback device, etc. The above-mentioned display device includes but is not limited to a liquid crystal display, a light-emitting diode, a display, and a plasma display. In some alternative embodiments, the display device may be a touch screen.

[0126] Embodiments of the present invention also provide a computer-readable storage medium. The methods according to the embodiments of the present invention can be implemented in hardware, firmware, or be implemented as computer code that can be recorded on a storage medium, or be implemented by downloading over a network and originally stored in a remote storage medium or a non-transitory machine-readable storage medium and to be stored in a local storage medium, so that the methods described herein can be stored as such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only memory, a random access memory, a flash memory, a hard disk, or a solid-state drive, etc.; further, the storage medium can also include a combination of the above-mentioned types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code, and when the software or computer code is accessed and executed by the computer, the processor, or the hardware, the methods shown in the above embodiments are implemented.

[0127] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A collaborative design method for node graph surface modeling, characterized in that, The method includes: Obtain the main branch and the first surface modeling diagram of the node graph surface modeling design. The main branch includes: a first node and several nodes after the first node. The first surface modeling diagram is formed after designing all the nodes on the main branch; Receive a first merge request sent from a first client. The first merge request is a request sent after a first user performs surface modeling design modification on the first node on the first client and generates a second node; If the priority of the first user is the highest priority, then detect whether there is a conflict between the second node and several nodes after the first node; If there is no conflict, then merge the second node after the several nodes on the main branch to generate a third node and obtain an updated main branch; Generate a second surface modeling diagram according to all the nodes on the updated main branch.

2. The method according to claim 1, characterized in that, The method further includes: Receive a second merge request sent from a second client. The second merge request is a request sent after a second user performs surface modeling design modification on the first node on the second client and generates a fourth node; Obtain the priority of the second user; Compare the priority of the second user with the priority of the first user; If the priority of the first user is higher than the priority of the second user, then perform the step of detecting whether there is a conflict between the second node and several nodes after the first node.

3. The method according to claim 2, characterized in that, The comparing the priority of the second user with the priority of the first user further includes: If the priority of the first user is lower than the priority of the second user, then detect whether there is a conflict between the fourth node and several nodes after the first node; If there is no conflict, then merge the fourth node after the several nodes on the main branch to generate a fifth node and obtain an updated main branch; Generate a third surface modeling diagram according to all the nodes on the updated main branch.

4. The method according to claim 3, characterized in that, The comparing the priority of the second user with the priority of the first user further includes: If the priority of the first user is the same as the priority of the second user, then compare the sequence of the first timestamp of the first merge request and the second timestamp of the second merge request; If the first timestamp is before the second timestamp, then perform the step of detecting whether there is a conflict between the second node of the first user and several nodes after the first node on the main branch.

5. The method according to claim 4, characterized in that, The if the priority of the first user is the same as the priority of the second user further includes: If the first timestamp is after the second timestamp, then perform the step of detecting whether there is a conflict between the fourth node of the second user and several nodes after the first node on the main branch.

6. The method according to claim 1, characterized in that, The detecting whether there is a conflict between the second node and several nodes after the first node includes: Obtain at least one preset format file of the second node and several nodes after the first node. Each preset format file includes key-value pairs composed of a modification path and modification content. Determine whether the modification paths in the preset format file corresponding to the second node are the same as the modification paths in each preset format file of several nodes after the first node. If so, determine that there is a conflict between the second node and several nodes after the first node. If not, determine that there is no conflict between the second node and several nodes after the first node.

7. The method according to any one of the above claims 1, characterized in that, It further includes: In the case of determining that there is a conflict between the second node and several nodes after the first node, generate a conflict detection report and send the conflict detection report to the first client.

8. A collaborative design device for node graph surface modeling, characterized in that, The device includes: An obtaining module, configured to obtain a main branch of node graph surface modeling design and a first surface modeling graph. The main branch includes a first node and several nodes after the first node. The first surface modeling graph is formed after all nodes on the main branch are designed. A receiving module, configured to receive a first merge request sent from a first client. The first merge request is a request sent after a first user performs surface modeling design modification on the first node on the first client and generates a second node. A processing module, configured to detect whether there is a conflict between the second node and several nodes after the first node if the priority of the first user is the highest priority. A judging module, configured to, if there is no conflict, merge the second node after several nodes on the main branch to generate a third node and obtain an updated main branch. A generating module, configured to generate a second surface modeling graph according to all nodes on the updated main branch.

9. An electronic device, characterized in that, It includes a processor and a memory, and the memory is coupled to the processor. The memory stores computer-readable program instructions, and when the computer-readable program instructions are executed by the processor, the node graph surface modeling collaborative design method as described in any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium, on which a computer program is stored, characterized in that, When the computer program is executed by the processor, the node graph surface modeling collaborative design method as described in any one of claims 1 to 7 is implemented.

Images