CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims benefit of U.S. provisional patent application Ser. No. 61/255,778, filed on Oct. 28, 2009, which is hereby incorporated by reference herein.

BACKGROUND OF THE INVENTION

1. Field of the Invention

Embodiments of the present invention relate generally to computer graphics, and, more specifically, to systems and methods for portable animation rigs.

2. Description of the Related Art

Prior art software graphics systems implement modeling, animation, and rendering functions that enable users to create three-dimensional (3D) models, animate the models, and render the models in a 3D graphics scene. Modeling typically involves creating geometric structures that represent a target 3D object. Modeling tools facilitate creating arbitrary shapes that may be moved or deformed according to a specific movement regime. Animation typically involves creating the movement regime for the target 3D object. The movement regime defines relative motion of geometry comprising the target 3D object and may also involve motion within a given graphics scene. For example, the movement regime may define how a humanoid model should implement movement for individual limbs, head movement, and composite movement activities such as walking or laughing. The movement regime may involve certain complex, algorithmically-defined rules governing movement, interdependencies of movement, and constraints placed on the movement.

Animation tools facilitate creating an animation “rig” used to define the movement regime of a target 3D object. The animation rig may include certain standard attributes as well as definitions of complex and algorithmically-defined behavior. Animation tools also facilitate creating animation sequences for the target 3D object based on the movement regime created for the target 3D object. An animation sequence includes a specific set of actions and motion for the target 3D object. One exemplary animation sequence comprises a humanoid model walking. Such an animation sequence includes specific motion curves for each geometric component of the humanoid model. The motion curves are generated in conjunction with an associated animation rig. Once the motion curves are generated for a specific animation sequence, the animation rig is no longer needed to reconstruct that specific sequence. However, generating a different animation sequence would require use of the animation rig to compute respective motion curves.

Rendering typically involves creating one or more frames of image data based on the target 3D object in a particular state of animation. The state of animation is substantially defined by motion curves for the target 3D object. Rendering tools facilitate rendering plural frames of image data corresponding to a particular animation sequence comprising motion curves for one or more target 3D objects.

Modeling, animation, and rendering operations comprise a complete graphics pipeline. In common usage models, different applications are used to perform these operations. For example, one application may implement a modeling tool that is used to create a specific 3D model, a second application may be used to create animation sequences from the 3D model, and a third application may be used to render the animation sequences. In one scenario, animation sequences are rendered to create clips of fixed content, such as portions of a movie. In another scenario, the animation sequences are rendered in real time as part of an interactive application, such as a game.

A 3D model may be exported from a modeling tool and imported into an animation tool via a standard file format that defines a standard representation of a 3D model. The 3D model comprises a geometric description of an object and may include additional attributes, such as texture placement information. Similarly, an animation sequence may be exported from an animation tool and imported by a rendering tool. The animation sequence includes motion curves that define animated movement for the object. However, an animation rig that provides animation setup and behavior within one tool may not have an analogous representation in another tool. As a result, certain animation information is lost when transporting a model or animation sequence from one application to another application. Such loss is unavoidable in the standard representation regime because new modeling features may be advantageously added to one application, but not another application.

As the foregoing illustrates, there is a need in the art for an improved technique for transporting an animation setup from one application to another.

SUMMARY

One embodiment of the invention provides a computer-implemented method for generating a behavioral component of an animation asset that is stored for future execution. The method includes attaining the animation asset including the behavior component; generating an executable representation corresponding to the behavioral component based on a virtual machine (VM) instruction set architecture (ISA); generating a transport file comprising the executable representation and a geometric object that is configured to be animated when the executable representation is executed; and saving the transport file in a storage system.

Another embodiment of the invention provides a computer-implemented method for reproducing a behavioral component of an animation asset. The method includes loading virtual machine instructions comprising an executable representation from a transport file into a memory for execution by a runtime engine; loading geometric object data from the transport file into the memory for manipulation when the executable representation is executed; and executing the executable representation to manipulate the geometric data.

