WO2005114586A1 - Procedes de traitement de scenes complexes - Google Patents

Procedes de traitement de scenes complexes Download PDF

Info

Publication number
WO2005114586A1
WO2005114586A1 PCT/US2004/014604 US2004014604W WO2005114586A1 WO 2005114586 A1 WO2005114586 A1 WO 2005114586A1 US 2004014604 W US2004014604 W US 2004014604W WO 2005114586 A1 WO2005114586 A1 WO 2005114586A1
Authority
WO
WIPO (PCT)
Prior art keywords
model
models
information
inputs
outputs
Prior art date
Application number
PCT/US2004/014604
Other languages
English (en)
Inventor
Frank Sebastian Grassia
Marco Jorge Da Silva
Original Assignee
Pixar
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Pixar filed Critical Pixar
Priority to PCT/US2004/014604 priority Critical patent/WO2005114586A1/fr
Publication of WO2005114586A1 publication Critical patent/WO2005114586A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T13/00—Animation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T17/00—Three dimensional [3D] modelling, e.g. data description of 3D objects

Definitions

  • the present application relates to computer-generated imagery (CGI) and animation, and more particularly to techniques for processing and manipulating complex scenes.
  • CGI computer-generated imagery
  • a model is generally a collection of geometric primitives, mathematical representations, and other information that is used to describe the shape and behavior of an object. Accordingly, a scene may comprise multiple objects (each represented by a model) interacting with each other.
  • Scenes are generally created by animators that specify the movement of the models and the interactions between the models.
  • information related to all the models involved in the scene must be loaded into memory of the animator's computer or workstation.
  • the computing and memory resources of the animator's computer are inadequate to load and process all the models involved in a scene.
  • the increasing complexity of scenes has also impacted the manner in which scenes are rendered.
  • One conventional technique that is used to try to resolve the above-mentioned problems is to reduce the complexity of a scene. This is done by representing each object in a scene at a low-fidelity that consumes less memory when loaded into computer memory of a computer. The low fidelity representations also evaluate more rapidly than the final (render) quality versions. However, even with the low-fidelity versions of the models, there is a limit to the number of models that can be loaded into computer memory simultaneously. Further, as more and more models are loaded, the interactions between the models considerably slow down thereby making the animation task slow and arduous. Also, extra work on part of the animators is needed to build low-fidelity versions of models and swap them in and out of scenes. This technique also does not help during the rendering process since final rendering generally requires the highest-fidelity (or full-fidelity) versions of the models to be used.
  • Another conventional technique that is commonly used to process large scenes is scene segmentation.
  • a user e.g., an animator
  • the resultant sub-scene images are then composited together.
  • This decomposition is however artificial and an impediment to the creative process. Further, it may be very difficult or even impossible to break up a scene in which many models are interacting with one another.
  • Embodiments of the present invention provide techniques for processing scenes of arbitrary complexity comprising a number of objects represented by models. Each model may comprise one or more inputs and outputs.
  • Embodiments of the present invention provide techniques for building a representation in memory that stores information or represents the inter and intra-model dependencies between the various inputs and outputs of the models included in a scene.
  • the memory representation is built based upon intra-model dependencies information and cues information for the scene.
  • the memory representation is a graph comprising a number of nodes and directed links between the nodes.
  • the nodes in the graph represent (are proxies for) inputs and outputs of the models involved in the scene.
  • the directed links between the nodes represent the intra- and inter-model dependencies between the inputs and outputs.
  • information is received specifying a time interval for a scene comprising a plurality of models comprising one or more inputs and outputs.
  • First information is accessed for the scene, the first information identifying time- varying dependencies of the plurality of models.
  • Intra-model dependency information is accessed for one or more models in the plurality of models, the intra-model dependency information for a model identifying one or more static dependencies of one or more outputs of the model on one or more inputs of the model.
  • a first representation is built based upon the first information and the intra-model dependency information for the one or more models in the plurality of models, the first representation comprising information identifying the one or more inputs and outputs of the models in the plurality of models and identifying dependencies between the one or more inputs and outputs.
  • the first representation is a directed graph comprising a plurality of nodes and directed links between the nodes, wherein the nodes represent the one or more inputs and outputs of the plurality of models and the directed links represent the dependencies between the one or more inputs and outputs.
  • FIG. 1 is a simplified block diagram of a computer system 100 that may be used to practice an embodiment of the present invention
  • FIG. 2 depicts a schematic representation of a Human model according to an embodiment of the present invention
  • FIG. 3 is a simplified high-level flowchart depicting a method of processing models in a scene to determine static intra-model dependencies for the models according to an embodiment of the present invention
  • Fig. 4 depicts a module that may be used to determine and store static intra-model dependency information according to an embodiment of the present invention
  • FIG. 5 is a simplified high-level flowchart depicting a method of constructing a proxy connectivity graph according to an embodiment of the present invention
  • Fig. 6 depicts a schematic view of a proxy connection graph according to an embodiment of the present invention.
  • FIG. 7 A is a simplified high-level flowchart depicting a method of loading models for animation according to an embodiment of the present invention
  • FIG. 7B is a simplified high-level flowchart 720 depicting a method of unloading models from computer memory according to an embodiment of the present invention
  • Fig. 8 depicts modules that may be used to construct and manipulate a proxy connectivity graph according to an embodiment of the present invention
  • FIG. 9 is a simplified high-level flowchart depicting processing performed to facilitate rendering of a scene according to an embodiment of the present invention.
  • Fig. 10 depicts modules that may be used to perform the processing depicted in Fig. 9 according to an embodiment of the present invention.
  • Figs. 11 A through 1 IF depict various stages of clustering nodes in a linear ordered list according to an embodiment of the present invention.
  • DETAILED DESCRIPTION OF THE INVENTION [0027] In the following description, for the purposes of explanation, specific details are set forth in order to provide a thorough understanding of the invention. However, it will be apparent that the invention may be practiced without these specific details.
  • Embodiments of the present invention provide techniques for processing large and complex scenes.
  • Artists such as animators, Tenderers, and layout artists can work with complex scenes in a natural way without having to worry about the complexities of the scene, available memory and/or computing resources, scene segmentation, different fidelity representations, and dependencies between models in a scene.
  • Fig. 1 is a simplified block diagram of a computer system 100 that may be used to practice an embodiment of the present invention.
  • systems such as computer system 100 may be used by an animator to specify or assemble a scene.
  • Systems such as computer system 100 may also be used to render scenes.
  • computer system 100 includes a processor 102 that communicates with a number of peripheral devices via a bus subsystem 104.
  • peripheral devices may include a storage subsystem 106, comprising a memory subsystem 108 and a file storage subsystem 110, user interface input devices 112, user interface output devices 114, and a network interface subsystem 116.
  • the input and output devices allow a user, such as the administrator, to interact with computer system 100.
  • Network interface subsystem 116 provides an interface to other computer systems, and networks.
  • Network interface subsystem 116 serves as an interface for receiving data from other sources and for transmitting data to other sources from computer system 100.
  • Embodiments of network interface subsystem 116 include an Ethernet card, a modem (telephone, satellite, cable, ISDN, etc.), (asynchronous) digital subscriber line (DSL) units, and the like.
  • User interface input devices 112 may include a keyboard, pointing devices such as a mouse, trackball, touchpad, or graphics tablet, a scanner, a barcode scanner, a touchscreen incorporated into the display, audio input devices such as voice recognition systems, microphones, and other types of input devices.
  • input device is intended to include all possible types of devices and mechanisms for inputting information to computer system 100.
  • User interface output devices 114 may include a display subsystem, a printer, a fax machine, or non- visual displays such as audio output devices, etc.
  • the display subsystem may be a cathode ray tube (CRT), a flat-panel device such as a liquid crystal display (LCD), or a projection device.
  • output device is intended to include all possible types of devices and mechanisms for outputting information from computer system 100.
  • Storage subsystem 106 may be configured to store the basic programming and data constructs that provide the functionality of the present invention. For example, according to an embodiment of the present invention, software code modules (or instructions) implementing the functionality of the present invention may be stored in storage subsystem 106. These software modules may be executed by processor(s) 102. Storage subsystem 106 may also provide a repository for storing data used in accordance with the present invention. Storage subsystem 106 may comprise memory subsystem 108 and file/disk storage subsystem 110.
  • Memory subsystem 108 may include a number of memories including a main random access memory (RAM) 118 for storage of instructions and data during program execution and a read only memory (ROM) 120 in which fixed instructions are stored.
  • RAM is generally semiconductor-based memory that can be read and written by processor 102. The storage locations can be accessed in any order.
  • the term RAM is generally understood to refer to volatile memory that can be written to as well as read. There are various different types of RAM. For purposes of this application, references to information being loaded or unloaded from compute memory refer to loading or unloading the information from RAM (or any other volatile computer memory used by a program or process during execution) of a computer.
  • File storage subsystem 110 provides persistent (non- volatile) storage and caching for program and data files, and may include a hard disk drive, a floppy disk drive along with associated removable media, a Compact Disk Read Only Memory (CD-ROM) drive, an optical drive, removable media cartridges, and other like storage media.
  • a hard disk drive e.g., a hard disk drive, a floppy disk drive along with associated removable media, a Compact Disk Read Only Memory (CD-ROM) drive, an optical drive, removable media cartridges, and other like storage media.
  • CD-ROM Compact Disk Read Only Memory
  • Bus subsystem 104 provides a mechanism for letting the various components and subsystems of computer system 100 communicate with each other as intended. Although bus subsystem 104 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple busses.
  • Computer system 100 can be of various types including a personal computer, a portable computer, a workstation, a network computer, a mainframe, a kiosk, or any other data processing system. Due to the ever-changing nature of computers and networks, the description of computer system 100 depicted in Fig. 1 is intended only as a specific example for purposes of illustrating the preferred embodiment of the computer system. Many other configurations having more or fewer components than the system depicted in Fig. 1 are possible.
  • a scene refers to a set of frames shot (generally continuously) using a camera between a start time and an end time.
  • Scenes are generally specified (or assembled) by one or more animators.
  • Information stored for a scene may include camera angles information, lighting information, the starting time and ending time for the scene, information identifying the models in a scene, descriptions of the models, description of how the models interact or move within a scene, and other information.
  • the information may be stored in a scene data file, as a scene graph, etc.
  • the stored scene information is then used to render the scene so that is can be viewed by animators, and others.
  • the process of specifying a scene is typically an iterative process where an animator assembles a scene, views the rendered scene, makes changes to the scene if necessary, and repeats the process.
  • a scene may include a number of obj ects or components possibly interacting with one another.
  • Each object may be represented by a model.
  • a model is generally a collection of geometric primitives, mathematical representations, and other information that is used to describe the shape and behavior of an object. Information specifying a model may be referred to as model information.
  • Each model may comprise (or is characterized by) a set of input parameters (or inputs) and a set of outputs. Values may be provided to the inputs to position and configure the geometric primitives of the model. Values of the outputs may represent the orientation and position of the geometric primitives of the model.
  • An input of a model may receive its value from (and thus depend upon) one or more outputs of other models or of the same model.
  • An output of a model may receive its value from (and thus depend on) one or more inputs of the model, i.e., values of the inputs are used to compute the output's value.
  • Dependencies may also be classified as intra-model or inter-model.
  • Intra and inter-model dependencies may arise from constraints placed by the animator on a model and between models.
  • a model A depends on another model B if model A makes use of data provided by model B.
  • model A depends directly on model B if an input or output of model A uses a value of an input or output of model B.
  • Model B may in turn depend on other models, which may in turn depend on other models, and so on.
  • Model A indirectly depends on models that model B depends on, models that those models depend on, and so on.
  • model A depends on model B which depends on model C which in turn depends on model D
  • model A depends directly on model B and indirectly on models C and D.
  • the set of models that model A depends on includes all models on which model A directly or indirectly depends on.
  • the set of models on which model A depends includes models B, C, and D.
  • the set may also be referred to as the transitive closure set of models that model A depends on.
  • models A, B, and C represent the models that depend upon model D. Accordingly, a set comprising models A, B, and C represents a transitive closure set of models that depend on model D.
  • Two models may exhibit a dependency where model A depends on model B and model B depends on model A, although there can be no input/output pair anywhere in a scene at any particular time in which the input depends on the output and the output also depends on the input, as that would cause the output's value to be incomputable
  • Dependencies may either be static or dynamic in nature.
  • a static dependency is a dependency that is fixed or time invariant over a period of time.
  • a dynamic dependency is a dependency that may be time variant over a period of time.
  • An intra-model dependency where an output of a model depends on one or more inputs of the same model is generally a static dependency that is configured when the model is built.
  • FIG. 2 depicts a schematic representation of a Human model 200 according to an embodiment of the present invention.
  • Human model 200 comprises three inputs (shown by diamonds and having an "In” label ending) and three outputs (shown by circles and having an "Out” label ending).
  • the inputs include waistln (HWI), headOrientln (HHI), and rHandln (HRI).
  • the outputs include waistOut (HWO), neckOut (HNO), and lHandOut (HLO).
  • dotted arrows 202 are used to represent the static intra-model dependencies where an output of the model depends on one or more inputs of the same model.
  • the arrows point in the direction of the dependency. For example, as shown, neckOut (HNO) depends on waistln (HWI), lHandOut (HLO) depends on waistln (HWI) and waistOut (HWO) depends on waistln (HWI).
  • HNO neckOut
  • HLO lHandOut
  • HWO waistOut
  • the inter-model dependencies for the scene are depicted in Fig. 6 and described below.
  • the model information for each model included in a scene is analyzed to determine the static intra-model dependencies (or static intra-model dataflow connections) between inputs and outputs of the model.
  • the static intra-model dependency information (or static intra-model dataflow connection information) for a model is persistently cached.
  • Various different techniques may be used for caching the static intra- model dependency information.
  • the static intra-model dependency information for a model is stored in a file (referred to as the "hook file" or "hook") associated with the model.
  • a hook file for a model may also store other information for the model besides dependency information.
  • the information may be stored in various formats.
  • the information is stored in the form of a directed graph such that the nodes of the graph represent (are proxies for) the inputs or outputs of a model and the links between the nodes represent the static intra-model dataflow connections.
  • Other data structures may also be used in alternative embodiments.
  • FIG. 1 An example of static intra-model dependency information that may be stored in a hook file is shown below.
  • the hook file comprising the information below is associated with a Human model (different from the model depicted in Fig. 2).
  • the "inputHandles” identifies the inputs of the Human model, namely, waistln, headOrientln, rHandln, and lHandln.
  • the “outputHandles” identifies the outputs of the model and also their static intra-model dependencies. As shown above, there are four outputs, namely, waistOut, neckOut, rHandOut, and lHandout.
  • the output waistOut depends on input waistln
  • the output neckOut depends on input waistln
  • the output rHandOut depends on inputs rHandln and waistln
  • the output lHandOut depends on inputs lHandln and waistln.
  • Fig. 3 is a simplified high-level flowchart 300 depicting a method of processing models in a scene to determine static intra-model dependencies for the models according to an embodiment of the present invention.
  • the method depicted in Fig. 3 may be performed by software modules executed by a processor, hardware modules, or combinations thereof.
  • Flowchart 300 depicted in Fig. 3 is merely illustrative of an embodiment of the present invention and is not intended to limit the scope of the present invention. Other variations, modifications, and alternatives are also within the scope of the present invention.
  • the method depicted in Fig. 3 may be adapted to work with different implementation constraints.
  • processing is initiated upon receiving information identifying a scene (step 302).
  • the scene information is then analyzed to determine the one or more models involved in the scene (step 304).
  • the scene information may be stored in various forms such as a scene graph, etc. and may be used to perform the analysis in step 302.
  • Model information for each model identified in step 304 is then accessed and the static intra-model dependencies of the outputs of a model on the inputs of the model are determined for each model (step 306).
  • each model is loaded into computer memory (i.e., the model information for the model is loaded into computer memory), the dependencies determined using the loaded model information, and then the model may be unloaded from the computer memory. Accordingly, all the models (i.e., the model information for all the models) do not need to be loaded into computer memory concurrently to determine static intra-model dependency information. For each model, the static intra-model dependency information determined for the model in step 306 is then persistently stored, for example in a hook file that is associated with the model (step 308). [0051] In alternative embodiments, instead of doing the analysis on a scene basis as depicted in Fig.
  • the intra-model static dependencies for a model may be determined and stored in a hook file associated with the model when the model is built or configured. Accordingly, whenever the model is subsequently used, the static intra-model dependency information for the model is available for processing from the hook file associated with the model. If a model is modified (i.e., model information for the model is changed), the dependency information stored in the hook file associated with the model may be updated to reflect the dependency changes, if any, resulting from the changed model information.
  • a user may select or specify the models for which intra- model dependency information is to be computed.
  • the model information for the model is analyzed to determine the static intra-model dependencies for the model, and the dependency information is cached in a hook file associated with the model.
  • Fig. 4 depicts a module that may be used to determine and store static intra-model dependency information according to an embodiment of the present invention.
  • an intra-model dependency analyzer 400 may be provided.
  • Intra-model dependency analyzer 400 takes as input model information 402 for a model, analyzes model information 402 to determine the static intra-model dependency information, and stores the dependency information in a hook file 404 associated with the model or with the model information.
  • Intra-model dependency analyzer 400 may be implemented using software, hardware, or combinations thereof. ,
  • the authored data that represents the animations for the model in the scene is stored in a cue.
  • the cue stores information describing the inter- and intra-model dataflow connections among the models for the scene.
  • the cue stores time varying specification for inputs of models that is used to pose the models.
  • Cues may store time-varying (i.e., dynamic) dependencies between the models, including the intra- and inter- model dependencies between the inputs and outputs of models.
  • a representation is constructed in memory for the scene.
  • the memory representation that is constructed stores information specifying the inter- and intra- model dependencies (i.e., the inter- and intra-model dataflow connections) between the various inputs and outputs of the models included in a scene.
  • the memory representation encapsulates the relationships between the models in a scene.
  • the memory representation is a directed graph, referred to as a proxy connectivity graph.
  • Other data structures may also be used for the memory representation in alternative embodiments.
  • the nodes of the proxy connectivity graph represent (are proxies for) inputs and outputs of the models of the scene and the directed links between the nodes represent the dataflow connections or dependencies (both static and dynamic inter-model and intra-model dependencies) between the inputs and outputs of the models.
  • the words proxy and node will be used interchangeably.
  • the proxy connectivity graph is built based upon the hooks and cues that are (in comparison to models) inexpensive to load and keep resident in memory for purposes of constructing the proxy connectivity graph.
  • the proxy connectivity graph itself is lightweight compared to loading all the models and thus can be easily loaded and kept resident in computer memory for further processing.
  • the proxy connectivity graph also stores information about the mapping of dataflow connections to corresponding authored elements in the cue.
  • a user e.g., an animator
  • the user can perform operations such as establishing and breaking time-varying relationships between models by making changes to the proxy connectivity graph without needing to load all models simultaneously.
  • the user can automatically propagate changes to the proxy connectivity graph back into the actual scene graph or scene information itself.
  • Fig. 5 is a simplified high-level flowchart 500 depicting a method of constructing a proxy connectivity graph according to an embodiment of the present invention.
  • the method depicted in Fig. 5 may be performed by software modules executed by a processor, hardware modules, or combinations thereof.
  • Flowchart 500 depicted in Fig. 5 is merely illustrative of an embodiment of the present invention and is not intended to limit the scope of the present invention. Other variations, modifications, and alternatives are also within the scope of the present invention.
  • the method depicted in Fig. 5 may be adapted to work with different implementation constraints.
  • processing is initiated upon receiving information identifying a time interval (step 502).
  • the time interval may be characterized by a start time (Ts) and an end time (Te).
  • Ts start time
  • Te end time
  • the start time (Ts) corresponds to the start time of a scene
  • the end time (Te) corresponds to the end time of the scene.
  • the time interval may also correspond to a subset of the scene.
  • the hooks information (i.e., information stored in the hook files associated with the model) for the models included in the scene and the cues information for the scene is then accessed and loaded into memory (step 504).
  • the hook information for a model stores the static intra-model dependencies for the model.
  • the cues information comprises information describing the time- varying inter and intra-model dataflow connections among the models for the scene.
  • the cue information stores time varying specification for inputs of models that is used to pose the models; these specifications determine the time-varying (i.e., dynamic) dependencies between inputs and outputs of models.
  • Any arbitrary type of dataflow connection or dependency may be defined including two-way dataflow connections between models, transfer of data from a model to itself, transfer of data from a model to another model, and the like.
  • Both the hooks and the cues are lightweight and inexpensive to load and keep resident in memory of a computer, as compared to loading the models themselves (i.e., loading the model information for all the models).
  • a proxy connectivity graph is constructed based upon the hooks information accessed and the cues information accessed and loaded in step 504 (step 506).
  • the nodes of the proxy cormectivity graph represent the inputs and outputs of the models included in the scene and the links between the nodes represent dataflow connections or dependencies between the inputs and the outputs for the time interval.
  • the proxy connectivity graph is built and kept resident in computer memory for further use.
  • FIG. 6 depicts a schematic view of a proxy connection graph according to an embodiment of the present invention for a scene in which a human with a cell-phone clipped to his belt follows the progress of the moon with his gaze, while leaning with his right hand on a rail and holding a cup of coffee in his left hand.
  • the scene includes several models including a Human 602, a Phone 604, a Rail 606, a Cup 608, a Targeter 610, and a Moon 612.
  • Each model has one or more inputs and/or outputs.
  • inputs have labels ending in "In” and are depicted using diamonds while outputs have labels ending in "Out” and are depicted using circles.
  • the input and output nodes are also labeled using three letter labels (e.g., HWO, PCI).
  • the first letter of the label identifies the model to which the input/output belongs, for example, "H” for Human, “P” for Phone, “M” for Moon, “C” for Cup, “T” for Targeter, and “R” for Rail.
  • the scene results in a number of intra and inter-model dependencies.
  • the arrows between the inputs and outputs depict the dependencies for the scene (which is opposite to the direction of dataflow).
  • the arrows point in the direction of the dependency. Accordingly, in Fig. 6, a first node depends on a second node if an arrow originates (i.e., tail of the arrow) from the first node and points to the second node (i.e., head of the arrow points to the second node).
  • static intra-model dependencies are depicted using dotted arrow lines while inter-model dependencies are depicted using solid arrow lines.
  • the coffee cup is constrained to the human's left hand because anywhere the human moves the hand, the cup must follow, and therefore the cup effectively takes its position from the hand. Accordingly, as depicted in Fig. 6, the handleln input of the Cup depends upon the lHandOut output of the Human model.
  • the nodes representing the inputs and outputs along with the arrows represent the proxy connectivity graph for the scene.
  • Targeter model 610 does not represent a physical object that will appear in the rendered scene, but rather a separate unit of computation not built into any model and therefore usable by any model.
  • Targeter model 610 encapsulates the computation that will orient an object to point at a second target object, given the first object's own pivot (center of rotation). This is a common computation in computer graphics, and is frequently embedded directly in models that require the computation. It is a simple example of a pattern that may be commonly used for other, much more complicated computations.
  • a proxy connectivity graph for a scene may be used for several different applications.
  • the proxy graph may be used to enable a user (e.g., an animator) to specify animation for a large complex scene such that only those models that are needed for the animation are loaded in computer memory—all the models involved in the scene do not have to be loaded.
  • the proxy connectivity graph for a scene is used to determine the models that are required, either directly or indirectly, for the animation. For example, for any given model in a scene, the proxy connectivity graph for the scene can be walked or traversed to determine which other models would need to be loaded in order for the given model to be able to evaluate itself correctly.
  • the proxy graph is traversed to determine a transitive closure set (or recursive closure set) comprising one or more models from the scene, including the given model, that are needed for the given model to evaluate correctly.
  • the ammator need only identify the models from a scene in which the animator is interested, and an embodiment of the present invention automatically constructs the proxy connectivity graph (if it is not already constructed and resident in memory) for the scene based on the cues for the scene and based upon hooks of the models included in the scene, traverses the proxy graph to determine a minimal set (transitive or recursive closure set) of models that are needed to be concurrently loaded in memory in order for the user-identified models to evaluate correctly, and loads the determined minimal set of models and the user-identified models into the memory of the computer used by the user. All the models do not have to be loaded. Accordingly, the proxy connectivity graph for a scene provides the ability to automatically and dynamically manage the number of models that need to be loaded into a computer memory for processing of the scene.
  • Fig. 7 A is a simplified high-level flowchart 700 depicting a method of loading models for animation according to an embodiment of the present invention.
  • the method depicted in Fig. 7A may be performed by software modules executed by a processor, hardware modules, or combinations thereof.
  • Flowchart 700 depicted in Fig. 7A is merely illustrative of an embodiment of the present invention and is not intended to limit the scope of the present invention. Other variations, modifications, and alternatives are also within the scope of the present invention.
  • the method depicted in Fig. 7 A may be adapted to work with different implementation constraints.
  • information may be received from an animator identifying a particular model (or multiple models) that the animator is interested in animating for a scene (step 702).
  • the proxy connectivity graph for the scene that is resident in computer memory is traversed to determine a minimal set of models including models that are needed to be loaded in order for the particular model specified by the animator to evaluate correctly (step 704).
  • the minimal set of models represents the transitive closure (or recursive closure) set of models with respect to dependencies of the particular model specified by the animator that are needed for the user- specified model to evaluate correctly.
  • the minimal set of models may include a first set of models on which the particular animator-specified model depends, a second set of models on which the first set of models depends on, and so on recursively.
  • each input of the model to be loaded is considered in turn.
  • a node in the proxy graph representing the input is determined.
  • the proxy graph is traversed or walked in the direction of the dependencies to identify nodes on which the input node being examined depends upon, either directly or indirectly (e.g., if a directed arrow in the proxy graph from a first node to a second node indicates that the first node depends on or uses a value of the second node, then the graph is walked in the direction of the directed arrows).
  • a transitive closure set of all inputs and outputs on which the input of the particular model being considered depends upon is determined.
  • a record is kept of which models' nodes are encountered during the walk.
  • the union of the models recorded for each "walk" for each input of the particular node represents the minimal set of models to be loaded in computer memory simultaneously for the particular model to evaluate correctly. Any model whose input or output is encountered during the traversals is included in the minimal set of models.
  • the set of models determined in step 704 and the particular model specified by the user are then loaded in the computer memory of the animator's computer to enable accurate animation of the particular model specified by the animator in step 702 (step 706).
  • the animator may then animate the particular model.
  • an animator can perform animation for a large scene comprising several models without having to load all the models for the scene concurrently into the computer memory.
  • Embodiments of the present invention thus enable a user to animate models from a large complex scene even if the animator's computer's memory is not large enough to load all the models for the scene. By loading only the models that are required to properly animate a particular model, the proper animation of the particular model is assured without having to load all the models in the scene.
  • the animator wishes to animate the Human model in the graph depicted in Fig. 6 using animation software.
  • the animator selects the Human for loading, and a system configured according to the teachings of the present invention determines what other models must also be loaded in order for the Human to move correctly while the animator animates it.
  • the proxy connectivity graph is traversed to determine the dependencies.
  • each node representing an input of the Human model is examined in turn, and the proxy graph is walked from each node, recording which other models' nodes are encountered.
  • the models that will be encountered by walking the proxy graph depicted in Fig. 6 are Targeter, Rail, and Moon.
  • the system therefore loads the Human, Rail, Targeter, and Moon models.
  • the Phone and Cup models are not loaded as the Human model does not depend on them, but rather the opposite. If the animator had selected the Cup model for animation instead, then Cup, Human, Rail, Target, and Moon models would be loaded.
  • the user may also specify a particular model to be unloaded from the computer memory. Since other models may depend on the model that is to be unloaded, the other models should also be unloaded to prevent incorrect animation of those models.
  • the proxy connectivity graph may be used to determine which other models must be unloaded.
  • Fig. 7B is a simplified high-level flowchart 720 depicting a method of unloading models from computer memory according to an embodiment of the present invention.
  • the method depicted in Fig. 7B may be performed by software modules executed by a processor, hardware modules, or combinations thereof.
  • Flowchart 720 depicted in Fig. 7B is merely illustrative of an embodiment of the present invention and is not intended to limit the scope of the present invention. Other variations, modifications, and alternatives are also within the scope of the present invention.
  • the method depicted in Fig. 7B may be adapted to work with different implementation constraints.
  • information may be received from a user (e.g., an animator) identifying a model to be unloaded from the memory of a computer (step 722).
  • the proxy connectivity graph is traversed to identify a transitive closure set of all models that depend, either directly or indirectly, on the model to be unloaded (step 724).
  • a node from the proxy graph is determined for each output of the model to be unloaded. Each node representing an output of the particular model to be unloaded is examined in turn.
  • the proxy graph is traversed or walked in the opposite direction of the dependencies (i.e., if a directed arrow in the proxy graph from a first node to a second node indicates that the first node depends on or uses the value of the second node, then the graph is walked in the direction from a node pointed to by an arrow to the node connected to the source of the arrow) to identify nodes that depend, either directly or indirectly, on the node representing the output of the model being examined. Accordingly, the directed links between the nodes are used to walk the graph.
  • a transitive closure set of all inputs and outputs that depend on the output of the model to be unloaded is determined.
  • a record is kept of which models' nodes are encountered during the "reverse" walk (i.e., models whose inputs or outputs are included in the transitive closure set).
  • the union of the models recorded for each reverse walk for each output of the model to be unloaded represents the minimal set of models to be unloaded from the computer memory to prevent faulty animation. Any model whose input or output is encountered during the traversals is included in the minimal set of models.
  • a set of models that are presently loaded in the computer memory are determined (step 726).
  • the models determined in 726 and the user- specified model to be unloaded are then unloaded from the computer memory (step 728).
  • embodiments of the present invention prevent "incorrect" animation for a particular model that may result if a model on which the particular model depends is not loaded and available for processing.
  • Fig. 8 depicts modules that may be used to construct and manipulate a proxy connectivity graph according to an embodiment of the present invention.
  • the modules depicted in Fig. 8 may be implemented as software, in hardware, or combinations thereof. Other variations, modifications, and alternatives are also within the scope of the present invention.
  • a proxy graph constructor and analyzer (PGCA) module 802 takes as input hooks 806 associated with models 804 for a scene and cues information 808 for a scene and builds a proxy connectivity graph 810.
  • a model loader 812 may receive information 814 from a user (e.g., an animator) specifying one or more models that are of interest to the user. Model loader 812 is configured to "walk" or traverse proxy connectivity graph 810 to determine a minimal set of models 816 (transitive closure set) that is needed for the user-selected models to evaluate properly. Model loader 812 then loads the models in the minimal set 816 in memory 818 of computer 820 used by the user. Model loader 812 may also be configured to unload models from memory according to the flowchart depicted in Fig. 7B.
  • the user may also make changes 822 to the scene using constraints editor 824.
  • a user may make or break constraints between models using constraints editor 824, thereby changing the intra and/or inter model dependencies.
  • the changes are stored in cues information 808 for the scene.
  • the changes are also provided to PGCA 802 which is configured to modify proxy connectivity graph 810 to reflect the changes. In this manner, a user can make changes to the scene without having to load all the models for the scene concurrently in computer memory.
  • the proxy connectivity graph built according to the teachings of the present invention also facilitates rendering of large scenes. Many commercial Tenderers, including
  • RenderMan® from PixarTM are generally capable of rendering large scenes if one is able to provide them a fully tessellated (mathematical description of models composed of adjoining
  • 3D polygons description of the scene in a single and consistent coordinate system.
  • the proxy connectivity graph is used to facilitate the rendering process.
  • An optimizing graph linearizer uses the proxy graph to trade off model loads for smaller sets (or clusters) of models that must be simultaneously loaded. Since loading models is expensive (adds significantly to the rendering time), the linearizer performs optimization to minimize the number of times each model must be loaded in order to be tessellated without concurrently loading all of the models upon which it depends.
  • Fig. 9 is a simplified high-level flowchart 900 depicting processing performed to facilitate rendering of a scene according to an embodiment of the present invention.
  • the method depicted in Fig. 9 may be performed by software modules executed by a processor, hardware modules, or combinations thereof.
  • Flowchart 900 depicted in Fig. 9 is merely illustrative of an embodiment of the present invention and is not intended to limit the scope of the present invention. Other variations, modifications, and alternatives are also within the scope of the present invention.
  • the method depicted in Fig. 9 may be adapted to work with different implementation constraints.
  • the linearizer "unrolls" the proxy connectivity graph into an ordered linear list of nodes presenting inputs and outputs (step 902).
  • a node is a proxy for an input or output of a model; accordingly, an ordered list of inputs and outputs represented by the proxy graph is determined in 902 and used for subsequent processing.
  • the unrolling operation is performed such that the following condition (“the invariant condition") is always satisfied: in the ordered list of nodes (inputs and outputs), all nodes that a particular node depends upon appear in the ordered list before the particular node.
  • a particular node representing an input (also referred to as an input node) of a model depends on two nodes representing outputs (or output nodes) of another model (implying that the input depends on the two outputs)
  • the two output nodes are positioned before the particular input node in the ordered list of nodes. If the ordered list of nodes is considered to be ordered from left to right, then the invariant condition is satisfied if all nodes that a particular node depends upon appear in the ordered list to the left of the particular node.
  • the invariant condition guarantees that when the nodes are evaluated (as described below in step 910), all the data that is needed to evaluate a particular node is cached and available before the particular node is evaluated. This ensures proper evaluation of all the nodes in the proxy connectivity graph and the proper rendering of the scene without having to load all the models into computer memory simultaneously.
  • Clusters (or sets) of nodes belonging to the same model are then determined in the ordered list of nodes (step 903).
  • a cluster comprises one or more nodes of the same model that are contiguous in the ordered list of nodes.
  • the linearizer then iteratively reorders the nodes in the ordered list to minimize the number of "clusters" (or sets) of nodes that belong to the same model, while ensuring that the invariant condition is satisfied at every stage of the clustering (step 904).
  • Clustering is performed in step 904 to optimize the evaluation process by reducing the number of times that a model must be loaded in order to evaluate the nodes in the ordered list of nodes corresponding to the model.
  • step 904 the goal of the processing performed in step 904 is to cluster nodes of a model into a minimal number of clusters (optimally into one cluster if possible, which implies that the model corresponding to the nodes in the cluster need be loaded only once to evaluate all of the nodes of the model).
  • step 904 The processing in step 904 is repeated until no further reduction in the number of clusters is possible by reordering the nodes without violating the invariant condition. Accordingly, a check is made to determine if any further reordering can be performed (step 906). If no further reordering can be performed, it indicates that an optimal ordering of the nodes has been reached that minimizes the number of times each model must be loaded for the evaluation processing.
  • An ordered list of model references is then determined based upon the ordering of the clusters in the ordered list of nodes generated at the end of the reordering (step 908).
  • the models are then evaluated or posed based upon information in the cue (step 910).
  • Posing includes providing a set of values (which may be stored in the cue) to the inputs of a model that position and configure the geometric primitives of the model.
  • the time- varying specification of poses results in animation for a scene.
  • each model is loaded into a computer's memory according to the order specified by the ordered list of model references determined in step 908.
  • the loaded model is then used to evaluate the nodes (inputs and/or outputs) in the cluster corresponding to the model.
  • the results of each evaluation are cached or stored.
  • Caching the results for each cluster guarantees that information needed for evaluating a particular node (input or output) of a model is available prior to the evaluation of the node.
  • Previously cached results may also be used for evaluating or posing of a model in 910.
  • the tessellator then produces tessellations for each model based upon the data cached in step 910 (step 912).
  • the tessellator may tessellate each model individually.
  • the caching of information performed in step 910 enables the models to be tessellated in any arbitrary order.
  • the tessellator sequentially loads each model individually and uses the information cached in 910 for the model and its dependencies to produce tessellations for the loaded model.
  • the tessellated data may then be rendered by a Tenderer (step 914).
  • a scene of arbitrary complexity can be rendered without needing to load all the models in the scene simultaneously in the memory of a computer.
  • the tessellator can also tessellate the models on a per-model basis without needing to load information for all the models—the cached data is used for the tessellation instead. Accordingly, a computer with a memory that is insufficient to load all the models of the scene may still be used to tessellate and render the scene.
  • the linearizer in general may be applied for multiple sub-intervals — whenever the dataflow relationships change sufficiently within the interval such that a single unrolling of the proxy graph is no longer sufficient to evaluate the entire interval.
  • Fig. 10 depicts modules that may be used to perform the processing depicted in
  • Fig. 9 according to an embodiment of the present invention.
  • the modules depicted in Fig. 10 may be implemented as software, in hardware, or combinations thereof. Other variations, modifications, and alternatives are also within the scope of the present invention.
  • a proxy graph constructor and analyzer (PGCA) module 1002 takes as input hooks 1006 associated with models 1004 for a scene and cues 1008 for the scene and builds a proxy connectivity graph 1010.
  • An optimizing graph linearizer 1012 traverses and unrolls proxy connectivity graph 1010 to generate a linearized ordered list of nodes.
  • Graph linearizer 1012 is configured to iteratively reorder the nodes in the ordered list with the goal of minimizing the number of clusters of nodes belonging to a model while satisfying the invariant condition. After no more re-orderings can be performed, linearizer 1012 may determine a list of ordered model references based upon the ordered list of clusters. The ordered list of model references along with intervals 1014 may then be forwarded to poser 1016.
  • Poser 1016 is configured to evaluate or pose the models based upon information received from linearizer 1012, cues information 1008, and model information 1004. As part of the posing, each model is loaded into a computer's memory according to the order specified by the ordered list of model references. The loaded model is then used to evaluate the nodes in a cluster corresponding to the model. The results of each evaluation are cached. The models are loaded and unloaded one by one per the ordering in the model list of references until all the models have been evaluated.
  • the cached data is then used by tessellator 1018 to produce tessellated renderable data 1020.
  • Tessellator 1016 is configured to tessellate each model individually using the cached information.
  • the models can be tessellated in any order.
  • Renderable data 1020 is then communicated to a renderer 1022 (e.g., RenderMan® from Pixar) for rendering.
  • Embodiments of the present invention are able to linearize the scene graph in such a way that no more than a few models need ever be resident in the memory of the rendering system simultaneously.
  • the tessellator can tessellate a model without needing to load all the other models concurrently in memory as the information needed for tessellating the model is cached and available to the tessellator.
  • This section uses an example to describe the process of unrolling a proxy graph to produce a linear ordered list of nodes and reordering of nodes in the ordered list to minimize the number of clusters of nodes representing inputs or outputs of the same model (referred to as nodes belonging to the same model) according to an embodiment of the present invention.
  • the example is not intended to limit the scope of the present invention as recited in the claims.
  • the proxy connectivity graph depicted in Fig. 6 is used to illustrate the example.
  • the proxy connectivity graph (depicted in Fig. 6) is unrolled to generate a linear ordered list of nodes.
  • the unrolling is performed such that the invariant condition (that all nodes that a particular node depends upon appear in the ordered list before the particular node) is satisfied.
  • all proxy nodes of the proxy connectivity graph are iterated through placing the nodes at the end of the (initially empty) linearized list after all nodes upon which they depend have already been added to the list. With proper marking of nodes, this can be performed efficiently in linear time with a simple recursive function.
  • Fig. 11 A One typical unrolling of the proxy graph depicted in Fig. 6 is depicted in Fig. 11 A, in which arrows indicate dependency.
  • the linear ordered list depicted in Fig. 11 A comprises thirteen nodes corresponding to input and output nodes in the proxy connectivity graph depicted in Fig. 6.
  • the nodes are ordered left to right.
  • the arrows indicate the dependencies of the nodes.
  • the nodes in the ordered list depicted in Fig. 11A are clustered into ten clusters comprising nodes of the same model. Each cluster (including the trivial cluster consisting of only one node) will require a model load and unload during the subsequent evaluation stage. Accordingly, if the ordered list depicted in Fig.
  • the Rail model would need to be loaded and unloaded once (to evaluate nodes in cluster #1)
  • the Human model would need to be loaded and unloaded four times (to evaluate nodes in clusters #2, #5, #7 and #9)
  • the Moon model would need to be loaded and unloaded once (to evaluate nodes in cluster #3)
  • the Targeter model would need to be loaded and unloaded twice (to evaluate nodes in clusters #4 and #6)
  • Cup would need to be loaded and unloaded once (to evaluate nodes in cluster #8)
  • the Phone would need to be loaded and unloaded once (to evaluate nodes in cluster #10).
  • embodiments of the present invention attempt to reorder the nodes in the rolled out linear list of ordered nodes to minimize the number of clusters of nodes belonging to the same model, while satisfying the invariant condition.
  • each model should be loaded and unloaded only once, i.e., the ordered list should comprise only a single cluster for a model; however, this may not be possible due to the nature of inter-model dependencies present in the scene.
  • the goal of the reordering is to have as few clusters of "same-model-nodes" (i.e. nodes belonging to the same model, indicated by the first letter of node name in our Fig. 11 A) in the reordering process as possible.
  • the optimization process is described below.
  • the reordering is initiated by moving each node to the left in order to:
  • RULE #2 If no such merge is possible, move the node as far left as it can legally move, so that other nodes that may depend on the node itself are freer to merge with other clusters.
  • a move is legal for a particular node as long as the move does not result in the particular node being moved past (to the left of) a node on which the particular node depends (denoted by arrows in the Figs.). Accordingly, a move is illegal if it results in a particular node being moved past (to the left of) a node upon which it depends, as that would violate the invariant condition and thus invalidate the subsequent caching process.
  • the clustering process starts at the beginning of the current linearization, considering each node in turn, and reordering the linearization in place. We will now follow this process through once, showing interesting intermediate orderings of the linear list. As previously stated, the arrows in the Figs, represent the dependencies depicted in the proxy graph depicted in Fig. 6.
  • HWI can merge with its left neighbor HRI.
  • the node HNO can also merge with its left neighbor HWI. Accordingly, nodes HRI, HWI, and HNO of the human model are clustered to form a single cluster #4. This reduces the total number of clusters from ten in Fig. 11 A to nine in Fig. 1 IB.
  • Node TOO can be merged with TPI using Rule #1, without actually moving it.
  • Node HHI cannot be moved or merged because it depends on the node directly to its left (node TOO).
  • Node HLO can be moved to the left by applying Rule #2 until it can merge with a cluster of nodes of the Human model (i.e., cluster #4 depicted in Fig. 1 IB) to form a larger cluster of nodes.
  • Node CHI can also be moved to the left by applying Rule #2.
  • Rule # 1 can be applied to node HWO to move it left until is merges with cluster #4 depicted in Fig. 1 lC.
  • Rule #2 can be applied to node PCI, moving it as left as possible, creating a new linearization as depicted in Fig. 1 ID. Comparing the linear ordered list depicted in Fig. 1 ID to the linear ordered list depicted in Fig. 11 A, the number of times that the Human model has to be loaded and unloaded has been reduced from four to two, which is the minimum achievable, given the dependencies of the scene. The Targeter model still has to be loaded twice, and repeating the clustering will not improve the ordering further. Next, a "cluster nodes rightwards" technique is applied as described below.
  • Rule #4 If no such merge is possible, move the node as far right as it can legally move, so that other nodes that may depend on the node itself are freer to merge with other clusters.
  • Fig. 1 IE the large cluster #4 of "H" nodes cannot move because TPI, just to its right, depends on one of its nodes, which means that moving past it would violate the invariant condition.
  • Rule #3 can be applied to cluster #2 (TTI) depicted in Fig. 1 IE, merging it with cluster #5 (TPI, TOO).
  • Rule #4 can be applied to cluster #1 (MMO) depicted in Fig. 1 IE, and it can be moved as far right as it can go, resulting in a final ordering as depicted in Fig. 1 IF.
  • the rightwards-clustering has resulted in merging one more cluster.
  • the linearization improves when, as a result of applying rules in steps 2 and 3, clusters are merged together. Therefore, since no action will be taken to split clusters, the termination criterion for the optimization is when both steps 2 and step 3 fail to merge any more clusters. It can be verified that a further application of the two steps to the current linearization depicted in Fig. 1 IF will only be able to apply steps 2 and 4, which do not affect the number of clusters. Thus, it can be verified that the linear ordered list depicted in Fig. 1 IF represents the optimized list.
  • the model list of references for the linear list in Fig. 1 IF is: Rail (to evaluate cluster #1), Human (to evaluate cluster #2), Moon (to evaluate cluster #3), Targeter (to evaluate cluster #4), Human (to evaluate cluster #5), Cup (to evaluate cluster #6), and Phone (to evaluate cluster #7). Accordingly, the Human model must be loaded twice and the other models must be loaded only once during the evaluation of the nodes (inputs and outputs) of the models.
  • steps 2, 3 and 4 may be needed in other embodiments analyzing more complicated (realistic) scenes in the production environment before merging is completed (i.e., before an optimized ordered list is arrived at).
  • N the number of nodes (or proxies) in the proxy connectivity graph
  • F the maximum number of direct dependencies any particular node or proxy has. Since F is generally a small constant and does not scale with the complexity of the scene, the algorithms therefore scale roughly linearly with scene complexity, which is the best complexity achievable by any Tenderer. Accordingly, the optimizer does not itself impact overall rendering performance.
  • Hierarchical Clustering N*F time
  • the only clustering metric that is used is the model to which a node belongs.
  • Embodiments of the present invention also support the mechanism of hierarchically grouping models (one model becomes a child of another model), both to aid in organization of complex scenes, and to facilitate sharing
  • cluster(O) is the zero'th predicate, corresponding to the model to which the proxies belong, and cluster(i>0) corresponds to the i'th ancestor of the model.
  • the linear list optimization algorithm described above may be extended to take advantage of coherence in multi- frame-rendering.
  • a typical animation consisting of dozens to hundreds of frames (e.g., 24 rendered frames per second of animation)
  • Inter-model dependencies due to dataflow connections are frequently coherent over a significant frame range, and by computing a single optimized linearization that can be used by the tessellator over multiple sequential frames, the number of times that each model must to be loaded can be reduced. In most instances, this speeds up the tessellation of "n" frames simultaneously by nearly a factor of "n".
  • the algorithm may be configured to enable it to consider proxy graphs that do not represent a single instant in time, but rather all the dependencies active over an interval of time.
  • Proxy graphs may further be characterized as a consistent proxy graph, one that can be linearized into an ordering that obeys the invariant condition (and thus can be used to accurately evaluate and cache the node proxies), and an inconsistent proxy graph, one that cannot be linearized into an ordering that obeys the invariant condition because it contains a cycle. Cycles are easy to detect in the proxy graph (or any graph), and thus enable embodiments of the present invention an efficient means of determining whether a given proxy graph is consistent.
  • Each interval corresponds to a consistent proxy graph defined over the interval, which means a single optimized linearization of the graph can be obtained to use across all frames in the interval.
  • the optimizer is executed once for the proxy graph of each interval, and the caching phase can evaluate and cache each model over the entire interval without reloading.

Landscapes

  • Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Graphics (AREA)
  • Geometry (AREA)
  • Software Systems (AREA)
  • Processing Or Creating Images (AREA)

Abstract

L'invention concerne des procédés permettant de traiter des scènes de complexité arbitraire comprenant plusieurs objets représentés par des modèles. Ces procédés permettent de construire une représentation en mémoire contenant des données ou représentant des dépendances mémoire inter-modèles et intra-modèles entre les diverses entrées et sorties des modèles compris dans une scène. Le représentation en mémoire qui construite à partir des données (804) de dépendances intra-modèle, et de données (808) de repères associées à la scène. Dans une forme de réalisation, la représentation en mémoire est constituée d'un graphe (802) comprenant un certain nombre de noeuds, et des liens orientés reliant les noeuds. Les noeuds du graphe représentent (sont des témoins (proxys) pour) les sorties et les entrées des modèles intervenant dans la scène. Les liens orientés reliant les noeuds représentent les dépendances intra et inter-modèles entre les entrées et les sorties.
PCT/US2004/014604 2004-05-10 2004-05-10 Procedes de traitement de scenes complexes WO2005114586A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2004/014604 WO2005114586A1 (fr) 2004-05-10 2004-05-10 Procedes de traitement de scenes complexes

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2004/014604 WO2005114586A1 (fr) 2004-05-10 2004-05-10 Procedes de traitement de scenes complexes

Publications (1)

Publication Number Publication Date
WO2005114586A1 true WO2005114586A1 (fr) 2005-12-01

Family

ID=35428573

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2004/014604 WO2005114586A1 (fr) 2004-05-10 2004-05-10 Procedes de traitement de scenes complexes

Country Status (1)

Country Link
WO (1) WO2005114586A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9135739B2 (en) 2011-09-06 2015-09-15 Dreamworks Animation Llc Optimizing graph evaluation

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5394168A (en) * 1993-01-06 1995-02-28 Smith Engineering Dual-mode hand-held game controller
US20030227453A1 (en) * 2002-04-09 2003-12-11 Klaus-Peter Beier Method, system and computer program product for automatically creating an animated 3-D scenario from human position and path data

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5394168A (en) * 1993-01-06 1995-02-28 Smith Engineering Dual-mode hand-held game controller
US20030227453A1 (en) * 2002-04-09 2003-12-11 Klaus-Peter Beier Method, system and computer program product for automatically creating an animated 3-D scenario from human position and path data

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9135739B2 (en) 2011-09-06 2015-09-15 Dreamworks Animation Llc Optimizing graph evaluation

Similar Documents

Publication Publication Date Title
US8059127B1 (en) Techniques for animating complex scenes
KR100938036B1 (ko) 그래픽 표시 애니메이션 시스템, 표시 요소 애니메이션화 방법, 애니메이션 동작 적용 방법, 및 컴퓨터 판독가능 매체
US7283134B2 (en) Regional progressive meshes
US8310484B2 (en) Efficient processing of operator graphs representing three-dimensional character animation
US7688323B2 (en) Function portions of animation program
US8253730B1 (en) System and method for construction of data structures for ray tracing using bounding hierarchies
US7330185B2 (en) Techniques for processing complex scenes
US7532212B2 (en) Techniques for rendering complex scenes
Cignoni et al. Selective refinement queries for volume visualization of unstructured tetrahedral meshes
EP2474930B1 (fr) Actualisation d'un objet modelé
Wald et al. Simd ray stream tracing-simd ray traversal with generalized ray packets and on-the-fly re-ordering
US7965294B1 (en) Key frame animation with path-based motion
WO2007090100A2 (fr) Ordonnancement à base de contrainte pour une cohérence temporelle d'animation à base de frappes
US20050248573A1 (en) Storing intra-model dependency information
US8436856B1 (en) Systems and methods for mixing the execution order of shading language code
EP1747537B1 (fr) Techniques pour animer des scenes complexes
WO2005114587A1 (fr) Procedes permettant le rendu de scenes complexes
WO2005114590A1 (fr) Stockage des donnees de dependances intra-modele
WO2005114586A1 (fr) Procedes de traitement de scenes complexes
NZ551283A (en) Techniques for animating complex scenes
Barnes Patchmatch: a fast randomized matching algorithm with application to image and video
Zanni et al. HCSG: Hashing for real-time CSG modeling
Chen et al. Generating high-quality discrete LOD meshes for 3D computer games in linear time
Argudo et al. Interactive inspection of complex multi-object industrial assemblies
Ramos et al. Characterization of multiresolution models for real-time rendering in GPU-limited environments

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase