Object-driven model reconstruction method and device, storage medium and electronic equipment
By reconstructing object-driven models in different modeling software and utilizing driver code and expression sets, the problem of low efficiency in object-driven model creation is solved, achieving efficient and consistent driving effects across software and incremental driving of user-defined logic.
Patent Information
- Application Number
- CN202410752898.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-06-11
- Publication Date
- 2025-12-12
AI Technical Summary
Existing object-driven models are inefficient to create in different modeling software, requiring the development of identical virtual object models separately to achieve the same driving effect.
By acquiring the set of driving information that matches the first object-driven model, separating the preset driving relationship and the custom driving relationship, and generating a set of driving code and a set of target expressions, the matching information set with the second object-driven model is reconstructed, ensuring consistent driving effects in different modeling software.
It enables efficient reconstruction of object-driven models in different modeling software, avoids redundant development, improves creation efficiency, and supports cross-software operation of user-defined driving logic.
Smart Images

Figure CN121120875A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computers, and more specifically, to a method and apparatus for reconstructing an object-driven model, a storage medium, and an electronic device. Background Technology
[0002] To achieve drive control of virtual objects in a virtual scene, it is usually necessary to determine an object model that matches the virtual object in the modeling software, and to determine the mapping relationship between control information and drive information in the object model.
[0003] In the development of virtual scenes, it is sometimes necessary to develop similar or identical virtual scenes and virtual objects using different modeling software. Since the driving methods and object nodes used to implement these drivers differ across modeling software, to achieve the same driving effect in different software, it is necessary to develop two object-driven models corresponding to the same virtual object in each modeling software. In other words, the existing methods for creating object-driven models are inefficient.
[0004] There is currently no effective solution to the above problems. Summary of the Invention
[0005] This invention provides a method and apparatus for reconstructing an object-driven model, a storage medium, and an electronic device, to at least solve the technical problem of low efficiency in object-driven model creation methods.
[0006] According to one aspect of the present invention, a method for reconstructing an object-driven model is provided, comprising: acquiring a first driving information set matching a first object-driven model, wherein the first object-driven model is used to drive a target virtual object according to control instructions received in a first object-driven tool, and the first driving information set is used to indicate the driving relationship between the control instructions and object actions performed by the target virtual object; acquiring a first driving node set and a second driving node set from the first driving information set, wherein the first driving node set is used to indicate a preset driving relationship provided by the first object-driven tool, and the second driving node set is used to indicate a custom driving relationship included in the first object-driven model; generating a driving code set according to the first driving node set, and generating a target expression set according to the second driving node set, wherein the driving code set includes driving codes corresponding to a plurality of driving nodes in the first driving node set, and the target expression set includes driving expressions used to indicate the custom driving relationships; determining a second driving information set matching a second object-driven model according to the driving code set and the target expression set, wherein the second object-driven model is used to drive the target virtual object according to the control instructions received in a second object-driven tool.
[0007] According to another aspect of the present invention, a method for driving a virtual object is provided, comprising: acquiring a second driving information set matching a second object driving model in a second object driving tool, wherein the second driving information set is determined based on a driving code set and a target expression set, the driving code set is generated based on a first driving node set included in a first driving information set matching a first object driving model, the target expression set is generated based on a second driving node set included in the first driving information set, the first driving node set is used to indicate a preset driving relationship provided by a first object driving tool, and the second driving node set is used to indicate a custom driving relationship included in the first object driving model; responding to receiving an initial driving parameter set carried by a control command, determining a first target driving parameter set based on the initial driving parameter set and the driving code set, and determining a second target driving parameter set based on the initial driving parameter set and the target expression set; determining object transformation information of at least one second skeleton object in the second object driving model based on the first target driving parameter set and the second target driving parameter set; and driving the target virtual object in the second object driving tool based on the object transformation information of at least one second skeleton object.
[0008] According to another aspect of the present invention, an object-driven model reconstruction apparatus is also provided, comprising: a first acquisition unit, configured to acquire a first driving information set matching a first object-driven model, wherein the first object-driven model is used to drive a target virtual object according to control instructions received in a first object-driven tool, and the first driving information set is used to indicate the driving relationship between the control instructions and the object actions performed by the target virtual object; and a second acquisition unit, configured to acquire a first driving node set and a second driving node set from the first driving information set, wherein the first driving node set is used to indicate a preset driving relationship provided by the first object-driven tool, and the second driving node set is used to indicate... The first object-driven model includes a custom driving relationship; a reconstruction unit is used to generate a set of driving codes based on the first set of driving nodes and a set of target expressions based on the second set of driving nodes, wherein the set of driving codes includes driving codes corresponding to multiple driving nodes in the first set of driving nodes, and the set of target expressions includes driving expressions used to indicate the custom driving relationship; a determination unit is used to determine a second set of driving information matching the second object-driven model based on the set of driving codes and the set of target expressions, wherein the second object-driven model is used to drive the target virtual object according to the control instructions received in the second object-driven tool.
[0009] Optionally, the reconstruction unit includes: a traversal module, configured to generate a first subset of driving code based on the traversal results of multiple driving nodes in the first set of driving nodes, wherein the first subset of driving code is used to determine reference driving parameters based on initial driving parameters, and the reference driving parameters are used to drive a first skeleton object in the first object-driven model in the first object-driven tool; a conversion module, configured to obtain a second subset of driving code based on the object coordinate transformation relationship between the first object-driven tool and the second object-driven tool, wherein the second subset of driving code is used to convert the reference driving parameters into target driving parameters, and the target driving parameters are used to drive a second skeleton object in the second object-driven model in the second object-driven tool; and a determination module, configured to determine the set of driving code based on the first subset of driving code and the second subset of driving code.
[0010] Optionally, the traversal module is configured to: obtain a node relationship graph matching the first set of driving nodes, wherein the node relationship graph includes multiple driving node objects and node dependency relationships between the driving node objects; in the parent and child driving node objects with the node dependency relationships, the parent driving node object is used to obtain a second driving calculation result based on the first driving calculation result output by the child driving node object; the leaf nodes in the node relationship graph are controller node objects, and the root node in the node relationship graph is the first skeleton object; traverse the multiple driving node objects in the node relationship graph sequentially according to the node hierarchy from low to high; store the calculation code corresponding to each driving node object according to a first queue based on the traversal results of the driving node objects, wherein during the operation of the second object driving tool, the first queue is used to call the calculation code corresponding to each driving node object, and the calculation result corresponding to each driving node object is stored according to the created second queue; and determine the multiple calculation codes matching the first queue as the first set of driving codes.
[0011] Optionally, the above-mentioned conversion module is used to: determine the first coordinate conversion code included in the second driving code subset based on the first object coordinate conversion relationship indicated by the coordinate axis sequence corresponding to the first object driving tool and the second object driving tool respectively; determine the second coordinate conversion code included in the second driving code subset based on the second object coordinate conversion relationship indicated by the length unit corresponding to the first object driving tool and the second object driving tool respectively; and determine the third coordinate conversion code included in the second driving code subset based on the third object coordinate conversion relationship indicated by the initial angle of the skeletal object corresponding to the first object driving tool and the second object driving tool respectively.
[0012] Optionally, the determining module is configured to: generate a third subset of driving code based on the parameter interface provided by the second object driving tool, wherein the third subset of driving code is used to obtain the initial driving parameters from the second object driving tool according to control instructions; update the calculation code associated with the second skeleton object in the first subset of driving code based on the second subset of driving code; and determine the updated first subset of driving code and the third subset of driving code as the driving code set.
[0013] Optionally, the reconstruction unit includes: an acquisition module, configured to acquire at least one node chain included in the second driver node set, wherein the node chain is used to indicate at least one driver node object associated with the custom driver relationship; an expression conversion module, configured to convert the custom driver relationship indicated by at least one of the node chains into at least one target expression included in the target expression set; and an adding module, configured to add at least one of the target expressions to a target expression file in a target format, wherein the target expression file is used to describe the custom driver relationship in the second object-driven tool.
[0014] Optionally, the expression conversion module is configured to: when the node chain includes multiple second reference driver objects for driving the first bone object, create a first target bone object matching the first bone object, and a second target driver object matching the multiple second reference driver objects, wherein the second target driver object is configured with multiple object attributes corresponding to the multiple second reference driver objects respectively, and the object attributes are used to store the attribute values transmitted by the corresponding second reference driver objects; and create a driving expression determined based on the multiple object attributes, wherein the driving expression is used to determine a target attribute value according to the attribute values of the multiple object attributes, and the target attribute value is used to drive the first target bone object in the second object driving tool.
[0015] Optionally, the above-mentioned adding module is also used for at least one of the following: adding attribute identification information associated with the above-mentioned node chain to the above-mentioned target expression file; adding value domain information matching the above-mentioned target expression to the above-mentioned target expression file.
[0016] Optionally, the above-described object-driven model reconstruction apparatus is further configured to: in response to an editing operation on the second set of driving nodes, obtain a third set of driving nodes updated according to the second set of driving nodes; generate an updated set of target expressions according to the third set of driving nodes; and determine a second set of driving information for indicating the second object-driven model according to the set of driving codes and the updated set of target expressions.
[0017] Optionally, the object-driven model reconstruction device described above is further configured to: determine, based on the first set of driving skeleton objects, the first set of skinned mesh objects, and the first skinned weight information included in the first object-driven model, as the second set of driving skeleton objects, the second set of skinned mesh objects, and the second skinned weight information included in the second object-driven model; and determine the second object-driven model based on the second set of driving skeleton objects, the second set of skinned mesh objects, the second skinned weight information, and the second set of driving information.
[0018] According to another aspect of the present invention, a driving device for a virtual object is also provided, comprising: an acquisition unit, configured to acquire a second driving information set matching a second object driving model in a second object driving tool, wherein the second driving information set is determined based on a driving code set and a target expression set, the driving code set is generated based on a first driving node set included in a first driving information set matching a first object driving model, the target expression set is generated based on a second driving node set included in the first driving information set, the first driving node set is used to indicate a preset driving relationship provided by a first object driving tool, and the second driving node set is used to indicate a custom driving relationship included in the first object driving model; a receiving unit, configured to, in response to receiving an initial driving parameter set carried by a control command, determine a first target driving parameter set based on the initial driving parameter set and the driving code set, and determine a second target driving parameter set based on the initial driving parameter set and the target expression set; a determining unit, configured to determine object transformation information of at least one second skeleton object in the second object driving model based on the first target driving parameter set and the second target driving parameter set; and a driving unit, configured to drive the target virtual object in the second object driving tool based on the object transformation information of at least one second skeleton object.
[0019] According to another aspect of the present invention, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, wherein the computer program is configured to execute the above-described object-driven model reconstruction method or the above-described virtual object driving method at runtime.
[0020] According to another aspect of the embodiments of this application, a computer program product is provided, the computer program product including a computer program / instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer program / instructions from the computer-readable storage medium, and executes the computer program / instructions, causing the computer device to perform a reconstruction method of the object-driven model as described above or a driving method for virtual objects as described above.
[0021] According to another aspect of the present invention, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the object-driven model reconstruction method or the virtual object driving method described above through the computer program.
[0022] In this embodiment of the invention, a first driving information set matching a first object-driven model is obtained; a first driving node set and a second driving node set are obtained from the first driving information set, wherein the first driving node set is used to indicate a preset driving relationship provided by a first object-driven tool, and the second driving node set is used to indicate a custom driving relationship included in the first object-driven model; a driving code set is generated based on the first driving node set, and a target expression set is generated based on the second driving node set; a second driving information set matching a second object-driven model is determined based on the driving code set and the target expression set, wherein the second object-driven model is used to drive a target virtual object according to control instructions received in the second object-driven tool, thereby realizing the reconstruction of a second driving information set for driving a target virtual object in the second object-driven tool based on the first driving information set of the first object-driven model created in the first object-driven tool, avoiding repeated development of object-driven models for the same virtual object in different object-driven tools, and improving the creation efficiency of object-driven models.
[0023] In the above embodiments, a set of driver code for running in a second object-driven tool can be generated based on a set of first driver nodes in the first driver information set that indicate preset driver relationships in the first object-driven tool. A set of target expressions can be generated based on a set of second driver nodes in the first driver information set that indicate user-defined driver relationships. The original driver relationships in the second object-driven tool are replaced by the set of driver code running in the second object-driven tool and the set of target expressions. Furthermore, the user-defined driver relationships can be represented based on the set of target expressions to enable cross-software execution of user-added incremental driver logic. While ensuring consistent driver effects in two different object-driven tools, the efficiency of object-driven operations is improved by running the set of driver code, thereby achieving efficient reconstruction of the object-driven model and solving the technical problem of low efficiency in object-driven model creation methods. Attached Figure Description
[0024] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:
[0025] Figure 1 This is a schematic diagram of the hardware environment for an optional object-driven model reconstruction method according to an embodiment of the present invention;
[0026] Figure 2 This is a flowchart of an optional object-driven model reconstruction method according to an embodiment of the present invention;
[0027] Figure 3This is a schematic diagram of an optional object-driven model reconstruction method according to an embodiment of the present invention;
[0028] Figure 4 This is a schematic diagram of another optional object-driven model reconstruction method according to an embodiment of the present invention;
[0029] Figure 5 This is a schematic diagram of another optional object-driven model reconstruction method according to an embodiment of the present invention;
[0030] Figure 6 This is a schematic diagram of another optional object-driven model reconstruction method according to an embodiment of the present invention;
[0031] Figure 7 This is a schematic diagram of another optional object-driven model reconstruction method according to an embodiment of the present invention;
[0032] Figure 8 This is a flowchart of an optional virtual object driving method according to an embodiment of the present invention;
[0033] Figure 9 This is a schematic diagram of the interface of an optional object-driven model reconstruction plugin according to an embodiment of the present invention;
[0034] Figure 10 This is a schematic diagram of the interface of another optional object-driven model reconstruction plugin according to an embodiment of the present invention;
[0035] Figure 11 This is a flowchart of another optional object-driven model reconstruction method according to an embodiment of the present invention;
[0036] Figure 12 This is a schematic diagram of the structure of an optional object-driven model reconstruction device according to an embodiment of the present invention;
[0037] Figure 13 This is a schematic diagram of the structure of an optional electronic device according to an embodiment of the present invention;
[0038] Figure 14 This is a schematic diagram of the structure of an optional virtual object driving device according to an embodiment of the present invention;
[0039] Figure 15 This is a schematic diagram of the structure of an optional electronic device according to an embodiment of the present invention. Detailed Implementation
[0040] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.
[0041] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0042] The following explains the technical terms used in this application:
[0043] Binding conversion: The operation of converting a bound asset from one 3D animation software format to an asset in another software format while maintaining consistent binding effects;
[0044] Rigging template: Pre-built rigging structure (rigging bone hierarchy, animation controller panel) and controller-bone / fusion deformation driving relationship;
[0045] Core driver: The mapping relationship from animation controller transformation to bone transformation / fusion deformation weights.
[0046] According to one aspect of the present invention, a method for reconstructing an object-driven model is provided. This method can be applied, but is not limited to, to applications such as... Figure 1The illustrated hardware environment includes an object-driven model reconstruction system, which may include, but is not limited to, terminal device 102, network 104, server 106, database 108, and terminal device 110. Terminal device 102 runs an object-driven model creation client, and terminal device 110 runs a client for driving rendering of virtual objects in a virtual scene. Terminal devices 102 and 110 each include a human-computer interaction screen, a processor, and a memory. The human-computer interaction screen displays the virtual scene and provides a human-computer interaction interface to receive human-computer interaction operations for controlling controlled virtual objects in the virtual scene, which will complete game tasks set in the virtual scene. The processor generates interaction instructions in response to the aforementioned human-computer interaction operations and sends these instructions to the server. The memory stores relevant attribute data, such as object attribute information of the controlled virtual objects and attribute information of the virtual props they hold. This attribute information may include, but is not limited to, information used to identify their identity and current location. Terminal device 102 runs an object-driven model creation client for creating a second object-driven model.
[0047] In addition, server 106 includes a processing engine for performing store or read operations on database 108. Specifically, the processing engine reads the object-driven model corresponding to each virtual object from database 108.
[0048] Assumption Figure 1The terminal device 102 runs a client for creating an object-driven model, and the terminal device 110 runs a client for rendering virtual objects in a virtual scene. The specific process of this embodiment is as follows: Steps S102 to S108 are executed through the terminal device 102 to obtain a first driving information set matching the first object-driven model. The first object-driven model is used to drive the target virtual object according to control instructions received in the first object-driven tool, and the first driving information set is used to indicate the driving relationship between the control instructions and the object actions performed by the target virtual object. A first driving node set and a second driving node set are obtained from the first driving information set. The first object-driven tool provides a preset driving relationship, and the second driving node set indicates the custom driving relationship included in the first object-driven model. A driving code set is generated based on the first driving node set, and a target expression set is generated based on the second driving node set. The driving code set includes driving codes corresponding to multiple driving nodes in the first driving node set, and the target expression set includes driving expressions indicating custom driving relationships. A second driving information set matching the second object-driven model is determined based on the driving code set and the target expression set. The second object-driven model is used to drive the target virtual object according to control instructions received in the second object-driven tool.
[0049] Next, step S110 is executed in terminal device 102, and the second object-driven model is sent to server 106 via network 104. Then, server 106 forwards the second object-driven model to terminal device 110 via network 104; finally, step S114 is executed in the target client running in terminal device 110, and the target virtual object is driven based on the second object-driven model.
[0050] Optionally, in this embodiment, the terminal device 110 can be a terminal device configured with a target client, which may include, but is not limited to, at least one of the following: mobile phone (such as Android phone, iOS phone, etc.), laptop computer, tablet computer, PDA, MID (Mobile Internet Devices), PAD, desktop computer, smart TV, etc. The target client can be a video client, instant messaging client, browser client, educational client, or other client that supports providing shooting game tasks. The network may include, but is not limited to, wired network and wireless network, wherein the wired network includes: local area network, metropolitan area network, and wide area network, and the wireless network includes: Bluetooth, WIFI, and other networks that enable wireless communication. The server may be a single server, a server cluster composed of multiple servers, or a cloud server. The above is only an example, and no limitation is made in this embodiment.
[0051] Optionally, in this embodiment, the second object-driven model obtained according to the above-described object-driven model reconstruction method can be applied, but is not limited to, to game-type terminal applications (APPs) that complete predetermined social game tasks in a virtual scene, such as virtual combat game applications in Multiplayer Online Battle Arena (MOBA) applications. The aforementioned social game tasks can be, but are not limited to, game tasks completed by the current player through virtual social interaction between virtual characters in the reconstructed virtual scene and virtual characters controlled by other players. The above-described object-driven model reconstruction method can also be applied to large-scale multiplayer online role-playing game (MMORPG) terminal applications, where the current player can complete social game tasks from the first-person perspective of a virtual character through role-playing, for example, completing game tasks together with other virtual characters. These social game tasks can, but are not limited to, run as plugins or mini-programs within an application (such as a non-standalone game APP), or run within a game engine within an application (such as a standalone game APP). The types of game applications mentioned above may include, but are not limited to, at least one of the following: two-dimensional (2D) game applications, three-dimensional (3D) game applications, virtual reality (VR) game applications, augmented reality (AR) game applications, and mixed reality (MR) game applications. This is merely an example, and this embodiment does not impose any limitations on it.
[0052] In this embodiment of the invention, a first driving information set matching a first object-driven model is obtained; a first driving node set and a second driving node set are obtained from the first driving information set, wherein the first driving node set is used to indicate a preset driving relationship provided by a first object-driven tool, and the second driving node set is used to indicate a custom driving relationship included in the first object-driven model; a driving code set is generated based on the first driving node set, and a target expression set is generated based on the second driving node set; a second driving information set matching a second object-driven model is determined based on the driving code set and the target expression set, wherein the second object-driven model is used to drive a target virtual object according to control instructions received in the second object-driven tool, thereby realizing the reconstruction of a second driving information set for driving a target virtual object in the second object-driven tool based on the first driving information set of the first object-driven model created in the first object-driven tool, avoiding repeated development of object-driven models for the same virtual object in different object-driven tools, and improving the creation efficiency of object-driven models.
[0053] In the above embodiments, a set of driver code for running in a second object-driven tool can be generated based on a set of first driver nodes in the first driver information set that indicate preset driver relationships in the first object-driven tool. A set of target expressions can be generated based on a set of second driver nodes in the first driver information set that indicate user-defined driver relationships. The original driver relationships in the second object-driven tool are replaced by the set of driver code running in the second object-driven tool and the set of target expressions. Furthermore, the user-defined driver relationships can be represented based on the set of target expressions to enable cross-software execution of user-added incremental driver logic. While ensuring consistent driver effects in two different object-driven tools, the efficiency of object-driven operations is improved by running the set of driver code, thereby achieving efficient reconstruction of the object-driven model and solving the technical problem of low efficiency in object-driven model creation methods.
[0054] As an optional implementation method, such as Figure 2 As shown, the object-driven model reconstruction method described above includes the following steps:
[0055] S202, Obtain a first driving information set that matches the first object driving model, wherein the first object driving model is used to drive a target virtual object according to control instructions received in the first object driving tool, and the first driving information set is used to indicate the driving relationship between the control instructions and the object actions performed by the target virtual object;
[0056] S204, obtain a first set of driving nodes and a second set of driving nodes from the first set of driving information, wherein the first set of driving nodes is used to indicate the preset driving relationship provided by the first object driving tool, and the second set of driving nodes is used to indicate the custom driving relationship included in the first object driving model.
[0057] S206, Generate a set of driver code based on the first set of driver nodes, and generate a set of target expressions based on the second set of driver nodes, wherein the set of driver code includes driver code corresponding to a plurality of driver nodes in the first set of driver nodes, and the set of target expressions includes driver expressions used to indicate the custom driver relationship;
[0058] S208, determine a second driving information set that matches the second object driving model based on the driving code set and the target expression set, wherein the second object driving model is used to drive the target virtual object according to the control instructions received in the second object driving tool.
[0059] It should be noted that, in some optional implementations, the first object-driven tool and the second object-driven tool mentioned above can be two different 3D modeling tools for creating object-driven models. The object-driven models created using the first and second object-driven tools can be used to render and drive virtual objects in various scenarios such as video games, movies, and television. The first object-driven model created by the first object-driven tool and the second object-driven model created by the second object-driven tool can include a set of driving node objects for determining driving information according to control instructions, and a set of skinned mesh objects for determining the spatial displacement of each point on the surface of the virtual object according to the driving information. Furthermore, in the process of determining the spatial displacement of each skinned mesh according to the driving information, the spatial displacement of each skinned mesh object can be further determined by combining the skinning weight information with the driving information.
[0060] The following combination Figure 3 An alternative object-driven model is described. For example... Figure 3As shown, the object-driven model includes at least a set of driving nodes 304 and a skin mesh 306. The set of driving nodes 304 is used to transmit and transform driving information according to the connection relationship between driving nodes, and the skin mesh 306 is used to determine the displacement information of the target skin mesh rendered on the virtual object according to the driving information output by node 1. More specifically, when the object-driven model receives control instruction 302 (e.g., a control instruction to "control the virtual object to make a smiling expression"), it then determines the initial driving information received by each node based on control instruction 302. That is, multiple leaf nodes, including node 10, node 11, and node 12, receive the initial driving information determined by control instruction 302. Based on the driving mode corresponding to each node, it determines the intermediate driving information received by the next level node connected to it. Finally, it determines the target driving information output by the binding layer node (i.e., node 1) connected to the skinned mesh 306. The target driving information can be used to indicate the displacement, rotation, scaling, and other changes of the binding layer skeleton in the virtual space. Then, based on the binding mapping relationship between the target driving information output by node 1 and the skinned mesh 306, it determines the displacement information of the object surface, including the skinned mesh 306, on the virtual object. It is understandable that the binding mapping relationship between the target driving information output by node 1 and the skin mesh 306 can be determined based on the skin weight information mentioned above. Furthermore, when the displacement information of the skin mesh 306 is determined based on multiple binding layer nodes, the displacement information of the skin mesh 306 can be determined based on the weight information corresponding to each binding layer node and the target driving information mentioned above.
[0061] It is understandable that the set of driver nodes included in the initial object-driven model created in different object-driven tools can vary significantly. For example, the types and numbers of nodes in the driver node sets may differ, and the methods of passing driver information between nodes may also differ. Therefore, if it is necessary to create driver models for the same virtual object based on different object-driven tools, the existing approach requires developing driver models separately for the tool characteristics of each object-driven tool, resulting in low efficiency in driver model creation.
[0062] The above embodiments of this application provide a method for creating a second driving information set that matches a second object driving model based on a first driving information set that matches a first object driving model, so as to enable the target virtual object to perform the same driving action based on the same driving instructions in different object driving tools.
[0063] The first object tool and the second object tool mentioned above may include, but are not limited to, any two different modeling tools such as Autodesk Maya modeling tool, Autodesk 3ds Max modeling tool, Unreal Engine modeling tool, and Unity 3D. In the embodiments of this application, the specific types of the first object tool and the second object tool mentioned above are not limited.
[0064] Specifically, in step S202 above, a first driving information set matching the first object-driven model can be obtained first. This first driving information set may include a first driving node set, a first driving skeleton object set, a first skinned mesh object set, and first skinned weight information. Specifically, the aforementioned first driving node set may be as follows: Figure 3 The set of driving nodes 304 shown is used to convert control command 302 into target driving information. The first set of driving bone objects can be used to indicate the binding layer bone objects included in the first driving model. The first set of skinned mesh objects can be used to indicate the skinned mesh objects associated with the binding layer bone objects in the first driving model. Based on the binding layer bone objects and the skinned mesh objects, the rendering model corresponding to the target virtual object can be determined in the virtual space. Then, according to the target driving information determined by the first set of driving nodes and the first skinned weight information, the target virtual object is driven to perform corresponding virtual actions or virtual expressions in the virtual space.
[0065] Furthermore, in step S204 above, the driving relationship between the control command and the object action of the target virtual object can be divided into a preset driving relationship and a custom driving relationship. The preset driving relationship can be determined according to the first set of driving nodes included in the object driving model template provided by the first object driving tool, and the custom driving relationship can be determined according to the second set of driving nodes obtained by the user.
[0066] Furthermore, in step S206, different reconstruction methods can be applied to the aforementioned sets of driving nodes used to represent different types of driving relationships to improve the flexibility of the reconstruction process. It is understood that in the process of creating different object-driven models based on the aforementioned first object-driven tool, the first set of driving nodes provided by the first object-driven tool to indicate preset driving relationships is usually frequently reused in different object-driven models; while users, in order to reflect the differences between the object-driven models corresponding to different virtual objects, can generate different second driving nodes according to custom editing methods. Therefore, in step S206, custom driving relationships can be represented according to the target expression set to achieve cross-software operation of incremental driving logic added by the user, while ensuring consistent driving effects in two different object-driven tools. This improves object-driven efficiency through the execution of the driving code set, thereby achieving efficient reconstruction of the object-driven model.
[0067] In an optional implementation, the above-mentioned determination of the second driver information set matching the second object-driven model based on the driver code set and the target expression set further includes:
[0068] S1, based on the first set of driving skeleton objects, the first set of skin mesh objects, and the first skin weight information included in the first object-driven model, the second set of driving skeleton objects, the second set of skin mesh objects, and the second skin weight information included in the second object-driven model are determined;
[0069] S2, determine the second object-driven model based on the second set of driving skeleton objects, the second set of skinned mesh objects, the second skinned weight information, and the second driving information set.
[0070] The above implementation method will be described below using Autodesk Maya (hereinafter referred to as Maya tool) as the first object-driven tool and Autodesk 3ds Max (hereinafter referred to as 3ds Max tool) as the second object-driven tool.
[0071] After generating the rigging template, matching the custom character head model, and processing the skin weights using the Maya toolset, only the skin skeleton (i.e., the aforementioned first driving skeleton object set) and the model mesh (i.e., the aforementioned first skin mesh object set) are retained and exported in FBX format. The skin weights (i.e., the aforementioned first skin weight information) export tool in the toolset is then used to export the skin weight information as a data file with the .w extension. These two files will serve as the data required to convert and obtain the corresponding second driving information set in 3ds Max.
[0072] Next, after obtaining the aforementioned FBX file and .w skinning weight file in the reconstruction software, the rigging driver can be reconstructed based on these files. Specifically, the 3D model created in Maya can be reconstructed using the FBX file. Based on the first driver information set indicated by the FBX file, a second driver information set is determined. Then, the core driver logic of the animation controller – skeleton / fusion deformation – in Maya is replaced with an equivalent driver code set to achieve cross-software portability of the face rigging template calculation system. For driver calculation logic other than the core driver, it is replaced with equivalent mathematical functions using expressions to enable cross-software operation of user-added incremental driver logic.
[0073] In one optional implementation, the above-mentioned generation of the driver code set based on the first driver node set includes:
[0074] S1, Generate a first driving code subset based on the traversal results of multiple driving nodes in the first driving node set, wherein the first driving code subset is used to determine reference driving parameters based on the initial driving parameters, and the reference driving parameters are used to drive the first skeleton object in the first object driving model in the first object driving tool;
[0075] S2, based on the object coordinate transformation relationship between the first object-driven tool and the second object-driven tool, obtain a second driving code subset, wherein the second driving code subset is used to convert the reference driving parameters into target driving parameters, and the target driving parameters are used to drive the second skeleton object in the second object-driven model in the second object-driven tool;
[0076] S3, determine the driver code set based on the first driver code subset and the second driver code subset.
[0077] The traversal results in the above steps may include, but are not limited to, the node traversal results obtained by the breadth-first traversal algorithm or the node traversal results obtained by the depth-first traversal algorithm. In this embodiment, the method of obtaining the above traversal results is not limited.
[0078] It should be noted that, in this embodiment, the first subset of driving code can be determined first based on the traversal results in the first set of driving nodes; then, the second subset of driving code can be obtained based on the object coordinate transformation relationship between the first object driving tool and the second object driving tool; finally, the above-mentioned set of driving code can be determined based on the first subset of driving code and the second subset of driving code.
[0079] It is understood that the aforementioned first subset of driving code can be used to determine reference driving parameters based on initial driving parameters. These initial driving parameters can be control parameters determined according to control instructions, and the reference driving parameters for driving the first bone object are determined based on these control parameters. It should be noted that the aforementioned first bone object can be a bound layer bone object in the aforementioned first object driving tool, that is, a bone object used to determine the driving result of the skinned mesh in the first object driving tool. In other words, in step S1 above, the driving result of the corresponding bound layer bone object in the first object driving tool can be reconstructed based on the aforementioned first subset of driving code.
[0080] However, since the control coordinate systems configured for each object may differ in different object-driven tools, the coordinate transformation result of the reference driving parameters, i.e. the target driving parameters, can be obtained through the second driving code subset in step S2 above. This is used to drive the binding layer bone object, i.e. the second bone object, in the second object-driven tool, thereby restoring the same driving result as in the first object-driven tool in the second object-driven tool.
[0081] Through the above-described embodiments of this application, a first subset of driving code is generated based on the traversal results of multiple driving nodes in the first set of driving nodes; and a second subset of driving code is obtained based on the object coordinate transformation relationship between the first object driving tool and the second object driving tool; finally, a set of driving code is determined based on the first subset of driving code and the second subset of driving code, and then the same driving result as in the first object driving tool can be restored in the second object driving tool based on the above set of driving code, thereby improving the creation efficiency of the object driving model.
[0082] In one optional implementation, generating the first driver code subset based on the traversal results of multiple driver nodes in the first driver node set includes:
[0083] S1, obtain the node relationship graph that matches the first set of driving nodes. The node relationship graph includes multiple driving node objects and the node dependency relationship between driving node objects. Among the parent driving node object and child driving node object with node dependency relationship, the parent driving node object is used to obtain the second driving calculation result based on the first driving calculation result output by the child driving node object. The leaf node in the node relationship graph is the controller node object, and the root node in the node relationship graph is the first skeleton object.
[0084] S2, traverse multiple driver node objects in the node relationship graph in order from low to high node hierarchy;
[0085] S3, based on the traversal results of the driver node objects, the calculation code corresponding to each driver node object is stored in the first queue respectively. During the operation of the second object driving tool, the first queue is used to call the calculation code corresponding to each driver node object, and the calculation results corresponding to each driver node object are stored in the created second queue.
[0086] S4, identify the multiple computation codes that match the first queue as the first driver code subset.
[0087] In another alternative implementation, when obtaining the multiple driver node objects using a breadth-first traversal algorithm, a stack data structure can be used to record the call relationships between the code instances corresponding to each traversed driver node object. For example, the controller transformation node at the head of the node chain in the node relationship graph can be pushed onto the stack sequentially to the skeletal node at the tail. During execution, a recursive algorithm is used to calculate the nodes from beginning to end.
[0088] Preferably, the above-described scheme of using two double-ended queues (Deque) and non-recursive function calls can be adopted to access, enqueue, and compute nodes in the node chain tree structure (controller nodes are leaves, and skeleton nodes are roots) layer by layer; the computation results of each level of the node tree are placed into the second queue and queried and called when the parent level node is computed, so as to solve the problem of memory overflow that may occur during operation.
[0089] The following combination Figure 4 The specific process of generating the first driver code subset based on the traversal results of multiple driver nodes in the first driver node set is explained below.
[0090] like Figure 4 The driver node set 402 shown is an optional node relationship diagram that matches the first driver node set, used to indicate the driving relationships between various driver node objects in the first object-driven model. It can be understood that the root node in the driver node set 402 can be a binding layer skeleton node (i.e., the first skeleton object) in the first object-driven model, used to drive the spatial position of the skinned mesh; the leaf nodes, including nodes 10, 11, and 12, can be used as controller nodes in the first object-driven model, used to receive control commands received from the first object-driven tool.
[0091] In this implementation, the traversal can be performed using a breadth-first search algorithm, such as... Figure 4The set of driving nodes 402 is shown, and the accessed node objects are replaced with instantiation code of classes defined in the framework's C++ part that have the same calculation functions. The above instantiation code is placed into the C++ container data structure in sequence and compiled into a dynamic library in the second object-driven tool to run in real time during the model rendering process.
[0092] Specifically, based on the breadth-first traversal algorithm described above, node 1 in the driver node set 402 can be obtained first. Then, according to the hierarchical driving relationship between node 1 and nodes 2, 3, and 4 (i.e., the outputs of nodes 2, 3, and 4 are used as the inputs of node 1), in... Figure 5 The head of the first queue 502 shown records node 1, node 2, node 3, and node 4 in sequence. Meanwhile, as... Figure 4 In the target data structure 404, the driving relationship between node 1 and nodes 2, 3 and 4 is stored, and the instantiation code corresponding to node 1 is also stored.
[0093] Next, according to the traversal order corresponding to the breadth-first search algorithm, nodes 9, 8, 7, 6, and 5 in the third node level can be obtained and stored sequentially. Figure 5 The head of the first queue 502. It can be understood that while storing the traversal order between the aforementioned nodes in the first queue 502, it is also necessary to... Figure 4 The target data structure 404 shows the structure that stores the instantiation code corresponding to each node, as well as the result call relationship between each instantiation code.
[0094] Based on the above steps, we can obtain the result. Figure 4 The driver node set 402 in the middle corresponds to Figure 5 The first queue 502 in the above. Then, the traversal relationship indicated by the first queue 502 and the instantiation code corresponding to each node are taken as the first driver code subset.
[0095] The following explains the code invocation methods during execution. When running the aforementioned subset of the first driver code in the second object-driven tool or virtual object rendering model, you can first create... Figure 5The second queue 504 is used to store intermediate results generated during the process. Specifically, the nodes can be dequeued sequentially from the tail of the first queue 502, and the execution results of the instantiated code corresponding to each node can be obtained and stored sequentially at the head of the second queue 504. For example, in the first queue 502, the node dequeued from the tail is node 10, and the instantiated code corresponding to node 10 is obtained. According to the input value indicated by the control command, the instantiated code corresponding to node 10 is run, and the execution result of the instantiated code corresponding to node 10 is stored at the head of the second queue 504 (i.e., 10v). Next, in the first queue 502, the next node dequeued from the tail is node 11, and the instantiated code corresponding to node 11 is obtained. According to the input value indicated by the control command, the instantiated code corresponding to node 11 is run, and the execution result of the instantiated code corresponding to node 11 is stored at the head of the second queue 504 (i.e., 11v).
[0096] Similarly, in the first queue 502, if the next node dequeued from the tail is node 5, the instantiation code corresponding to node 5 and the driving relationship between node 5 and nodes 10, 11 and 12 are obtained. Then, in the head of the second queue 504, the running results corresponding to nodes 10, 11 and 12 are dequeued and the three running results are obtained as the input values of the instantiation code corresponding to node 5. The instantiation code corresponding to node 5 is run and the running result of the instantiation code corresponding to node 5 is stored in the head of the second queue 504 (i.e. 5v).
[0097] According to the above process, the corresponding instantiation code is called sequentially from the first queue 502, and the corresponding running results are stored sequentially in the second queue 504. Based on the calling relationship between each instantiation code, the code is dequeued sequentially to obtain the output result 1v corresponding to the root node, which serves as the reference driving parameter of the first skeleton object in the first object-driven model.
[0098] It should be noted that the final output obtained in the above steps is the driving result determined in the first object-driven model. Further correction of the above reference driving parameters is needed based on the geometric differences between the two object-driven tools to obtain the accurate skeleton driving result in the second object-driven tool.
[0099] Through the above-described embodiments of this application, a node relationship graph matching the first set of driving nodes is obtained; multiple driving node objects in the node relationship graph are traversed sequentially according to the node hierarchy from low to high; based on the traversal results of the driving node objects, the calculation codes corresponding to each driving node object are stored in the first queue; the multiple calculation codes matching the first queue are determined as the first subset of driving codes, and then the animation controller-bone / fusion deformation core driving logic originally implemented using the calculation node graph of Maya tools is replaced by equivalent C++ code and compiled into a dynamic library plugin in 3ds Max to achieve cross-software portability of the object binding template calculation system.
[0100] In one optional implementation, obtaining the second subset of driving code based on the object coordinate transformation relationship between the first object-driven tool and the second object-driven tool includes at least one of the following:
[0101] Method 1: Determine the first coordinate transformation code included in the second driving code subset based on the first object coordinate transformation relationship indicated by the coordinate axis sequence of the first object driving tool and the second object driving tool.
[0102] Method 2: Determine the second coordinate transformation code included in the second driving code subset based on the second object coordinate transformation relationship indicated by the length units corresponding to the first object driving tool and the second object driving tool;
[0103] Method 3: Determine the third coordinate transformation code included in the second driving code subset based on the third object coordinate transformation relationship indicated by the initial angle of the skeletal object corresponding to the first object driving tool and the second object driving tool.
[0104] It is understood that, in this embodiment, a second subset of driving code can be determined based on the object coordinate transformation relationship between the first object driving tool and the second object driving tool, so as to correct the reference driving parameters output by the first subset of driving code through the second subset of driving code, thereby determining the accurate target driving parameters of the second skeleton object in the second object driving tool.
[0105] Let's continue using Maya and 3ds Max as examples. Both tools use a right-handed coordinate system, but the order of the axes differs: the X / Y / Z axes in Maya correspond to the Z / X / Y axes in 3ds Max. Therefore, the calculation results of the code examples need to be transformed based on the second subset of the driving code mentioned above.
[0106] Furthermore, the default length units differ between the two tools: Maya uses centimeters, while 3ds Max uses inches. To ensure that the core-driven calculations, converted from node graphs to C++ code, are assigned to the correct coordinate axes for the skeleton, the framework code performs coordinate system and length unit transformations on the node chain calculations.
[0107] Furthermore, after the face rigging skeleton is imported into 3ds Max using FBX as an intermediary, the rotation values of the rigging layer bones, which were originally zero in Maya tools, become non-zero after being converted into Dummy objects in 3ds Max. Therefore, the rotation value attributes of the bone objects need to be adjusted. Specifically, the rigging layer bones can be reconstructed in 3ds Max using the conversion tool's workflow script to ensure that the initial rotation values of the bones are zero.
[0108] Finally, since the translation and rotation / scaling of the bones bound by the two software programs are represented in the parent space and object space respectively, and the bones in the template have multiple coordinate axes, the selection branch of its coordinate system transformation code must include all cases.
[0109] It's important to note that in 3D modeling and animation, object space and parent space are two different ways of defining coordinate transformations, affecting the positioning, rotation, and scaling of objects. Object space is defined relative to the object's own coordinate system. In this space, transformations (such as rotation, scaling, and translation) are performed relative to the object's origin and axes. Parent space, on the other hand, is defined relative to the object's parent object. In a 3D hierarchy, one object can be a child object of another; this relationship is called a parent-child relationship.
[0110] For example, node A is the parent node of the bound bone B, meaning that the movement of node A will drive the movement of the bound bone B. In the above implementation, the displacement of the bound bone B is described based on the parent space defined by node A, while the rotation and scaling parameters of the bound bone B are described based on the object space defined by the bound bone B itself.
[0111] During the transformation of displacement properties, it is possible to follow the rules such as... Figure 6 The image shows the orientation of a specific type of bone object in Maya tools, along with its specific coordinate axis orientation in the parent space, which is then converted to its corresponding orientation in 3ds Max. For example, Figure 6In case 1 shown, if the coordinate axis direction of the parent space corresponding to the displacement attribute of the head skeleton is as shown in case 1, its conversion to the corresponding coordinate axis direction in 3ds Max is as follows: Figure 6 As shown. For example, Figure 6 The example in Case 1 illustrates the conversion between rotation and scaling attributes. For the object space coordinate axes corresponding to the rotation and scaling attributes of the facial bone (facial), as shown in Case 1, the conversion to the corresponding coordinate axis directions in 3ds Max is as follows: Figure 6 As shown.
[0112] In other words, in the above embodiments of this application, when obtaining the reference driving parameters of the binding layer skeleton based on the code set of node graph transformation, it is also necessary to consider coordinate axis direction, length unit, object rotation attributes, and so on. Figure 6 The coordinate transformation relationship of a specific type of skeletal object in the parent space and object space is shown to determine the second subset of driving code that performs spatial correction on the above reference driving parameters, and then determine the accurate target driving parameters in the second object driving tool.
[0113] In the above embodiments of this application, it is understood that during cross-software data exchange, data deviations or inconsistencies may occur due to different software architectures and processing methods. In this embodiment, automated data correction and standardization are performed using the aforementioned second subset of driving code to ensure that the expected results are obtained in the second object-driven tool. The transformation process indicated by the aforementioned second subset of driving code involves the parsing, transformation, and reconstruction of the skeletal hierarchy, as well as the adjustment of transformation attributes such as rotation and scaling. Simultaneously, the differences in coordinate systems across different software are considered to ensure the accuracy of coordinate system transformation.
[0114] In one optional implementation, determining the driver code set based on the first driver code subset and the second driver code subset includes:
[0115] S1, Generate a third driver code subset based on the parameter interface provided by the second object driver tool, wherein the third driver code subset is used to obtain initial driver parameters from the second object driver tool according to control instructions;
[0116] S2, Update the calculation code associated with the second skeleton object in the first driver code subset according to the second driver code subset;
[0117] S3, the updated first driver code subset and the third driver code subset are determined as the driver code set.
[0118] It is understood that, in this embodiment, during the process of determining the set of driving codes based on the first subset of driving codes and the second subset of driving codes, the first subset of driving codes can be updated based on the second subset of driving codes. For example, the first instantiated code corresponding to the target binding layer bone in the first subset of driving codes is obtained, and then the second instantiated code corresponding to the target binding layer bone in the second subset of driving codes is obtained. It is understood that the first instantiated code can be used to obtain the corresponding bone position change in the first object-driven tool, and the second instantiated code can convert the bone position change into an accurate bone position change in the second object-driven tool based on the spatial geometric differences between tools. Furthermore, the corresponding second instantiated code can be added to the first instantiated code to update the instantiated code corresponding to the target binding layer bone.
[0119] Furthermore, in this embodiment, in order for the converted rigging animation controller to drive the skeleton, the controller transformation parameter values need to be passed to the dynamic library plugin compiled from the C++ code equivalently converted by the Maya rigging node graph (i.e., the updated first driving code subset mentioned above); and after the dynamic library calculates the displacement / rotation transformation values corresponding to each driven bone under various facial expressions and poses, it is connected to the corresponding transformation attribute parameters of the bone entity through the parameter wiring method of 3ds Max software.
[0120] In this implementation, the Parameter Blocks API provided by the 3ds Max SDK can be used as the interface for passing 3ds Max scene object attribute values to the core driver C++ code, and custom controls corresponding to the parameter blocks can be added to the UI panel.
[0121] The basic format of the code block description is as follows:
[0122] ParamBlockDesc2 simpeblk
[0123] {
[0124] simple_params,T("Simple Parameters"),0,&SimpleAttribDesc,
[0125] / / Flags
[0126] P_AUTO_CONSTRUCT+P_AUTO_UI,
[0127] 0,
[0128] / / Rollout
[0129] IDD_DYNPARAM,IDS_DYNPARAMS,0,0,NULL,
[0130] / / Params
[0131] simple_spin,_T("spinner"),TYPE_INT,P_ANIMATABLE,IDS_SPIN,
[0132] p_default,4,
[0133] p_range, MIN_SPIN, MAX_SPIN
[0134] p_ui,TYPE_SPINNER,EDITTYPE_INT,IDC_EDIT,IDC_EDITSPIN,0.05f,
[0135] p_end
[0136] };
[0137] The following is a detailed explanation of the code block:
[0138] ParamBlockDesc2 is a class in 3ds Max used to describe parametric blocks. ParamBlockDesc2 is an instantiation of this class.
[0139] simpleblk is the name of the parameter block, usually an identifier used to reference this parameter block in the code;
[0140] simple_params can be an array of parameter IDs associated with a parameter block, used to define the parameters contained in the parameter block;
[0141] T("Simple Parameters") can be a descriptive title for the parameter block, used for display in the UI;
[0142] The identifier 0 can be the ID of the parameter block, used to uniquely identify the parameter block.
[0143] &SimpleAttribDesc can be a pointer to an attribute description that defines some additional information about the parameter block;
[0144] P_AUTO_CONSTRUCT+P_AUTO_UI can be flags for a parameter block, instructing 3ds Max to automatically build the parameter block and create its UI;
[0145] IDD_DYNPARAM, IDS_DYNPARAMS: These can be used to indicate resource definitions, typically used to specify UI dialog templates and related string resources.
[0146] simple_spin is the name of the parameter, used to identify a specific parameter in the parameter block;
[0147] T("spinner") is a UI title used to indicate parameters and is displayed next to UI controls;
[0148] TYPE_INT is used to specify that the data type of the parameter is an integer;
[0149] The P_ANIMATABLE parameter indicates that the parameter can be animated;
[0150] IDS_SPIN is the resource ID of the parameter, used for display in the UI;
[0151] p_default is used to specify that a parameter has a default value;
[0152] p_range is used to define the range of values for a parameter;
[0153] MIN_SPIN and MAX_SPIN are used to indicate the minimum and maximum limits for parameter values;
[0154] p_ui is used to define how parameters are represented in the UI;
[0155] TYPE_SPINNER is used to specify that the UI control is a spinner.
[0156] EDITTYPE_INT is used to specify that the type of the edit control is an integer;
[0157] The IDC_EDIT and IDC_EDITSPIN parameters are used to indicate the resource ID of a UI control, which is used to reference it in a dialog template.
[0158] 0.05f can be used to indicate the step size or sensitivity of UI controls;
[0159] p_end: is used to mark the end of parameter definition.
[0160] In the above implementation, the code block defines a parameter block containing an animable integer parameter. This parameter has a default value and a range limit, and is presented in the UI as a rotator. By defining the code block, the controller transformation parameter values of 3ds Max can be obtained and passed to the updated first driving code subset. Then, based on the updated first driving code subset, the attribute transformation values of the skeletal objects in 3ds Max can be determined and assigned to the skeletal objects in 3ds Max according to the parameter connection method, thereby realizing the driving of the skeletal objects in 3ds Max.
[0161] In one optional implementation, generating the target expression set based on the second set of driving nodes includes:
[0162] S1, Obtain at least one node chain included in the second set of driver nodes, wherein the node chain is used to indicate at least one driver node object associated with the custom driver relationship;
[0163] S2, convert the custom driving relationship indicated by at least one node chain into at least one target expression included in the target expression set;
[0164] S3, add at least one target expression to the target expression file in the target format, wherein the target expression file is used to describe custom driving relationships in the second object-driven tool.
[0165] It should be noted that in this embodiment, since users may add additional drivers beyond the basic binding template-driven functionality generated by the Maya toolset (adding custom attributes to the animation controller, adding facial expressions and poses to the hub group node and connecting them to bone transformation attributes using computed nodes), this embodiment avoids having to process the updated node graph, convert it into C++ code, and recompile the plugin every time the user makes such modifications. Instead, this embodiment uses a hybrid node alternative scheme that converts the basic template functionality into fixed C++ code and replaces the user-defined driver mapping with mathematical expressions. This improves the creation efficiency of the second object-driven model after the user modifies the custom driver method.
[0166] In one alternative implementation, after adding at least one target expression to the target expression file in the target format, the method further includes at least one of the following:
[0167] Method 1: Add attribute identification information associated with the node chain to the target expression file;
[0168] Method 2: Add value range information that matches the target expression to the target expression file.
[0169] Specifically, in this embodiment, the node chain generated by the custom driver can be traversed in a depth-first manner. After replacing the calculation functions of the key animation curves and other related nodes with equivalent mathematical formulas, the beginning and end attribute names, value ranges, and mathematical expressions of the node chain are passed into 3ds Max in the form of a JSON dictionary. These are added to the script controller (Script Editor) of the controller group's Dummy object transformation attribute trajectory to restore the custom driver mapping.
[0170] In one optional implementation, the above-described conversion of the custom driving relationship indicated by at least one node chain into at least one target expression included in the target expression set includes:
[0171] S1, In the case that the node chain includes multiple second reference driving objects for driving the first bone object, a first target bone object matching the first bone object and a second target driving object matching the multiple second reference driving objects are created. The second target driving object is configured with multiple object attributes corresponding to the multiple second reference driving objects respectively. The object attributes are used to store the attribute values transmitted by the corresponding second reference driving object.
[0172] S2, create a driving expression based on multiple object properties, where the driving expression is used to determine the target attribute value according to the attribute values of multiple object properties, and the target attribute value is used to drive the first target skeleton object in the second object driving tool.
[0173] It's important to note that in Maya tools (the first object-driven tool), the blendWeighted node is a node that can combine the weights of multiple inputs (drivers) to affect a single output property. This allows a transformation property (such as rotation or position) to be influenced by custom properties of multiple controllers. However, in 3ds Max tools (the second object-driven tool), there are limitations on parameter joins. 3ds Max's parameter join mechanism typically only allows one property parameter to be directly driven by another property at a time, and does not support the many-to-one (multiple drivers affecting one property) functionality of Maya's blendWeighted node.
[0174] In the above embodiments of this application, to overcome this limitation in 3ds Max, a parent Dummy object can be used as a hub to simulate the function of the blendWeighted node in Maya. Specifically, a parent Dummy object is added above the bone hierarchy. This Dummy object serves as the control center for centrally managing multiple driving attributes. Next, multiple custom attributes are added to the parent Dummy object. These attributes correspond to the custom attributes in Maya that affect bone transformation attributes. Finally, using 3ds Max's script controller and expressions, a mathematical expression is created to calculate the weighted sum of the various custom attributes on the Dummy object, thereby simulating the effect of weighted blending.
[0175] Through the above-described embodiments of this application, when a user-defined blendWeighted node exists in the Maya tool, the weighted blending function of the blendWeighted node in Maya can be simulated during the conversion process by combining scripts and custom attributes.
[0176] The following combination Figure 7 The above-described embodiments will be explained. For example... Figure 7 As shown, suppose a user creates a blendWeighted driven structure including node 1, node 2, and node 3 using Maya tools, where the outputs of node 2 and node 3 are used as the inputs of node 1. During the conversion process, node 1 can be mapped to node 4 in 3ds Max, and a parent node corresponding to node 2 and node 3, i.e., node 5, is added above node 4. Node 5 is configured with at least two node attributes, used to store the outputs corresponding to node 2 and node 3, respectively. Then, using 3ds Max's script controller and expressions, a mathematical expression is created to calculate the weighted sum of the two custom attributes on node 5, which is then used as the input to node 4. This achieves the simulation of the weighted blending function of Maya's blendWeighted nodes during the conversion process, even when a user-defined blendWeighted node exists in Maya tools, through a combination of scripts and custom attributes.
[0177] In an optional implementation, after adding at least one target expression to the target expression file in the target format, the method further includes:
[0178] S1, in response to the edit operation on the second driving node set, obtain the third driving node set updated according to the second driving node set;
[0179] S2, Generate the updated target expression set based on the third driving node set;
[0180] S3, determine the second driving information set for indicating the second object driving model based on the driving code set and the updated target expression set.
[0181] Understandably, in this implementation, users may add additional drivers beyond the basic binding template-driven functionality generated by the Maya toolset (adding custom attributes to the animation controller, adding facial expressions and poses to the hub group node, and connecting them to bone transformation attributes using computed nodes). To avoid having to process the updated node graph, convert it to C++ code, and recompile the plugin every time the user makes such modifications, this implementation adopts a hybrid node alternative scheme that converts the basic template functionality into fixed C++ code and replaces the user-defined driver mapping with mathematical expressions. Therefore, after the user modifies the custom driver method, only the custom driver portion needs to be converted using expressions, thereby improving the creation efficiency of the second object-driven model.
[0182] like Figure 8 As shown, in one optional implementation, this application also provides a method for driving virtual objects, including:
[0183] S802, Obtain the second driving information set that matches the second object driving model in the second object driving tool;
[0184] The second driving information set is determined based on the driving code set and the target expression set. The driving code set is generated based on the first driving node set included in the first driving information set that matches the first object driving model. The target expression set is generated based on the second driving node set included in the first driving information set. The first driving node set is used to indicate the preset driving relationship provided by the first object driving tool, and the second driving node set is used to indicate the custom driving relationship included in the first object driving model.
[0185] S804, in response to receiving the initial drive parameter set carried by the control command, determines the first target drive parameter set based on the initial drive parameter set and the drive code set, and determines the second target drive parameter set based on the initial drive parameter set and the target expression set;
[0186] S806, determine the object transformation information of at least one second skeleton object in the second object-driven model based on the first target-driven parameter set and the second target-driven parameter set;
[0187] S808, based on the object transformation information of at least one second skeleton object, drive the target virtual object in the second object driving tool.
[0188] In the above embodiments, the first object-driven tool and the second object-driven tool can be two different 3D modeling tools for creating object-driven models. The object-driven models created by the first and second object-driven tools can be used to render and drive virtual objects in various scenarios such as video games, movies, and television. The first object-driven model created by the first object-driven tool and the second object-driven model created by the second object-driven tool can include a set of driving node objects for determining driving information according to control instructions, and a set of skinned mesh objects for determining the spatial displacement of each point on the surface of the virtual object according to the driving information. Furthermore, in the process of determining the spatial displacement of each skinned mesh according to the driving information, the spatial displacement of each skinned mesh object can be further determined by combining skinned weight information with the driving information.
[0189] It should be noted that, in this embodiment, it can be based on, as follows: Figure 9 The operation panel 902 shown receives trigger operations that match each operation control, and the initial drive parameter set corresponds to the control instructions indicated by the aforementioned trigger operations. In another optional implementation, it can also be in a virtual scene rendering application, where control instructions for controlling the target virtual object are obtained, and the corresponding initial drive parameter set is obtained based on the control instructions.
[0190] The following combination Figure 3 An alternative object-driven model is described. For example... Figure 3As shown, the object-driven model includes at least a set of driving nodes 304 and a skin mesh 306. The set of driving nodes 304 is used to transmit and transform driving information according to the connection relationship between driving nodes, and the skin mesh 306 is used to determine the displacement information of the target skin mesh rendered on the virtual object according to the driving information output by node 1. More specifically, when the object-driven model receives control instruction 302 (e.g., a control instruction to "control the virtual object to make a smiling expression"), it then determines the initial driving information received by each node based on control instruction 302. That is, multiple leaf nodes, including node 10, node 11, and node 12, receive the initial driving information determined by control instruction 302. Based on the driving mode corresponding to each node, it determines the intermediate driving information received by the next level node connected to it. Finally, it determines the target driving information output by the binding layer node (i.e., node 1) connected to the skinned mesh 306. The target driving information can be used to indicate the displacement, rotation, scaling, and other changes of the binding layer skeleton in the virtual space. Then, based on the binding mapping relationship between the target driving information output by node 1 and the skinned mesh 306, it determines the displacement information of the object surface, including the skinned mesh 306, on the virtual object. It is understandable that the binding mapping relationship between the target driving information output by node 1 and the skin mesh 306 can be determined based on the skin weight information mentioned above. Furthermore, when the displacement information of the skin mesh 306 is determined based on multiple binding layer nodes, the displacement information of the skin mesh 306 can be determined based on the weight information corresponding to each binding layer node and the target driving information mentioned above.
[0191] The following combination Figure 5 This section explains the code invocation method used during operation to determine the first target driver parameter set based on the initial driver parameter set and the driver code set. During the execution of the first driver code subset in the second object-driven tool or virtual object rendering model, a process such as... Figure 5The second queue 504 is used to store intermediate results generated during the process. Specifically, the nodes can be dequeued sequentially from the tail of the first queue 502, and the execution results of the instantiated code corresponding to each node can be obtained and stored sequentially at the head of the second queue 504. For example, in the first queue 502, the node dequeued from the tail is node 10, and the instantiated code corresponding to node 10 is obtained. According to the input value indicated by the control command, the instantiated code corresponding to node 10 is run, and the execution result of the instantiated code corresponding to node 10 is stored at the head of the second queue 504 (i.e., 10v). Next, in the first queue 502, the next node dequeued from the tail is node 11, and the instantiated code corresponding to node 11 is obtained. According to the input value indicated by the control command, the instantiated code corresponding to node 11 is run, and the execution result of the instantiated code corresponding to node 11 is stored at the head of the second queue 504 (i.e., 11v).
[0192] Similarly, in the first queue 502, if the next node dequeued from the tail is node 5, the instantiation code corresponding to node 5 and the driving relationship between node 5 and nodes 10, 11 and 12 are obtained. Then, in the head of the second queue 504, the running results corresponding to nodes 10, 11 and 12 are dequeued and the three running results are obtained as the input values of the instantiation code corresponding to node 5. The instantiation code corresponding to node 5 is run and the running result of the instantiation code corresponding to node 5 is stored in the head of the second queue 504 (i.e. 5v).
[0193] According to the above process, the corresponding instantiation code is called sequentially from the first queue 502, and the corresponding running results are stored sequentially in the second queue 504. Based on the calling relationship between each instantiation code, the code is dequeued sequentially to obtain the output result 1v corresponding to the root node, which serves as the reference driving parameter of the first skeleton object in the first object-driven model.
[0194] It should be noted that the final output obtained in the above steps is the driving result determined in the first object-driven model. Further correction of the above reference driving parameters is needed based on the geometric differences between the two object-driven tools to obtain the accurate skeleton driving result in the second object-driven tool.
[0195] Specifically, taking a face binding template as an example, the specific implementation method of creating an object-driven model is described. In this embodiment, an object-driven model creation plugin is also provided, which can be used to implement the object-driven model creation method.
[0196] After the user generates a face rigging template, matches a custom character head model, and processes the skinning weights using the Maya toolset, only the skinned skeleton and model mesh are retained and exported in FBX format. The skinning weights export tool in the toolset is then used to export the skinning weights information as a data file with the .w extension. These two files will be loaded into 3ds Max as the data input required by the conversion process.
[0197] After that, as Figure 10 As shown, users can open the Face Rigging Conversion Tool (the aforementioned Object-Driven Model Creation Plugin) UI panel in 3ds Max, select the rigging template type corresponding to that generated in Maya, click the corresponding panel button to select and load the FBX file and .w skinning weight file from the previous step, and then rebuild the rigging drive in 3ds Max by clicking the "Execute Conversion" button at the bottom of the panel. The entire conversion process takes only a few minutes to complete and accurately reproduces the driving mesh deformation effect in Maya. Furthermore, this plugin can automatically switch between different panel text labels and button text languages based on the 3ds Max software language version.
[0198] During the transformation process, the specific visual process is as follows: Figure 11 As shown, firstly, S1102 is executed based on the FBX file to calculate the node graph; then S1104 is executed to generate the equivalent C++ code for the node graph; then S1106 is executed to determine the core driver method based on the equivalent C++ code.
[0199] In steps S1102 to S1106 above, a Python script can be used to execute a breadth-first traversal algorithm to traverse the rigging base templates generated by the Maya toolset, such as... Figure 4 The node graph shown is used, and the visited nodes are replaced with instantiations of classes defined in the framework's C++ section that have the same computational functionality. Instances of these computation node classes are sequentially placed into a C++ container data structure and compiled into a .dlo 3ds Max dynamic library for real-time execution in the software. In the above steps, a scheme using two double-ended queues and non-recursive function calls is employed to access, enqueue, and compute nodes in the tree-like node chain structure (controller nodes are leaves, and skeleton nodes are roots) layer by layer. The computation results of nodes at each level of the node tree are placed into the second queue for querying and calling when the parent level node is computed.
[0200] Furthermore, while both Maya and 3ds Max use a right-handed coordinate system (OpenGL graphics API), the order of their axes differs: Maya's X / Y / Z axes correspond to 3ds Max's Z / X / Y axes. Additionally, their default units of length differ: Maya uses centimeters while 3ds Max uses inches. To ensure that the calculation results, converted from node graphs to C++ code, are assigned to the correct coordinate axes for the skeleton, the framework code automatically performs coordinate system and unit of length conversions on the node chain calculation results.
[0201] In this implementation, the conversion tool's workflow script in 3ds Max further reconstructs the bound hierarchical bones to ensure that the initial rotation values of the bones are zero. Simultaneously, since the displacement and rotation / scaling of the bound bones in both software programs are represented in parent space and object space respectively, and the bones in the template have multiple coordinate axes, the selection branch of its coordinate system transformation code must include all cases, such as... Figure 6 As shown.
[0202] Furthermore, in 3ds Max, to enable the converted rigging animation controller to drive the skeleton, the controller's transformation parameter values need to be passed to a dynamic library plugin compiled from C++ code equivalent to the Maya rigging node graph. After the dynamic library calculates the displacement / rotation transformation values for each driven bone under various facial expressions and poses, it connects to the corresponding transformation attribute parameters of the bone entity via 3ds Max's parameter wiring method. Therefore, this technical solution uses the Parameter Blocks API provided by the 3ds Max SDK as the interface for passing 3ds Max scene object attribute values to the core driving C++ code, and adds custom controls corresponding to the parameter blocks to the UI panel.
[0203] Furthermore, if the face binding template includes a user-defined driver method, execute S1104-1 to obtain user-defined driver information; and execute S1106-1 to determine the target expression based on the user-defined driver information.
[0204] Understandably, users might add additional drivers beyond the basic rigging templates generated by the Maya toolset (adding custom attributes to the animation controller, adding facial expressions to hub group nodes, and connecting them to bone transformation attributes using computed nodes). However, it's impractical to have the product developers process the updated node graphs with script code, convert it to C++ code, and recompile the plugin every time a user makes such modifications. This product employs a hybrid node replacement solution: converting the basic template functionality into fixed C++ code and replacing user-defined driver mappings with mathematical expressions. Specifically, it performs a depth-first traversal of the node chain generated by the custom driver, replacing the calculation functions of key animation curves and other related nodes with equivalent mathematical formulas. Then, it passes the node chain's start and end attribute names, value ranges, and mathematical expressions as a JSON dictionary to 3ds Max, adding them as attributes and expressions to the script controller (Script Editor) of the Dummy object transformation attribute trajectory in the controller group to restore the custom driver mapping.
[0205] On the other hand, in Maya, adding custom drivers usually involves a transformation attribute of a bone being driven by multiple custom attributes of the animation controller (implemented by the blendWeighted node); however, 3ds Max's parameter connection mechanism only allows one attribute parameter to be driven by another (not many-to-one). In this implementation, a parent dummy object can be added to the bone in 3ds Max as a hub, and multiple 3ds Max custom attributes corresponding to the custom driving attributes can be added to it. This can be combined with transformation attribute trajectory script controller expressions to simulate the functionality of the Maya blendWeighted node.
[0206] like Figure 7As shown, suppose a user creates a blendWeighted driven structure including node 1, node 2, and node 3 using Maya tools, where the outputs of node 2 and node 3 are used as the inputs of node 1. During the conversion process, node 1 can be mapped to node 4 in 3ds Max, and a parent node corresponding to node 2 and node 3, i.e., node 5, is added above node 4. Node 5 is configured with at least two node attributes, used to store the outputs corresponding to node 2 and node 3, respectively. Then, using 3ds Max's ScriptController and expressions, a mathematical expression is created to calculate the weighted sum of the two custom attributes on node 5, which is then used as the input to node 4. This achieves the simulation of the weighted blending function of Maya's blendWeighted nodes during the conversion process, even when a user-defined blendWeighted node exists in Maya tools, through a combination of scripts and custom attributes.
[0207] In addition, S1102-1, template conversion, also needs to be performed;
[0208] Through the above-described implementation methods of this application, the basic driver of the face rigging template generated by the Maya toolset is converted and compiled into C++ code, resulting in a more standardized and centralized overall replacement rule (a single .dlo plugin) and more efficient computational performance. Furthermore, user-added incremental drivers are converted into 3ds Max expressions, thus providing greater flexibility in modifying synchronous driver effects. Simultaneously, this technical solution simplifies the data and processes used for synchronous rigging and deformation effects in both Maya and 3ds Max 3D animation software, restoring the optimal rigging effect at minimal cost.
[0209] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.
[0210] According to another aspect of the present invention, an apparatus for reconstructing an object-driven model for implementing the above-described object-driven model reconstruction method is also provided. For example... Figure 12 As shown, the device includes:
[0211] The first acquisition unit 1202 is used to acquire a first driving information set that matches the first object driving model, wherein the first object driving model is used to drive a target virtual object according to control instructions received in the first object driving tool, and the first driving information set is used to indicate the driving relationship between the control instructions and the object actions performed by the target virtual object.
[0212] The second acquisition unit 1204 is used to acquire a first set of driving nodes and a second set of driving nodes from the first set of driving information, wherein the first set of driving nodes is used to indicate the preset driving relationship provided by the first object driving tool, and the second set of driving nodes is used to indicate the custom driving relationship included in the first object driving model.
[0213] The reconstruction unit 1206 is used to generate a set of driver codes based on the first set of driver nodes and a set of target expressions based on the second set of driver nodes. The set of driver codes includes driver codes corresponding to multiple driver nodes in the first set of driver nodes, and the set of target expressions includes driver expressions used to indicate the custom driver relationship.
[0214] The determining unit 1208 is used to determine a second driving information set that matches the second object driving model based on the above-mentioned driving code set and the above-mentioned target expression set, wherein the above-mentioned second object driving model is used to drive the above-mentioned target virtual object according to the above-mentioned control instructions received in the second object driving tool.
[0215] Optionally, the reconstruction unit 1206 includes: a traversal module, configured to generate a first subset of driving code based on the traversal results of multiple driving nodes in the first set of driving nodes, wherein the first subset of driving code is used to determine reference driving parameters based on initial driving parameters, and the reference driving parameters are used to drive a first skeleton object in the first object-driven model in the first object-driven tool; a conversion module, configured to obtain a second subset of driving code based on the object coordinate transformation relationship between the first object-driven tool and the second object-driven tool, wherein the second subset of driving code is used to convert the reference driving parameters into target driving parameters, and the target driving parameters are used to drive a second skeleton object in the second object-driven model in the second object-driven tool; and a determination module, configured to determine the set of driving code based on the first subset of driving code and the second subset of driving code.
[0216] Optionally, the traversal module is configured to: obtain a node relationship graph matching the first set of driving nodes, wherein the node relationship graph includes multiple driving node objects and node dependency relationships between the driving node objects; in the parent and child driving node objects with the node dependency relationships, the parent driving node object is used to obtain a second driving calculation result based on the first driving calculation result output by the child driving node object; the leaf nodes in the node relationship graph are controller node objects, and the root node in the node relationship graph is the first skeleton object; traverse the multiple driving node objects in the node relationship graph sequentially according to the node hierarchy from low to high; store the calculation code corresponding to each driving node object according to a first queue based on the traversal results of the driving node objects, wherein during the operation of the second object driving tool, the first queue is used to call the calculation code corresponding to each driving node object, and the calculation result corresponding to each driving node object is stored according to the created second queue; and determine the multiple calculation codes matching the first queue as the first set of driving codes.
[0217] Optionally, the above-mentioned conversion module is used to: determine the first coordinate conversion code included in the second driving code subset based on the first object coordinate conversion relationship indicated by the coordinate axis sequence corresponding to the first object driving tool and the second object driving tool respectively; determine the second coordinate conversion code included in the second driving code subset based on the second object coordinate conversion relationship indicated by the length unit corresponding to the first object driving tool and the second object driving tool respectively; and determine the third coordinate conversion code included in the second driving code subset based on the third object coordinate conversion relationship indicated by the initial angle of the skeletal object corresponding to the first object driving tool and the second object driving tool respectively.
[0218] Optionally, the determining module is configured to: generate a third subset of driving code based on the parameter interface provided by the second object driving tool, wherein the third subset of driving code is used to obtain the initial driving parameters from the second object driving tool according to control instructions; update the calculation code associated with the second skeleton object in the first subset of driving code based on the second subset of driving code; and determine the updated first subset of driving code and the third subset of driving code as the driving code set.
[0219] Optionally, the reconstruction unit 1206 includes: an acquisition module, configured to acquire at least one node chain included in the second driver node set, wherein the node chain is used to indicate at least one driver node object associated with the custom driver relationship; an expression conversion module, configured to convert the custom driver relationship indicated by at least one of the node chains into at least one target expression included in the target expression set; and an adding module, configured to add at least one of the target expressions in a target expression file of a target format, wherein the target expression file is used to describe the custom driver relationship in the second object driver tool.
[0220] Optionally, the expression conversion module is configured to: when the node chain includes multiple second reference driver objects for driving the first bone object, create a first target bone object matching the first bone object, and a second target driver object matching the multiple second reference driver objects, wherein the second target driver object is configured with multiple object attributes corresponding to the multiple second reference driver objects respectively, and the object attributes are used to store the attribute values transmitted by the corresponding second reference driver objects; and create a driving expression determined based on the multiple object attributes, wherein the driving expression is used to determine a target attribute value according to the attribute values of the multiple object attributes, and the target attribute value is used to drive the first target bone object in the second object driving tool.
[0221] Optionally, the above-mentioned adding module is also used for at least one of the following: adding attribute identification information associated with the above-mentioned node chain to the above-mentioned target expression file; adding value domain information matching the above-mentioned target expression to the above-mentioned target expression file.
[0222] Optionally, the above-described object-driven model reconstruction apparatus is further configured to: in response to an editing operation on the second set of driving nodes, obtain a third set of driving nodes updated according to the second set of driving nodes; generate an updated set of target expressions according to the third set of driving nodes; and determine a second set of driving information for indicating the second object-driven model according to the set of driving codes and the updated set of target expressions.
[0223] Optionally, the object-driven model reconstruction device described above is further configured to: determine, based on the first set of driving skeleton objects, the first set of skinned mesh objects, and the first skinned weight information included in the first object-driven model, as the second set of driving skeleton objects, the second set of skinned mesh objects, and the second skinned weight information included in the second object-driven model; and determine the second object-driven model based on the second set of driving skeleton objects, the second set of skinned mesh objects, the second skinned weight information, and the second set of driving information.
[0224] Optionally, in this embodiment, the implementation of each of the above-mentioned unit modules can be referred to the above-mentioned method embodiments, which will not be repeated here.
[0225] According to another aspect of the present invention, an electronic device for implementing the above-described object-driven model reconstruction method is also provided, the electronic device being... Figure 13 The terminal device or server shown. This embodiment uses this electronic device as an example for illustration. Figure 13 As shown, the electronic device includes a memory 1302 and a processor 1304. The memory 1302 stores a computer program, and the processor 1304 is configured to execute the steps of any of the above method embodiments through the computer program.
[0226] Optionally, in this embodiment, the aforementioned electronic device may be located in at least one of a plurality of network devices in a computer network.
[0227] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:
[0228] S1, Obtain a first driving information set that matches the first object driving model, wherein the first object driving model is used to drive the target virtual object according to the control instructions received in the first object driving tool, and the first driving information set is used to indicate the driving relationship between the control instructions and the object actions performed by the target virtual object.
[0229] S2, obtain a first set of driving nodes and a second set of driving nodes from the first set of driving information, wherein the first set of driving nodes is used to indicate the preset driving relationship provided by the first object driving tool, and the second set of driving nodes is used to indicate the custom driving relationship included in the first object driving model.
[0230] S3, generate a set of driver code based on the first set of driver nodes and generate a set of target expressions based on the second set of driver nodes, wherein the set of driver code includes driver code corresponding to multiple driver nodes in the first set of driver nodes, and the set of target expressions includes driver expressions used to indicate the custom driver relationship.
[0231] S4, determine a second driving information set that matches the second object driving model based on the above driving code set and the above target expression set, wherein the above second object driving model is used to drive the above target virtual object according to the control instructions received in the second object driving tool.
[0232] Alternatively, as those skilled in the art will understand, Figure 13 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones (such as Android phones, iOS phones, etc.), tablets, PDAs, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 13 This does not limit the structure of the aforementioned electronic devices or electronic equipment. For example, electronic devices or electronic equipment may also include components that are more... Figure 13 The more or fewer components shown (such as network interfaces, etc.), or having the same Figure 13 The different configurations shown.
[0233] The memory 1302 can be used to store software programs and modules, such as the program instructions / modules corresponding to the object-driven model reconstruction method and apparatus in this embodiment of the invention. The processor 1304 executes various functional applications and data processing by running the software programs and modules stored in the memory 1302, thereby realizing the object-driven model reconstruction method described above. The memory 1302 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 1302 may further include memory remotely located relative to the processor 1304, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. Specifically, the memory 1302 may be used, but is not limited to, to store information such as various elements in the scene and reconstruction information of the object-driven model. As an example, such as Figure 13 As shown, the memory 1302 may include, but is not limited to, the first acquisition unit 1202, the second acquisition unit 1204, the reconstruction unit 1206, and the determination unit 1208 in the object-driven model reconstruction device described above. Furthermore, it may include, but is not limited to, other module units in the object-driven model reconstruction device described above, which will not be elaborated upon in this example.
[0234] Optionally, the transmission device 1306 described above is used to receive or send data via a network. Specific examples of the network described above may include wired networks and wireless networks. In one example, the transmission device 1306 includes a Network Interface Controller (NIC), which can be connected to other network devices and a router via a network cable to communicate with the Internet or a local area network. In another example, the transmission device 1306 is a Radio Frequency (RF) module, used for wireless communication with the Internet.
[0235] In addition, the aforementioned electronic device also includes: a display 1308 for displaying a virtual scene in the interface; and a connection bus 1310 for connecting various module components in the aforementioned electronic device.
[0236] According to another aspect of the present invention, an apparatus for reconstructing an object-driven model for implementing the above-described object-driven model reconstruction method is also provided. For example... Figure 14 As shown, the device includes:
[0237] The acquisition unit 1402 is used to acquire a second set of driving information that matches the second object-driven model in the second object-driven tool. The second set of driving information is determined based on a set of driving codes and a set of target expressions. The set of driving codes is generated based on a set of first driving nodes included in the first set of driving information that matches the first object-driven model. The set of target expressions is generated based on a set of second driving nodes included in the first set of driving information. The set of first driving nodes is used to indicate a preset driving relationship provided by the first object-driven tool. The set of second driving nodes is used to indicate a custom driving relationship included in the first object-driven model.
[0238] The receiving unit 1404 is configured to, in response to receiving an initial drive parameter set carried by a control command, determine a first target drive parameter set based on the initial drive parameter set and the drive code set, and determine a second target drive parameter set based on the initial drive parameter set and the target expression set.
[0239] The determining unit 1406 is used to determine the object transformation information of at least one second skeleton object in the second object-driven model based on the first target driving parameter set and the second target driving parameter set.
[0240] The driving unit 1408 is used to drive the target virtual object in the second object driving tool according to the object transformation information of at least one of the second skeleton objects.
[0241] Optionally, in this embodiment, the implementation of each of the above-mentioned unit modules can be referred to the above-mentioned method embodiments, which will not be repeated here.
[0242] According to another aspect of the present invention, an electronic device for implementing the above-described object-driven model reconstruction method is also provided, the electronic device being... Figure 15 The terminal device or server shown. This embodiment uses this electronic device as an example for illustration. Figure 15As shown, the electronic device includes a memory 1502 and a processor 1504. The memory 1502 stores a computer program, and the processor 1504 is configured to execute the steps of any of the above method embodiments via the computer program.
[0243] Optionally, in this embodiment, the aforementioned electronic device may be located in at least one of a plurality of network devices in a computer network.
[0244] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:
[0245] S1, in the second object-driven tool, obtain a second driving information set that matches the second object-driven model, wherein the second driving information set is determined based on the driving code set and the target expression set, the driving code set is generated based on the first driving node set included in the first driving information set that matches the first object-driven model, the target expression set is generated based on the second driving node set included in the first driving information set, the first driving node set is used to indicate the preset driving relationship provided by the first object-driven tool, and the second driving node set is used to indicate the custom driving relationship included in the first object-driven model;
[0246] S2, in response to receiving the initial drive parameter set carried by the control command, determine the first target drive parameter set according to the initial drive parameter set and the drive code set, and determine the second target drive parameter set according to the initial drive parameter set and the target expression set;
[0247] S3, determine the object transformation information of at least one second skeleton object in the second object-driven model based on the first target-driven parameter set and the second target-driven parameter set;
[0248] S4, based on the object transformation information of at least one of the second skeleton objects, drive the target virtual object in the second object driving tool.
[0249] Alternatively, as those skilled in the art will understand, Figure 15 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones (such as Android phones, iOS phones, etc.), tablets, PDAs, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 15 This does not limit the structure of the aforementioned electronic devices or electronic equipment. For example, electronic devices or electronic equipment may also include components that are more... Figure 15 The more or fewer components shown (such as network interfaces, etc.), or having the same Figure 15The different configurations shown.
[0250] The memory 1502 can be used to store software programs and modules, such as the program instructions / modules corresponding to the object-driven model reconstruction method and apparatus in this embodiment of the invention. The processor 1504 executes various functional applications and data processing by running the software programs and modules stored in the memory 1502, thereby realizing the object-driven model reconstruction method described above. The memory 1502 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 1502 may further include memory remotely located relative to the processor 1504, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. Specifically, the memory 1502 may be used, but is not limited to, to store information such as various elements in the scene and reconstruction information of the object-driven model. As an example, such as... Figure 15 As shown, the memory 1502 may include, but is not limited to, the acquisition unit 1402, the receiving unit 1404, the determining unit 1406, and the driving unit 1408 in the driving device for the virtual object. Furthermore, it may include, but is not limited to, other module units in the driving device for the virtual object, which will not be described further in this example.
[0251] Optionally, the transmission device 1506 described above is used to receive or send data via a network. Specific examples of the network described above may include wired networks and wireless networks. In one example, the transmission device 1506 includes a Network Interface Controller (NIC), which can be connected to other network devices and a router via a network cable to communicate with the Internet or a local area network. In another example, the transmission device 1506 is a Radio Frequency (RF) module, used for wireless communication with the Internet.
[0252] In addition, the aforementioned electronic device also includes: a display 1508 for displaying a virtual scene in the interface; and a connection bus 1510 for connecting various module components in the aforementioned electronic device.
[0253] In other embodiments, the aforementioned terminal device or server can be a node in a distributed system, wherein the distributed system can be a blockchain system, which is a distributed system formed by connecting multiple nodes through network communication. The nodes can form a peer-to-peer network, and any form of computing device, such as a server, terminal, or other electronic device, can become a node in the blockchain system by joining this peer-to-peer network.
[0254] According to one aspect of this application, a computer program product is provided, comprising a computer program / instructions containing program code for performing the methods shown in the flowchart. In such embodiments, the computer program can be downloaded and installed from a network via a communication component, and / or installed from a removable medium. When the computer program is executed by a central processing unit, it performs various functions provided in embodiments of this application.
[0255] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.
[0256] According to one aspect of this application, a computer-readable storage medium is provided, wherein a processor of a computer device reads computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform the driving method of the aforementioned virtual object.
[0257] Optionally, in this embodiment, the computer-readable storage medium may be configured to store a computer program for performing the following steps:
[0258] S1, Obtain a first driving information set that matches the first object driving model, wherein the first object driving model is used to drive the target virtual object according to the control instructions received in the first object driving tool, and the first driving information set is used to indicate the driving relationship between the control instructions and the object actions performed by the target virtual object.
[0259] S2, obtain a first set of driving nodes and a second set of driving nodes from the first set of driving information, wherein the first set of driving nodes is used to indicate the preset driving relationship provided by the first object driving tool, and the second set of driving nodes is used to indicate the custom driving relationship included in the first object driving model.
[0260] S3, generate a set of driver code based on the first set of driver nodes and generate a set of target expressions based on the second set of driver nodes, wherein the set of driver code includes driver code corresponding to multiple driver nodes in the first set of driver nodes, and the set of target expressions includes driver expressions used to indicate the custom driver relationship.
[0261] S4, determine a second driving information set that matches the second object driving model based on the above driving code set and the above target expression set, wherein the above second object driving model is used to drive the above target virtual object according to the control instructions received in the second object driving tool.
[0262] Optionally, in this embodiment, the computer-readable storage medium may also be configured to store a computer program for performing the following steps:
[0263] S1, in the second object-driven tool, obtain a second driving information set that matches the second object-driven model, wherein the second driving information set is determined based on the driving code set and the target expression set, the driving code set is generated based on the first driving node set included in the first driving information set that matches the first object-driven model, the target expression set is generated based on the second driving node set included in the first driving information set, the first driving node set is used to indicate the preset driving relationship provided by the first object-driven tool, and the second driving node set is used to indicate the custom driving relationship included in the first object-driven model;
[0264] S2, in response to receiving the initial drive parameter set carried by the control command, determine the first target drive parameter set according to the initial drive parameter set and the drive code set, and determine the second target drive parameter set according to the initial drive parameter set and the target expression set;
[0265] S3, determine the object transformation information of at least one second skeleton object in the second object-driven model based on the first target-driven parameter set and the second target-driven parameter set;
[0266] S4, based on the object transformation information of at least one of the second skeleton objects, drive the target virtual object in the second object driving tool.
[0267] Optionally, in this embodiment, those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.
[0268] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.
[0269] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.
[0270] In the several embodiments provided in this application, it should be understood that the disclosed client can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between units or modules, and may be electrical or other forms.
[0271] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0272] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0273] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.
Claims
1. A method for reconstructing an object-driven model, characterized in that, include: A first set of driving information matching the first object-driven model is obtained, wherein the first object-driven model is used to drive a target virtual object according to control instructions received in the first object-driven tool, and the first set of driving information is used to indicate the driving relationship between the control instructions and the object actions performed by the target virtual object. Obtain a first set of driving nodes and a second set of driving nodes from the first set of driving information, wherein the first set of driving nodes is used to indicate the preset driving relationship provided by the first object driving tool, and the second set of driving nodes is used to indicate the custom driving relationship included in the first object driving model. A set of driver code is generated based on the first set of driver nodes, and a set of target expressions is generated based on the second set of driver nodes. The set of driver code includes driver code corresponding to multiple driver nodes in the first set of driver nodes, and the set of target expressions includes driver expressions used to indicate the custom driver relationship. A second set of driving information matching the second object-driven model is determined based on the set of driving code and the set of target expressions, wherein the second object-driven model is used to drive the target virtual object according to the control instructions received in the second object-driven tool.
2. The method according to claim 1, characterized in that, The step of generating a driver code set based on the first driver node set includes: A first driver code subset is generated based on the traversal results of multiple driver nodes in the first driver node set. The first driver code subset is used to determine reference driver parameters based on initial driver parameters. The reference driver parameters are used to drive the first skeleton object in the first object-driven model in the first object-driven tool. Based on the object coordinate transformation relationship between the first object-driven tool and the second object-driven tool, a second driving code subset is obtained, wherein the second driving code subset is used to convert the reference driving parameters into target driving parameters, and the target driving parameters are used to drive the second skeleton object in the second object-driven model in the second object-driven tool; The driver code set is determined based on the first driver code subset and the second driver code subset.
3. The method according to claim 2, characterized in that, The step of generating a first driver code subset based on the traversal results of multiple driver nodes in the first driver node set includes: Obtain a node relationship graph that matches the first set of driver nodes, wherein the node relationship graph includes multiple driver node objects and node dependency relationships between the driver node objects, in the parent driver node object and child driver node object with the node dependency relationship, the parent driver node object is used to obtain a second driver calculation result based on the first driver calculation result output by the child driver node object, the leaf node in the node relationship graph is a controller node object, and the root node in the node relationship graph is the first skeleton object; The multiple driving node objects in the node relationship graph are traversed sequentially in ascending order of node hierarchy. Based on the traversal results of the driver node objects, the calculation code corresponding to each driver node object is stored in the first queue. During the operation of the second object driving tool, the first queue is used to call the calculation code corresponding to each driver node object, and the calculation results corresponding to each driver node object are stored in the created second queue. The plurality of computation codes that match the first queue are identified as the first subset of driver codes.
4. The method according to claim 2, characterized in that, The step of obtaining the second subset of driving code based on the object coordinate transformation relationship between the first object-driven tool and the second object-driven tool includes at least one of the following: Based on the first object coordinate transformation relationship indicated by the coordinate axis sequence corresponding to the first object driving tool and the second object driving tool, the first coordinate transformation code included in the second driving code subset is determined; Based on the second object coordinate transformation relationship indicated by the length unit corresponding to the first object driving tool and the second object driving tool, determine the second coordinate transformation code included in the second driving code subset; Based on the third object coordinate transformation relationship indicated by the initial angle of the skeletal object corresponding to the first object driving tool and the second object driving tool, the third coordinate transformation code included in the second driving code subset is determined.
5. The method according to claim 2, characterized in that, Determining the driver code set based on the first driver code subset and the second driver code subset includes: A third subset of driver code is generated based on the parameter interface provided by the second object driver tool, wherein the third subset of driver code is used to obtain the initial driver parameters from the second object driver tool according to control instructions; Update the computation code associated with the second skeleton object in the first driver code subset according to the second driver code subset; The updated first subset of driver code and the third subset of driver code are determined as the driver code set.
6. The method according to claim 1, characterized in that, The step of generating the target expression set based on the second set of driving nodes includes: Obtain at least one node chain included in the second set of driver nodes, wherein the node chain is used to indicate at least one driver node object associated with the custom driver relationship; The custom driving relationship indicated by at least one of the node chains is converted into at least one target expression included in the target expression set; Add at least one of the target expressions to the target expression file in the target format, wherein the target expression file is used to describe the custom driving relationship in the second object-driven tool.
7. The method according to claim 6, characterized in that, The step of converting the custom driving relationship indicated by at least one of the node chains into at least one target expression included in the target expression set includes: In the case where the node chain includes multiple second reference driver objects for driving the first bone object, a first target bone object matching the first bone object and a second target driver object matching the multiple second reference driver objects are created. The second target driver object is configured with multiple object attributes corresponding to the multiple second reference driver objects respectively. The object attributes are used to store the attribute values transmitted by the corresponding second reference driver object. Create a driving expression based on multiple object attributes, wherein the driving expression is used to determine a target attribute value based on the attribute values of the multiple object attributes, and the target attribute value is used to drive the first target skeleton object in the second object driving tool.
8. The method according to claim 6, characterized in that, After adding at least one of the target expressions to the target expression file in the target format, the method further includes at least one of the following: Add attribute identification information associated with the node chain to the target expression file; add value domain information matching the target expression to the target expression file.
9. The method according to claim 6, characterized in that, After adding at least one of the target expressions to the target expression file in the target format, the method further includes: In response to an edit operation on the second set of driver nodes, obtain the third set of driver nodes updated based on the second set of driver nodes; The updated target expression set is generated based on the third driving node set; A second set of driving information for indicating the second object-driven model is determined based on the set of driving codes and the updated set of target expressions.
10. The method according to claim 1, characterized in that, The step of determining the second driver information set matching the second object-driven model based on the driver code set and the target expression set further includes: Based on the first set of driving skeleton objects, the first set of skin mesh objects, and the first skin weight information included in the first object-driven model, the second set of driving skeleton objects, the second set of skin mesh objects, and the second skin weight information included in the second object-driven model are determined. The second object-driven model is determined based on the second set of driving skeleton objects, the second set of skinned mesh objects, the second skinning weight information, and the second set of driving information.
11. A method for driving virtual objects, characterized in that, include: A second set of driving information matching the second object-driven model is obtained in the second object-driven tool. The second set of driving information is determined based on a set of driving code and a set of target expressions. The set of driving code is generated based on a set of first driving nodes included in the first set of driving information matching the first object-driven model. The set of target expressions is generated based on a set of second driving nodes included in the first set of driving information. The first set of driving nodes is used to indicate a preset driving relationship provided by the first object-driven tool. The second set of driving nodes is used to indicate a custom driving relationship included in the first object-driven model. In response to receiving an initial drive parameter set carried by a control command, a first target drive parameter set is determined based on the initial drive parameter set and the drive code set, and a second target drive parameter set is determined based on the initial drive parameter set and the target expression set; Based on the first target driving parameter set and the second target driving parameter set, determine the object transformation information of at least one second skeleton object in the second object driving model; The target virtual object is driven in the second object driving tool based on the object transformation information of at least one of the second skeleton objects.
12. A reconstruction apparatus for an object-driven model, characterized in that, include: The first acquisition unit is used to acquire a first driving information set that matches the first object driving model, wherein the first object driving model is used to drive a target virtual object according to control instructions received in the first object driving tool, and the first driving information set is used to indicate the driving relationship between the control instructions and the object actions performed by the target virtual object; The second acquisition unit is used to acquire a first set of driving nodes and a second set of driving nodes from the first set of driving information, wherein the first set of driving nodes is used to indicate the preset driving relationship provided by the first object driving tool, and the second set of driving nodes is used to indicate the custom driving relationship included in the first object driving model. The reconstruction unit is configured to generate a set of driver code based on the first set of driver nodes and a set of target expressions based on the second set of driver nodes, wherein the set of driver code includes driver code corresponding to a plurality of driver nodes in the first set of driver nodes, and the set of target expressions includes driver expressions used to indicate the custom driver relationship. The determining unit is configured to determine a second set of driving information that matches the second object driving model based on the set of driving code and the set of target expressions, wherein the second object driving model is configured to drive the target virtual object according to the control instructions received in the second object driving tool.
13. A driving device for a virtual object, characterized in that, include: The acquisition unit is configured to acquire a second set of driving information matching the second object-driven model in the second object-driven tool, wherein the second set of driving information is determined based on a set of driving code and a set of target expressions, the set of driving code is generated based on a set of first driving nodes included in the first set of driving information matching the first object-driven model, and the set of target expressions is generated based on a set of second driving nodes included in the first set of driving information, the first set of driving nodes is used to indicate a preset driving relationship provided by the first object-driven tool, and the second set of driving nodes is used to indicate a custom driving relationship included in the first object-driven model; A receiving unit is configured to, in response to receiving an initial drive parameter set carried by a control command, determine a first target drive parameter set based on the initial drive parameter set and the drive code set, and determine a second target drive parameter set based on the initial drive parameter set and the target expression set; The determining unit is configured to determine object transformation information of at least one second skeleton object in the second object-driven model based on the first target driving parameter set and the second target driving parameter set. A driving unit is configured to drive the target virtual object in the second object driving tool based on the object transformation information of at least one second skeleton object.
14. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program, when executed, performs the method described in any one of claims 1 to 11.
15. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 11.
16. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the method described in any one of claims 1 to 11 through the computer program.