One advantage of embodiments of the invention is that highly customized behaviors may be transported as animation assets between different execution platforms via a common virtual machine execution model. Embodiments of the present invention enable users to advantageously transport behavior as well as geometric construction between tools and playback platforms. This contrasts with prior art solutions, which typically only provide for transport of geometric information or very basic behaviors.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a computer system configured to implement one or more aspects of the present invention;

FIG. 2A illustrates a graphics authoring pipeline, according to one embodiment of the present invention;

FIG. 2B illustrates an interactive graphics pipeline, according to one embodiment of the present invention;

FIG. 3A illustrates a function curve block, according to one embodiment of the present invention;

FIG. 3B illustrates an exemplary motion clip evaluator, according to one embodiment of the present invention;

FIG. 3C illustrates an exemplary action controller, according to one embodiment of the present invention;

FIG. 4 illustrates an inter-platform workflow for transporting animation assets from an authoring platform to a target platform, according to one embodiment of the present invention;

FIG. 5 is a flow diagram of method steps for generating a transport file, according to one embodiment of the present invention; and

FIG. 6 is a flow diagram of method steps for manipulating a geometric object described within the transport file according to virtual machine instructions residing within the transport file, according to one embodiment of the present invention.

DETAILED DESCRIPTION

The details set forth below enable a person skilled in the art to implement the embodiments of the invention described herein. Certain details tied to a specific implementation are omitted for clarity.

System Architecture

FIG. 1 is a block diagram of a computer system 100 configured to implement one or more aspects of the present invention. The system architecture depicted in FIG. 1 in no way limits or is intended to limit the scope of the present invention. Computer system 100 may be a computer workstation, personal computer, video game console, personal digital assistant, rendering engine, or any other device suitable for practicing one or more embodiments of the present invention.

As shown, computer system 100 includes a central processing unit (CPU) 102 and a system memory 104 communicating via a bus path that may include a memory bridge 105. CPU 102 includes one or more processing cores, and, in operation, CPU 102 is the master processor of computer system 100, controlling and coordinating operations of other system components. System memory 104 stores software applications and data for use by CPU 102. CPU 102 runs software applications and optionally an operating system. Memory bridge 105, which may be, for example, a Northbridge chip, is connected via a bus or other communication path (e.g., a HyperTransport link) to an I/O (input/output) bridge 107. I/O bridge 107, which may be, for example, a Southbridge chip, receives user input from one or more user input devices 108 (e.g., keyboard, mouse, joystick, digitizer tablets, touch pads, touch screens, still or video cameras, motion sensors, and/or microphones) and forwards the input to CPU 102 via memory bridge 105. In some embodiments, input/output devices may include a radio frequency identification (RFID) tag and/or RFID reader. Additionally, any other technically feasible technique for implementing user identification is within the scope of embodiments of the invention.

A display processor 112 is coupled to memory bridge 105 via a bus or other communication path (e.g., a PCI Express, Accelerated Graphics Port, or HyperTransport link); in one embodiment display processor 112 is a graphics subsystem that includes at least one graphics processing unit (GPU) and graphics memory. Graphics memory includes a display memory (e.g., a frame buffer) used for storing pixel data for each pixel of an output image. Graphics memory can be integrated in the same device as the GPU, connected as a separate device with the GPU, and/or implemented within system memory 104.

Display processor 112 periodically delivers pixels to a display device 110 (e.g., a screen or conventional CRT, plasma, OLED, SED or LCD based monitor or television). Additionally, display processor 112 may output pixels to film recorders adapted to reproduce computer generated images, on photographic film. Display processor 112 can provide display device 110 with an analog or digital signal.

A system disk 114 is also connected to I/O bridge 107 and may be configured to store content and applications and data for use by CPU 102 and display processor 112. System disk 114 provides non-volatile storage for applications and data and may include fixed or removable hard disk drives, flash memory devices, and CD-ROM, DVD-ROM, Blu-ray, HD-DVD, or other magnetic, optical, or solid state storage devices.

A switch 116 provides connections between I/O bridge 107 and other components such as a network adapter 118 and various add-in cards 120 and 121. Network adapter 118 allows computer system 100 to communicate with other systems via an electronic communications network, and may include wired or wireless communication over local area networks and wide area networks such as the Internet.

Other components (not shown), including USB or other port connections, film recording devices, and the like, may also be connected to I/O bridge 107. For example, an audio processor may be used to generate analog or digital audio output from instructions and/or data provided by CPU 102, system memory 104, or system disk 114. Communication paths interconnecting the various components in FIG. 1 may be implemented using any suitable protocols, such as PCI (Peripheral Component Interconnect), PCI Express (PCI-E), AGP (Accelerated Graphics Port), HyperTransport, or any other bus or point-to-point communication protocol(s), and connections between different devices may use different protocols, as is known in the art.

In one embodiment, display processor 112 incorporates circuitry optimized for graphics and video processing, including, for example, video output circuitry, and constitutes a graphics processing unit (GPU). In another embodiment, display processor 112 incorporates circuitry optimized for general purpose processing. In yet another embodiment, display processor 112 may be integrated with one or more other system elements, such as the memory bridge 105, CPU 102, and I/O bridge 107 to form a system on chip (SoC). In still further embodiments, display processor 112 is omitted and software executed by CPU 102 performs the functions of display processor 112.

Pixel data can be provided to display processor 112 directly from CPU 102. In some embodiments of the present invention, instructions and/or data representing a scene are provided to a render farm or a set of server computers, each similar to computer system 100, via network adapter 118 or system disk 114. The render farm generates one or more rendered images of the scene using the provided instructions and/or data. These rendered images may be stored on computer-readable media in a digital format and optionally returned to computer system 100 for display. Similarly, stereo image pairs processed by display processor 112 may be output to other systems for display, stored in system disk 114, or stored on computer-readable media in a digital format.

Alternatively, CPU 102 provides display processor 112 with data and/or instructions defining the desired output images, from which display processor 112 generates the pixel data of one or more output images, including characterizing and/or adjusting the offset between stereo image pairs. The data and/or instructions defining the desired output images can be stored in system memory 104 or graphics memory within display processor 112. In one embodiment, display processor 112 includes 3D rendering capabilities for generating pixel data for output images from instructions and data defining the geometry, lighting shading, texturing, motion, and/or camera parameters for a scene. Display processor 112 can further include one or more programmable execution units capable of executing shader programs, tone mapping programs, and the like.

It will be appreciated that the system shown herein is illustrative and that variations and modifications are possible. The connection topology, including the number and arrangement of bridges, may be modified as desired. For instance, in some embodiments, system memory 104 is connected to CPU 102 directly rather than through a bridge, and other devices communicate with system memory 104 via memory bridge 105 and CPU 102. In other alternative topologies display processor 112 is connected to I/O bridge 107 or directly to CPU 102, rather than to memory bridge 105. In still other embodiments, I/O bridge 107 and memory bridge 105 might be integrated into a single chip. The particular components shown herein are optional; for instance, any number of add-in cards or peripheral devices might be supported. In some embodiments, switch 116 is eliminated, and network adapter 118 and add-in cards 120, 121 connect directly to I/O bridge 107.

FIG. 2A illustrates a graphics authoring pipeline 200, according to one embodiment of the present invention. The graphics authoring pipeline 200 includes a 3D modeling application 212, an animation application 214, and a rendering application 216. In one embodiment, the modeling application 212, animation application 214, and rendering application 216 are separate software applications. In alternative embodiments, an application suite may combine the functions of two or more of the applications 212, 214, 216. Users may author graphics content using one or more different 3D modeling applications, animation applications, or rendering applications based on specific technical requirements.

The 3D modeling application 212 enables a user to form a geometric model representing a desired 3D object. For example, the user may use the 3D modeling application 212 to generate a geometric model of a teapot or a game character. Conventional geometric models comprise meshes of geometric primitives, such as triangles. The animation application 214 enables the user to describe motion for the 3D object. The animation application 214 generates function curves that describe motion of various geometric components of the 3D model. Many common 3D objects exhibit complex behavior and the behavior is conventionally represented by an animation “rig.” The rig imparts movement constraints, interdependences, and any other algorithmically determined movement properties for the 3D object. The rendering application 216 receives a sequence of discrete frames of scene information from a scene, with each frame comprising descriptions of plural 3D objects. The rendering application 216 renders each frame of scene information into a sequence of rendered frames 222 for storage or display. Persons skilled in the art will understand that specific functions of the 3D modeling application 212, animation application 214, and rendering application 216 may be implemented using any technically feasible technique.

Animation data 220 may comprise a 3D model 230, an animation rig 232, and evaluated animation data 234. The 3D model includes geometric primitives that collectively describe a 3D object. The animation rig 232 includes a behavioral description of the 3D model 230. Evaluated animation data 234 includes evaluated animation sequence data for a specific motion sequences for the 3D model 230. For example, the 3D model 230 may describe a humanoid form comprising movable components, such as a head and limbs, eyes, and muscle forms. The animation rig 232 describes how the movable components move to simulate actions such as walking or laughing. The evaluated animation data 234 describes a specific walking or laughing sequence.

In prior art systems, only the 3D model 230 and evaluated animation data 234 are transportable between disparate systems. Thus, in prior art system, new or different animation sequences can not be generated from the animation rig 232 outside the original animation application 214 used to construct the animation rig 232. If a different animation application needs to be used, a new animation rig needs to be created first. Thus, prior art solutions present challenges when multiple different tools of similar function are brought together in the graphics authoring pipeline 200, or when an interactive application could benefit from the animation rig 232 for real time animation applications.

In embodiments of the present invention, the animation rig 232 includes a functional description of animation computations. The functional description may be described as a directed graph (DG), a directed acyclic graph (DAG), or any other technically feasible description. The functional description includes specific computational steps for transforming input parameters into output parameters. The computational steps can be described in terms of a graphical representation or a language representation, or any combination thereof. The computational steps are compiled into instructions for a virtual machine. Any technically feasible virtual machine may be used, and any sufficiently general set of virtual machine instructions may specify an instruction set architecture for the virtual machine. In one embodiment, each application configured to receive the animation rig 232 includes a runtime engine that is able to execute the virtual machine instructions associated with the animation rig. Importantly, a common virtual machine instruction set architecture is implemented in each runtime engine for identical execution and identical results. Persons skilled in the art will recognize that execution of virtual machine instructions may be performed using various different techniques. For example, execution may be performed by interpreting virtual machine instructions directly or by dynamically compiling the virtual machine instructions into executable native code modules.

FIG. 2B illustrates an interactive graphics pipeline 202, according to one embodiment of the present invention. The interactive graphics pipeline 202 is characterized by an interactive application 240 that receives animation data 220 and user input 250, and generates rendered frames 222. The interactive application 240 includes an interactive logic engine 242, a runtime animation engine 244, and a rendering engine 248. The interactive logic engine 242 defines the user experience for the interactive application 240. One example of the interactive logic engine 242 is a game engine. The game engine defines a setting for a game, and game play for the game. Persons skilled in the art will recognize that other types of interactive logic engines may be implemented without departing the scope of the present invention.

The runtime animation engine 244 generates frame data 246 comprising sequential frames of geometric objects being animated. Descriptions of the geometric objects may reside in the animation data 220. For example, 3D model 230 may be animated according to the animation rig 232 for creating sequential frames comprising frame data 246. The rendering engine 248 renders the frame data 246 to generate a corresponding sequence of images represented by the rendered frames 222.

The animation data 220, comprising the 3D model 230 and animation rig 232, may be created using the graphics authoring pipeline 200 and transported to the interactive graphics pipeline 202 without loss of information and without introducing computational discrepancies within the animation rig 232.

FIG. 3A illustrates a function curve block 310, according to one embodiment of the present invention. The function curve block 310 includes an arbitrary function 326, a value array 320, a time input 312, and a value output 318. The time input 312 is received via input interface 314 (represented by a circle), and the value output 318 is transmitted via output interface 316 (also represented by a circle).

The functional curve block 310 generates the value output 318 based on the function 326 and data within value array 320, comprises data values 322. In one embodiment the function 326 is a cubic evaluation function and value array 320 stores coefficients as data values 322 for the cubic evaluation function. The value output 318 is a function of time input 312, and represents one of potentially plural parameters that describe animation for a 3D object.

FIG. 3B illustrates an exemplary motion clip evaluator 330, according to one embodiment of the present invention. The motion clip evaluator 330 may include plural function curve blocks 332, each substantially reflecting the structure and operation of functional curve block 310. Each function curve block 332 receives time input 312 and generates a respective value output 334. A value to state module 340 generates detailed state information for a related 3D object. The state information may include, without limitation, specific geometric position information for a given frame of animation for the 3D object. The state information is reflected in state output 342. In this way, the motion clip evaluator 330 generates a sequence of geometric state information presented as state output 342 as a function of time input 312.

FIG. 3C illustrates an exemplary action controller 350, according to one embodiment of the present invention. The action controller 350 includes motion clip evaluators 352, custom functions 360, and action evaluator 354. Each motion clip evaluator 352 is configured to generate a specific aspect of geometric state information in response to a value of modified time 313. Each custom function 360 receives state information and performs a respective set of one or more operations on the state information to generate further state information. Custom function 360-3 generates output state 362. Action evaluator 354 receives time input 312 and generates modified time 313, used as inputs to the motion clip evaluators 352. Action evaluator 354 also receives action control information 356, which specifies specific actions related to the action evaluator 354. One example of an action controller generates a 3D object reflecting a humanoid performing a specified action, such as walking. The time input 312 determines what stage of walking, for example, the humanoid 3D object represents. The action control 356 may control what type of walking gate or style is reflected in an overall animation sequence of walking.

The action controller 350 and computational elements within the action controller 350, such as motion clip evaluator 330 and function curve block 310, may be incorporated into animation rig 232. In one embodiment, the computational elements may be represented and computed via compiled virtual machine code. Importantly, the animation rig, which specifies behavior for a 3D object, may be transported to another application or even another target platform via the compiled virtual machine code.

FIG. 4 illustrates an inter-platform workflow 400 for transporting animation assets from an authoring platform to a target platform, according to one embodiment of the present invention. An animation asset may include, for example, a 3D object and one or more related animation rigs. Authoring platform 410 may comprise a computer system, such as computer system 100 of FIG. 1, configured to run an authoring tool suite 420. The authoring tool suite 420 may include 3D modeling application 212 of FIG. 2A, animation application 214, and rendering application 216, or any technically feasible combination thereof. The authoring tool suite 420 is typically required to perform exemplary animation sequences, and may invoke computational elements, such as those illustrated in FIGS. 3A-3C during normal authoring activities. Runtime engine 422 is configured to perform computations associated with the computational elements via compiled virtual machine code, generated by an asset compiler 430. Animation assets may be stored within asset library 440, residing in system disk 114, system memory 104, a network attached storage system (not shown), or any combination thereof.

In one embodiment, authoring tool suite 420 is used to create a particular animation asset 460, comprising a 3D object and an animation rig. The animation asset 460 may be stored within the asset library 440. After the animation asset 460 is created on the authoring platform 410, the animation asset 460 is transported to a target platform 450. Virtual machine code 427 associated with the animation asset 460 is executed in a platform runtime engine 452 residing within the target platform 450. The target platform 450 may be a game system or another computer system. Behavior associated with the animation asset 460 is transported as virtual machine instructions that may be executed identically on both the authoring platform 410 and the target platform 450.

The runtime engine 422 and platform runtime engine 452 may be developed from different source platforms, including Autodesk® Maya®, Autodesk® 3ds Max®, Autodesk® MotionBuilder®, or any other animation, authoring, and/or rendering tool.

Using conventional techniques, a scene description comprising animation assets associated with one platform cannot be easily converted into a scene description associated with a different platform (i.e., the target platform). In the prior art, the target platform may attempt to determine if solvers (i.e., functions) associated with the target platform are analogous to solvers in the scene description that are associated with the source platform. If no match is found, then the target platform chooses the “closest” solver, which may result in an awkward-looking representation. In some prior art systems, the scene description associated with a source platform is “baked” into a format that can be read by the target platform. Baking is a term commonly used to refer to the process of evaluating, at each frame of an animation, the values of the various parameters of the solvers in the source platform and exporting the results to a conventional (e.g., image) format. However, when the scene description is baked, all control of the parameters is lost and cannot be edited in the target platform. Embodiments of the invention solve these problems.

Embodiments of the invention differ significantly from prior art approaches in that they do not require the scene description associated with the source platform to “fit” into a “standard representation,” as described above. Because a separate intermediate solver can be implemented for each node in the scene description in each different authoring (source) platform, embodiments of the invention provide for substantially the same evaluation of the scene description in any supported target platform, independent of the source platform. Each target platform (e.g., authoring tool, game engine, etc.) is implemented with a virtual machine that is able to understand and evaluate the code that is transported.

In some embodiments, the software application is able to create a list of tasks that can be evaluated in parallel and distribute the work to a multi-core parallel processor. Also, in some embodiments, the code generated can be multithreaded, parallelized, or distributed on multi-cores. In certain embodiments, the virtual machine optimizes task scheduling to take full advantage of multi-core architecture. A micro evaluation kernel may serve as a runtime engine to evaluate the virtual instructions on the target platform. In some embodiments, there is at least one different implementation of a runtime engine per target platform.

Accordingly, a scene description in a given target platform is evaluated to substantially the same result as the scene description in the source platform. This approach allows developers to work together more easily across various platforms. Also, in animation, since results of evaluating a scene description in the source and target platforms are the same, consistency is achieved between platforms.

FIG. 5 is a flow diagram of method steps 500 for generating a transport file, according to one embodiment of the present invention. Although the method steps are described in conjunction with the systems of FIGS. 1-4, persons skilled in the art will understand that any system configured to perform the method steps, in any order, is within the scope of the invention.

The method begins is step 502, where asset compiler 430 of FIG. 4 receives a scene description including an animation asset comprising a geometric object and custom function for manipulating the geometric object. In step 504, the asset compiler 430 compiles a custom function from the animation asset into virtual machine instructions. In step 506, the asset compiler 430 generates transport file 425 comprising compiled virtual machine instructions (code) 427 for the custom function and a description of the geometric object. The method terminates in step 590, where the asset compiler 430 saves the transport file 590 to non-volatile storage, such as system disk 114 of FIG. 1.

FIG. 6 is a flow diagram of method steps 600 for manipulating a geometric object described within the transport file according to virtual machine instructions residing within the transport file, according to one embodiment of the present invention. Although the method steps are described in conjunction with the systems of FIGS. 1-4, persons skilled in the art will understand that any system configured to perform the method steps, in any order, is within the scope of the invention.

The method begins in step 602, where target platform 450 loads virtual machine instructions 427 from transport file 425 into memory for execution by runtime engine 452. In step 604, target platform 450 loads geometric object data from transport file 425 into memory for manipulation. In step 490, the runtime engine 452 executes the virtual machine instructions 427 to manipulate the geometric object. The method terminates in step 490.

One advantage of the present invention is that highly customized behaviors may be transported as animation assets between different execution platforms via a common virtual machine execution model. Embodiments of the present invention enable users to advantageously transport behavior as well as geometric construction between tools and playback platforms. This contrasts with prior art solutions, which typically only provide for transport of geometric information or very basic behaviors.

Various embodiments of the invention may be implemented as a program product for use with a computer system. The program(s) of the program product define functions of the embodiments (including the methods described herein) and can be contained on a variety of computer-readable storage media. Illustrative computer-readable storage media include, but are not limited to: (i) non-writable storage media (e.g., read-only memory devices within a computer such as CD-ROM disks readable by a CD-ROM drive, flash memory, ROM chips or any type of solid-state non-volatile semiconductor memory) on which information is permanently stored; and (ii) writable storage media (e.g., floppy disks within a diskette drive or hard-disk drive or any type of solid-state random-access semiconductor memory) on which alterable information is stored.

The invention has been described above with reference to specific embodiments and numerous specific details are set forth to provide a more thorough understanding of the invention. Persons skilled in the art, however, will understand that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The foregoing description and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.