ES2255167T3

A computer graphics system

Abstract

A computerized graphic system is described in which a new type of entity, referred to as "phenomenon", can be created, instantiated and used to form an image of a scene. A phenomenon is an encapsulated degrading DAG that comprises one or more nodes, each of which comprises an encapsulated degrader or set of DAGs that are interconnected so that they can cooperate, that are instantiated and attached to entities of the scene that they are created during the scene definition procedure to define various types of scene characteristics. The phenomena selected for use by an operator in reference to a scene may be predefined, or may be constructed from nodes of base degraders, by the operator using a phenomenon creator. The phenomenon editor allows the operator to see the effects produced by the different settings of the values of the selected parameters.

ES2255167T3, drawing sheet 1 — Sheet 1 of 8

Term

Term ended

Projected expiry passed 2 July 2018, 8.2 years ago.

32 claims: 32 independent, 0 dependent

1
ES 2 255 167 T3 REIVINDICACIONES 1. Un sistema de gráficos por ordenador para generar una imagen de una escena a partir de una representación de la escena a la cual está aplicado, al menos, un shader de gráfico acíclico dirigido (DAG) que comprende una pluralidad de nodos, incluyendo al menos un nodo raíz primario para aplicar el DAG de shaders a un elemento de la representación de la escena y al menos un nodo de shader conectado a él en el DAG, comprendiendo el sistema de gráficos por ordenador:A. un módulo preprocesador configurado para determinar si el al menos un nodo de shader es del tipo que se usa para ejecutar una operación de preprocesado en relación con dicha representación y, si es así, usar el al menos un nodo shader para ejecutar dicha operación de preprocesado para generar una representación preprocesada de la escena;y B. un módulo renderizador configurado para generar la imagen renderizada a partir de la representación de la escena o, si el sistema de gráficos por ordenador incluye el módulo preprocesador, la representación preprocesada de la escena.
2
Un sistema de gráficos por ordenador como el definido en la reivindicación 1 en el cual el al menos un nodo shader es de un tipo de nodo shader de geometría, estando configurado el módulo de preprocesado para ejecutar dicha operación de preprocesado usando el al menos un nodo shader del tipo de nodo de shader de geometría para definir la geometría para la escena.
3
Un sistema de gráficos por ordenador como el definido en la reivindicación 1 en el cual el al menos un nodo de shader es de un tipo de nodo de shader de fotones, estando configurado el módulo preprocesador para ejecutar la operación de preprocesado usando el al menos un nodo de shader del tipo de nodo de shader de fotones para controlar el recorrido de al menos un fotón de la escena o al menos una característica de interacción de al menos un fotón con una superficie de un objeto de la escena.
4
Un sistema de gráficos por ordenador como el definido en la reivindicación 1 en el cual el al menos un nodo de shader es de un tipo de nodo de shader de emisor de fotón, estando configurado el módulo preprocesador para ejecutar dicha operación de preprocesado usando el al menos un nodo de shader del tipo de nodo de shader de emisor de fotón para simular la generación de al menos un fotón por una fuente de luz que ilumina la escena.
5
Un sistema de gráficos por ordenador como el definido en la reivindicación 1 en el cual el al menos un nodo de shader es de un tipo de nodo de shader de volumen de fotón, estando configurado el módulo preprocesador para ejecutar dicha operación de preprocesado usando el al menos un nodo de shader del tipo de nodo de shader de volumen de fotón para simular la interacción de al menos un fotón de una fuente de luz con un volumen tridimensional del espacio de la escena.
6
Un sistema de gráficos por ordenador como el definido en la reivindicación 1, incluyendo, además, el sistema de gráficos por ordenador un módulo postprocesador configurado para determinar si el al menos un nodo de shader es de un tipo que se usa en ejecutar una operación de postprocesado en relación con dicha representación y, si es así, usar el al menos un nodo de shader para ejecutar dicha operación de postprocesado en relación con una imagen renderizada.
7
Un sistema de gráficos por ordenador como el definido en la reivindicación 6 en el que el nodo de shader es de un tipo de nodo de shader de salida de datos, estando configurado el módulo postprocesador para ejecutar dicha operación de postprocesado usando el al menos un nodo de shader del tipo de nodo de shader de salida de datos.
8
Un sistema de gráficos por ordenador como el definido en la reivindicación 6 en el que la imagen renderizada comprende una pluralidad de pixeles asociado cada uno de ellos con un valor de pixel, estando configurado el módulo postprocesador para ejecutar dicha operación de postprocesado en relación con dichos valores de pixel.
9
Un sistema de gráficos por ordenador como el definido en la reivindicación 6 en el que el módulo postprocesador está configurado para usar el al menos un nodo de shader del tipo de nodo de shader de salida de datos para ejecutar al menos una de entre una operación de composición, una operación de convolución compleja o una operación de dibujado de línea de contorno.
10
Un sistema de gráficos por ordenador como el definido en la reivindicación 1 que incluye, además, un segundo DAG de shader que comprende el nodo raíz primario y al menos un nodo de shader, en el cual el al menos un nodo shader de uno de dichos DAGs, cuando es usado por al menos uno de entre el módulo preprocesador o el módulo renderizador, proporciona al menos un valor que es usado en el preprocesado del al menos un nodo de shader del otro de dichos DAGs.
11
Un sistema de gráficos por ordenador como el definido en la reivindicación 1 en el que dicho DAG de shader tiene, además, al menos un nodo raíz opcional para aplicar el DAG de shader a un segundo elemento de la representación de escena, estando conectado, además, el al menos un nodo raíz opcional al al menos un nodo de shader del DAG.
12
Un método de gráficos por ordenador para generar una imagen de una escena a partir de una representación de la escena a la que está aplicado al menos un gráfico acíclico dirigido (DAG) de shader que comprende una pluralidad de nodos, incluyendo un nodo raíz primario para aplicar el DAG de shader a un elemento de la representación de escena y al menos un nodo de shader conectado a él en el DAG, método de gráficos por ordenador que incluye:A. un paso preprocesador para determinar si el al menos un nodo de shader es del tipo que se usa para ejecutar una operación de preprocesado en relación con dicha representación y, si es así, usar el al menos un nodo shader para ejecutar dicha operación de preprocesado para generar una representación preprocesada de la escena;y B. un paso renderizador para generar la imagen renderizada a partir de la representación de la escena o, si el método de gráficos por ordenador incluye el paso preprocesador, la representación preprocesada de la escena.
13
Un método de gráficos por ordenador como el definido en la reivindicación 12 en el cual el al menos un nodo shader es de un tipo de nodo shader de geometría, incluyendo el paso preprocesador el paso de ejecutar dicha operación de preprocesado usando el al menos un nodo shader del tipo de nodo de shader de geometría para definir la geometría para la escena. ES 2 255 167 T3
14
Un método de gráficos por ordenador como el definido en la reivindicación 12 en el cual el al menos un nodo de shader es de un tipo de nodo de shader de fotones, incluyendo el paso preprocesador el paso de ejecutar la operación de preprocesado usando el al menos un nodo de shader del tipo de nodo de shader de fotones para controlar el recorrido de al menos un fotón de la escena o al menos una característica de interacción de al menos un fotón con una superficie de un objeto de la escena.
15
Un método de gráficos por ordenador como el definido en la reivindicación 12 en el cual el al menos un nodo de shader es de un tipo de nodo de shader de emisor de fotón incluyendo el paso preprocesador el paso de ejecutar dicha operación de preprocesado usando el al menos un nodo de shader del tipo de nodo de shader de emisor de fotón para simular la generación de al menos un fotón por una fuente de luz que ilumina la escena.
16
Un método de gráficos por ordenador como el definido en la reivindicación 12 en el cual el al menos un nodo de shader es de un tipo de nodo de shader de volumen de fotón, incluyendo el paso preprocesador el paso de ejecutar dicha operación de preprocesado usando el al menos un nodo de shader del tipo de nodo de shader de volumen de fotón para simular la interacción de al menos un fotón de una fuente de luz con un volumen tridimensional del espacio de la escena.
17
Un método de gráficos por ordenador como el definido en la reivindicación 12, comprendiendo, además, el sistema de gráficos por ordenador un paso postprocesador para determinar si el al menos un nodo de shader es de un tipo que se usa en la ejecución de una operación de postprocesado en relación con una imagen renderizada y, si es así, usar el al menos un nodo de shader para ejecutar dicha operación de postprocesado usando el al menos un nodo de shader en relación con una imagen renderizada.
18
Un método de gráficos por ordenador como el definido en la reivindicación 17 en el que el al menos un nodo de shader es de un tipo de nodo de shader de salida de datos, incluyendo el paso postprocesador el paso de ejecutar dicha operación de postprocesado usando el al menos un nodo de shader del tipo de nodo de shader de salida de datos.
19
Un método de gráficos por ordenador como el definido en la reivindicación 17 en el que la imagen renderizada comprende una pluralidad de pixeles asociado cada uno de ellos con un valor de pixel, incluyendo el paso postprocesador el paso de ejecutar dicha operación de postprocesado en relación con dichos valores de pixel.
20
Un método de gráficos por ordenador como el definido en la reivindicación 17 en el que el paso postprocesador incluye el paso de usar el al menos un nodo de shader del tipo de nodo de shader de salida de datos para ejecutar al menos una de entre una operación de composición, una operación de convolución compleja o una operación de dibujado de línea de contorno.
21
Un método de gráficos por ordenador como el definido en la reivindicación 12 en el que el al menos un DAG de shader comprende una pluralidad de DAGs, incluyendo cada uno de dicha pluralidad de DAGs al menos un nodo de shader, en el cual el al menos un nodo shader de uno de dichos DAGs, cuando es usado por al menos uno de entre el paso preprocesador o el paso renderizador, proporciona al menos un valor que es usado en el preprocesado del al menos un nodo de shader del otro de dichos DAGs.
22
Un producto de programa para ordenador para su uso en relación con un ordenador para proporcionar un sistema de gráficos por ordenador para generar una imagen de una escena a partir de una representación de la escena a la cual está aplicado, al menos, un gráfico acíclico dirigido (DAG) de shader que comprende una pluralidad de nodos, incluyendo al menos un nodo raíz primario para aplicar el DAG de shaders a un elemento de la representación de la escena y al menos un nodo de shader conectado a él en el DAG, comprendiendo el producto de programa de ordenador un medio legible por un ordenador en el que han sido codificados:A. un módulo preprocesador configurado para permitir al ordenador determinar si el al menos un nodo de shader es del tipo que se usa para ejecutar una operación de preprocesado en relación con dicha representación y, si es así, usar el al menos un nodo shader para ejecutar dicha operación de preprocesado para generar una representación preprocesada de la escena;y B. un módulo renderizador configurado para permitir al ordenador generar la imagen renderizada a partir de la representación de la escena o, si el producto de programa de ordenador incluye el módulo preprocesador, la representación preprocesada de la escena.
23
Un producto de programa para ordenador como el definido en la reivindicación 22 en el cual el al menos un nodo shader es de un tipo de nodo shader de geometría, estando configurado el módulo de preprocesado para permitir al ordenador ejecutar dicha operación de preprocesado usando el al menos un nodo shader del tipo de nodo de shader de geometría para definir la geometría para la escena.
24
Un producto de programa para ordenador como el definido en la reivindicación 22 en el cual el al menos un nodo de shader es de un tipo de nodo de shader de fotones, estando configurado el módulo preprocesador para permitir al ordenador ejecutar la operación de preprocesado usando el al menos un nodo de shader del tipo de nodo de shader de fotones para controlar el recorrido de al menos un fotón de la escena o al menos una característica de interacción de al menos un fotón con una superficie de un objeto de la escena.
25
Un producto de programa para ordenador como el definido en la reivindicación 22 en el cual el al menos un nodo de shader es de un tipo de nodo de shader de emisor de fotón, estando configurado el módulo preprocesador para permitir al ordenador ejecutar dicha operación de preprocesado usando el al menos un nodo de shader del tipo de nodo de shader de emisor de fotón para simular la generación de al menos un fotón por una fuente de luz que ilumina la escena.
26
Un producto de programa para ordenador como el definido en la reivindicación 22 en el cual el al menos un nodo de shader es de un tipo de nodo de shader de volumen de fotón, estando configurado el módulo preprocesador para permitir al ordenador ejecutar dicha operación de preprocesado usando el al menos un nodo de shader del tipo de nodo de shader de volumen de fotón para simular la interacción de al ES 2 255 167 T3 menos un fotón de una fuente de luz con un volumen tridimensional del espacio de la escena.
27
Un producto de programa para ordenador como el definido en la reivindicación 22 en el que el medio legible por ordenador tiene, además, codificado en él un módulo postprocesador configurado para permitir al ordenador determinar si el al menos un nodo de shader es de un tipo que se usa en ejecutar una operación de postprocesado en relación con dicha representación y, si es así, usar el al menos un nodo de shader para ejecutar dicha operación de postprocesado en relación con una imagen renderizada.
28
Un producto de programa para ordenador como el definido en la reivindicación 27 en el que el nodo de shader es de un tipo de nodo de shader de salida de datos, estando configurado el módulo postprocesador para permitir al ordenador ejecutar dicha operación de postprocesado usando el al menos un nodo de shader del tipo de nodo de shader de salida de datos.
29
Un producto de programa para ordenador como el definido en la reivindicación 28 en el que la imagen renderizada comprende una pluralidad de pixeles asociado cada uno de ellos con un valor de pixel, estando configurado el módulo postprocesador para permitir al ordenador ejecutar dicha operación de postprocesado en relación con dichos valores de pixel.
30
Un producto de programa para ordenador como el definido en la reivindicación 27 en el que el módulo postprocesador está configurado para permitir al ordenador usar el al menos un nodo de shader del tipo de nodo de shader de salida de datos para ejecutar al menos una de entre una operación de composición, una operación de convolución compleja o una operación de dibujado de línea de contorno.
31
Un producto de programa para ordenador como el definido en la reivindicación 22 que incluye, además, un segundo DAG de shader que comprende el nodo raíz primario y al menos un nodo de shader, en el cual el al menos un nodo shader de uno de dichos DAGs, cuando es usado por al menos uno de entre el módulo preprocesador o el módulo renderizador, proporciona al menos un valor que es usado en el preprocesado del al menos un nodo de shader del otro de dichos DAGs.
32
Un producto de programa para ordenador como el definido en la reivindicación 22 en el que dicho DAG de shader tiene, además, al menos un nodo raíz opcional para aplicar el DAG de shader a un segundo elemento de la representación de escena, estando conectado, además, el al menos un nodo raíz opcional al al menos un nodo de shader del DAG.

Independent claims32

105 paragraphs in 2 sections, as filed

IS 2 255 167 T3

DESCRIPTION

Computer graphics system.

Field of the invention

The invention relates generally to the field of computer graphics, computer-aided design and the like, and more particularly to systems and methods for generating shader systems and using the shader systems thus generated to render an image or a scene. The invention, in particular, provides a new type of component useful in a computer graphics system, hereinafter identified as a "phenomenon", which comprises a system that includes a DAG ("directed acyclic graphic") of packed shaders and encapsulation or set of cooperating shader DAGs, each of which may include one or more shaders, and which is generated and encapsulated to help define at least a portion of the scene, in a way that will ensure that the shaders can cooperate properly during rendering.

Background of the invention

In computer graphics, computer-aided geometric design, and the like, an artist, draftsman, or the like (generally referred to hereinafter as an "operator") tries to generate a three-dimensional representation of objects in a scene, such as the maintained by a computer, and later render the corresponding two-dimensional images of the objects in the scene from one or more orientations. At the beginning, the representation generation phase, conventionally, computer graphics systems generate a three-dimensional representation from, for example, several two-dimensional line drawings that comprise the contours and / or cross sections of the objects in the scene and, applying various operations to such lines that will result in two-dimensional surfaces in three-dimensional space and subsequent modification of the parameters and control points of such surfaces to correct or otherwise modify the shape of the resulting representation of the object. During this process, the operator also defines different properties of the surfaces of the objects, the structure and characteristics of the light sources that illuminate the scene, and the structure and characteristics of one or more simulated cameras that generate the images. After the structure and characteristics of the scene, light source (s) and camera (s) have been defined, in a second phase, an operator enables the computer to render an image of the scene from a specific viewing direction. .

The objects of the scene, light source (s) and camera (s) are defined, in the first stage of definition of the scene, by means of the corresponding multidimensional mathematical representations that include, at least, the three spatial dimensions and, possibly, a dimension of time. The mathematical representations are typically stored in a tree-like data structure. The properties of the object's surfaces, in turn, are defined by “shader trees”, each of which includes one or more shaders which, during the second stage rendering phase, enable the computer to render. the corresponding surfaces, essentially providing color values representative of the colors of the respective surfaces. The shaders of a shader tree are generated by an operator or are provided a priori by a computer graphics system, in a high-level language such as C or C ++, and together they enable the computer to render an image of a corresponding surface. in the second stage rendering of the scene.

Shader trees were presented by R.

Cook in the article "Tree of Shaders", ACM Computer Graphics, vol. 18, no. 3, July 1984, and redefined in the RenderMan shading language, presented in "A Language for Shading and Lighting Calculations" by P. Hanrahan et al., ACM Computer Graphics, vol. 24, no. 4, April 1991. Another language and shading system is described by B. Corrie and others in Computer Science Technical Report TR-CS-9302 from the Computer Sciences Laboratory of The Australian National University, entitled “Data Shader Language and Interface Specification”, June 1993.

Various problems arise from the generation and use of shaders and shader trees as currently provided in computer graphics tools. First, shaders generally cannot cooperate with each other unless they are programmed to do so. Typically, the input values are constant values, which limits the flexibility of shaders and the ability to render features in an interesting and vivid way. Furthermore, it is generally difficult to establish cooperative shader systems that can obtain their input values from a common source.

The present invention is as claimed in the claims.

The invention provides a new and improved computer graphics system and method that provides increased cooperation between shaders by facilitating the generation of packaged and encapsulated shader DAGs, each of which may include one or more shaders, generated in a way that ensures that the shaders of the shader DAGs can cooperate correctly during rendering.

In brief summary, a computer graphics system is provided in which a new type of entity, referred to as a "phenomenon", can be created, instantiated, and used to render an image of a scene. A phenomenon is an encapsulated shader DAG that comprises one or more nodes that, in turn, each comprise a shader, or an encapsulated set of such DAGs that are interconnected in a cooperative way, which are instantiated and assigned to scene entities that are created during the scene definition process to define various types of scene characteristics, including color characteristics and surface textures of objects in the scene, characteristics of volumes and geometry of the scene, characteristics of light sources that illuminate the scene, characteristics of simulated cameras that will be simulated during rendering, and numerous other characteristics that are useful when rendering.

The phenomena selected for use by an operator in relation to a scene can be predefined or can be constructed from base shader nodes by an operator using a phenomenon creator. The phenomena creator ensures that the phenomena are constructed in such a way that the DAG shaders or cooperating DAGs can cooperate.

ES 2 255 167 T3 correctly while rendering a scene image.

Before being applied to a scene, a phenomenon is instantiated by providing values, or functions that are used to define the values, for each of the phenomenon's parameters using a phenomenon editor.

After a representation of a scene has been defined and the phenomena applied, a scene imager can generate an image of the scene. In that operation, the scene image generator operates in a series of phases including a pre-processing phase, a rendering phase, and an optional post-processing phase. During the pre-processing phase, the scene image generator can perform pre-processing operations such as photon and shadow mapping, multiple inheritance resolution, and the like. The scene image generator can perform preprocessing operations if, for example, a phenomenon applied to the scene includes a geometry shader to generate the geometry defined by it for the scene. During the render phase, the scene image generator renders the image. During the post-processing phase, the scene image generator can perform post-processing operations if, for example, a phenomenon applied to the scene includes a shader that defines post-processing operations, such as depth-of-field or blur calculations. motion that are dependent on the speed and depth information stored in relation to each pixel value of the rendered image.

Brief description of the drawings

This invention is set forth in detail in the appended claims. The foregoing and further advantages of this invention may be better understood by referring to the following description taken in conjunction with the accompanying drawings, in which:

Figure 1 depicts a computer graphics system that provides increased cooperation between shaders by facilitating the generation of packaged and encapsulated shader DAGs, each of which may include one or more shaders, of which shader DAGs are generated in a single way which ensure that the shaders of the shader DAG can cooperate correctly during rendering, built according to the invention;

Figure 2 is a functional block diagram of the computer graphics system depicted in Figure 1;

Figure 3 depicts a graphical user interface for an embodiment of the phenomenon creator used in the computer graphics system whose functional block diagram is depicted in Figure 2;

Figure 4 graphically depicts an illustrative phenomenon generated using the phenomenon creator depicted in Figures 2 and 3;

Figure 5 depicts a graphical user interface for an embodiment of the phenomenon editor used in the computer graphics system whose functional block diagram is depicted in Figure 2;

Figures 6A and 6B represent details of the graphical user interface shown in Figure 5; <sup>Y</sup> Figure 7 is a flow chart depicting operations performed by a scene image generation portion of the computer graphics system shown in Figure 2 to generate an image of a scene.

Detailed Description of an Illustrative Embodiment

Figure 1 attached hereto depicts elements comprising a computer graphics system 10 constructed in accordance with the invention. The computer graphics system 10 provides enhanced cooperation between shaders by facilitating the generation of new computer graphics components, referred to herein as "phenomenon" (singular) or "phenomena" (plural), which are used to define characteristics of a scene for use in its rendering. A phenomenon is a packaged and encapsulated system comprising one or more shaders, which are organized and interconnected in the form of one or more directed acyclic graphics ("DAGs"), with each DAG including one or more shaders. The phenomena generated by the computer graphics system 10 are generated in such a way as to ensure that the shader (s) of each shader dAg can cooperate correctly during rendering, to facilitate the rendering of realistic or complex visual effects. In addition, for phenomena comprising multiple cooperating shader DAGs, the computer graphics system 10 generates the phenomena in such a way that the shaders of all shader DAGs can cooperate correctly during rendering to facilitate the rendering of progressively realistic visual effects. or complex.

Referring to Figure 1, the computer graphics system 10 of the embodiment includes a computer that, in turn, includes a processor module 11 and operator interface elements comprising operator data entry components such as a keyboard. 12A and / or a mouse 12B (generally identified as operator data input element (s) 12) and an operator data output element such as a video display device 13. Illustrative computer system 10 is of conventional stored program computer architecture. The processor module 11 includes, for example, processor, memory, and mass storage devices such as disk and / or tape storage elements (not shown separately) that perform processing and storage operations in relation to the digital data supplied to it. the same. The operator data entry element (s) 12 are provided to allow the operator to enter information for processing. The video display device 13 is provided to visually show the operator the output information generated by the processor module 11 on a screen 14, including data that the operator can enter to process, information that the operator can enter to control the processing , as well as information generated during processing. The processor module 11 generates information to be displayed visually by the video display device 13 using a so-called "graphical user interface" ("GUI"), in which information for different application programs is displayed using various "windows". Although the computer system 10 is shown to comprise certain components, such as the

ES 2 255 167 T3 keyboard 12A and mouse 12B to receive input information from an operator and a video display device 13 to visually display output information to the operator, it will be appreciated that computer system 10 may include a variety of components added to or substitutes for those represented in Figure 1.

In addition, the processor module 11 may include one or more network ports, generally identified by reference numeral 14, which are connected to communication links that connect the computer system 10 to a computer network. The network ports enable the computer system 10 to transmit information to, and receive information from, other computer systems and other devices that are on the network. In a typical network organized according to, for example, the client-server paradigm, certain computer systems on the network are designated as servers, which store data and programs (generally, "information") for processing by others. , client computer systems, thereby enabling client computer systems to conveniently share information. A client computer system that needs access to information maintained by a specific server will enable the server to download the information to you over the network. After processing the data, the client computer system can also return the processed data to the server for storage. In addition to computer systems (including the servers and clients described above), a network may also include, for example, printers and fax devices, digital audio or video storage and distribution devices, and the like which can be shared. between the different computer systems connected to the network. The communication links that interconnect the computer systems of the network may, as is conventional, comprise any convenient information transport medium, including cables, optical fibers or other means for transporting signals between the computer systems. Computer systems transfer information through the network by means of messages transferred through communication links including, in each message, information and an identifier that identifies the device that should receive the message.

As outlined above, the computer graphics system 10 provides enhanced cooperation between shaders by facilitating the generation of phenomena comprising packaged and encapsulated shader DAGs or cooperating shader DAGs, with each of the shader DAGs comprising the minus one shader, which defines characteristics of a three-dimensional scene. Phenomena can be used to define various types of characteristics of a scene, including characteristics of color and texture of the surfaces of objects in the scene, characteristics of volumes and geometries of the scene, characteristics of light sources that illuminate the scene, features of simulated cameras or other image recording devices that will be simulated during rendering and numerous other features that are useful when rendering as will be apparent from the following description. The phenomena are constructed in such a way as to ensure that the DAG shaders or cooperating DAGs can cooperate correctly during rendering of a scene image.

Figure 2 depicts a functional block diagram of the computer graphics system 10 used in one embodiment of the invention. As shown in FIG. 2, the computer graphics system 10 includes two general portions, including a scene structure generating portion 20 and a scene image generating portion 21. The generation portion 20 of the scene structure is used by an artist, draftsman or the like (generally an "operator") during the scene entity generation phase to generate a representation of various elements that will be used by the generation portion 21 of the scene image when rendering a scene image, which may include, for example, the objects that are in the scene and the characteristics of their surfaces, the structure and characteristics of the light source or sources that illuminate the scene and the structure and characteristics of a given device, such as a camera, that will be simulated when generating the image when the image is rendered. The representation generated by the scene structure generation portion 20 is in the form of a mathematical representation that is stored in the scene object database 22. The mathematical representation is evaluated by the image rendering portion 21 for display by the operator. The scene structure generation portion 20 and the scene image generation portion 21 may reside on or be part of the same computer, in which case the database 22 of scene objects may also reside on the same computer or, alternatively, on a server for which computer 20 is a client. Alternatively, portions 20 and 21 may reside on or be part of two different computers, in which case the scene object database 22 may reside either on either computer or on the server of both.

More particularly, the scene structure generation portion 20 is used by the operator to generate a mathematical representation that defines, comprising the geometric structures of the scene objects, the locations and geometric characteristics of the light sources that illuminate the scene, and the locations, geometric and optical characteristics of the cameras that will be simulated when generating the images that will be rendered. The mathematical representation preferably defines the three spatial dimensions and thus identifies the location of the objects in the scene and the characteristics of the objects. Objects can be defined according to their characteristics in one, two or three dimensions, which include straight lines or curves inserted in a three-dimensional space, two-dimensional surfaces inserted in a three-dimensional space, one or more bounded and / or closed three-dimensional surfaces or any combination of them. Furthermore, mathematical representations can also define a time dimension, which can be particularly useful in relation to computer animation, in which objects and their respective characteristics are considered to move as a function of time.

In addition to the mathematical representation of the geometric structure of the object or objects of the scene to be rendered, the mathematical representation defines,

ES 2 255 167 T3 furthermore, the one or more light sources illuminating the scene and a camera. The mathematical representation of a light source defines, in particular, the location and / or direction of the light source relative to the scene and the structural characteristics of the light source, including whether the light source is a source. point, a straight or curved line, a flat or curved surface or the like. The mathematical representation of the camera defines, in particular, the conventional parameters of a camera, which include the lens or objective, the focal length, the orientation of the image plane, etc.

The scene structure generation portion 20 also facilitates the generation of phenomena, which will be described in detail below, and the association of phenomena to the corresponding scene elements. The phenomena define, in general, other information that is required to complete the definition of the scene and that will be used in the rendering. This information includes, but is not limited to, characteristics of colors, textures, etc. of the surfaces of the geometric entities defined by the generation portion 20 of the scene structure. A phenomenon may include mathematical representations or other objects that, when evaluated during the rendering operation, will allow the computer to generate the rendered image to display the display of their respective surfaces in the desired manner. The scene structure generation portion 20, under operator control, effectively associates the phenomena with the mathematical representations for the respective elements (that is, objects, surfaces, volumes and the like) with which those, " applying "effectively the phenomena to the respective elements."

After the mathematical representations have been generated by the scene structure generation portion 20 and stored in the scene representation database 22, the scene image generation portion 21 is used by an operator. during a rendering phase to generate an image of the scene in, for example, the video display unit 13 (Figure 1).

The scene structure generation portion 20 includes various elements, including a geometric entity representation generator 23, a phenomenon creator 24, a phenomenon database 25, a phenomenon editor 26, a database 32 of base shader nodes, a database 33 of phenomena instances, and a scene assembler 34, all of which operate under control of operator input information entered through an operator interface 27. The operator interface 27 may generally include the operator data entry devices 12 and the video display unit 13 of the computer graphics system 10 as described above in connection with Figure 1. The generator 23 of representations of geometric entities, under the control of the data entered by the operator from the operator interface 27, facilitates the generation of the mathematical representation of the objects in the scene and of the light source (s) and the camera described above. The phenomenon creator 24 provides a mechanism by which the operator can, using the operator interface 27 and the base shader nodes of the base shader node database 32, generate phenomena that can be used in connection with the scene or otherwise (as will be described below). After a phenomenon is generated by the phenomenon creator 24, it (ie, the phenomenon) will be stored in the phenomenon database 25. After a phenomenon has been stored in the phenomenon database 25, an instance of the phenomenon can be created by the phenomenon editor 26. In this operation, the operator will use the phenomena editor 26 to provide values for the different parameters of the phenomenon (if it is the case). For example, if the phenomenon has been created to provide characteristics, such as color balance, texture graining, gloss or the like, which will be set, adjusted or modified based on the input data of the operator at the time of application or later, the phenomenon editor 26 allows the operator, through the operator interface 27, to set, adjust or modify the particular characteristic. The values for the parameters can either be fixed or they can vary according to a function of a variable (for example, time). The operator, using scene assembler 34, can apply phenomena instances generated using phenomenon editor 26 to elements of the scene as generated by geometric entity representation generator 23.

Although it has been described that the phenomena editor 26 retrieves phenomena from the phenomena database 25 which have been generated by the phenomenon creator 24 of the scene structure generation portion 20 of the computer graphics system 10 , it will be appreciated that one or more of the phenomena, perhaps all, provided in the computer graphics system 10 may be predefined and created by other devices (not shown) and stored in the phenomenon database 25 for use by the phenomenon editor 26. In such a case, the operator, who controls the phenomenon editor through the operator interface 27, can select appropriate predefined phenomena for application to the scene.

The scene image generation portion 21 includes various components including an image generator 30 and an operator interface 31. If the scene image generation portion 21 is part of the same computer as the scene structure generation portion 20, the operator interface 31 may, but need not, comprise the same components as the computer interface 27. operator. On the other hand, if the scene image generation portion 21 is part of a different computer from the computer in which the scene structure generation portion is located, the operator interface 31 will generally comprise different components than those of operator interface 27, although the components of the two operator interfaces 31 and 27 may be similar. The image generator 30, under the control of the operator interface 31, retrieves the representation of the scene to be rendered from the database 22 of scene representations and generates a rendered image for display on the video display unit of operator interface 31.

Before going any further, it would be helpful to further describe a "phenomenon" used in connection with the invention. A phenomenon provides information

ES 2 255 167 T3 which, added to the mathematical representation generated by the geometric entity representation generator 23, is used to complete the definition of the scene that will be used in the rendering, including, but not limited to, color characteristics , textures and closed volumes, etc. of the surfaces of the geometric entities defined by the generation portion 20 of the scene structure. A phenomenon comprises one or more interconnected nodes in the form of a directed acyclic graph ("DAG") or a plurality of cooperating DAGs. One of the nodes is a primary root node that is used to apply the phenomenon to an entity in the scene or, more specifically, to a mathematical representation of the entity. Other types of nodes that can be used in a phenomenon include optional root nodes and shader nodes. The shader nodes can comprise any of a plurality of conventional shaders, including conventional simple shaders, as well as texture shaders, material shaders, volume shaders, ambience shaders, shadow shaders, and displacement shaders, and material shaders that they can be used in connection with generating a representation to be rendered. Additionally, various other types of shader nodes can be used in a phenomenon, including (i) Geometry Shaders, which can be used to add geometric objects to the scene. Geometry shaders essentially comprise static or procedural mathematical representations of entities in three-dimensional space, similar to the representations that are generated by the geometric entity representation generator 23 in relation to entities in the scene, except that they can be provided at a time prior to processing for, for example, define the respective regions in which other shaders used in the corresponding phenomenon will be delimited. A geometry shader essentially has access to the scene building elements of the scene geometric entity representation generator 23 so that it can alter the scene representation as it is stored in the scene object database to For example, modifying or creating new geometric elements of the scene in a static or procedural way. It should be noted that a phenomenon consisting entirely of a geometry shader DAG or a set of cooperating geometry shader DAGs can be used to represent objects in a scene procedurally. This is, in contrast to typical modeling, which is carried out in a modeling system by a human operator by executing a sequence of modeling operations to obtain the desired representation of an object on the computer. In essence, therefore, a geometry phenomenon represents an encapsulated and automated abstract parameterized modeling operation. An instance of a geometry phenomenon (that is, a geometry phenomenon associated with a set of parametric values that are either fixed or vary with time or something similar) in a predetermined way will result in a specific geometric scene extent when evaluated by scene imager 30 at run time during the pre-processing phase.

(ii) Photon shaders, which can be used to control the photon paths of the scene and the interaction characteristics of photons with the surfaces of objects in the scene, such as absorption, reflection and the like. Photon shaders facilitate the physically correct simulation of global illumination and caustics in relation to rendering. In one embodiment, the photon shaders are used during rendering by the scene imager 30 during the pre-processing operation.

(iii) Photon volume shaders, which are similar to photon shaders, except that they operate in relation to a three-dimensional volume of scene space rather than on the surface of an object. This allows lighting and caustics simulation to be extended to enclosed participatory volumes and media that accompany them, such as scattering of photons by airborne dust or mist particles, by water vapor such as in clouds, or the like.

(iv) Photon emitter shaders, which are similar to photon shaders as well, except that they are related to light sources and therefore photon emission. The simulated photons for which the emission is simulated relative to the photon emitter shaders can then be processed relative to the photon shaders, which can be used to simulate path and surface interaction characteristics of the simulated photons. and with photon volume shaders that can be used to simulate paths and other features in three-dimensional volumes, in particular, along the corresponding routes.

(v) Contour shaders, which are used in conjunction with the contour generation lines during rendering. In the embodiment, there are three subtypes of contour shaders, namely, contour storage shaders, contour contrast shaders, and contour generation shaders. A contour storage shader is used to collect contour sampling information for, for example, a surface. A contour contrast shader is used to compare two sets of the sample information that is collected using a contour storage shader. Finally, a contour generation shader is used to generate the contour point information, for storage in a buffer memory, and which is then used by a data output shader (described below) to generate contour lines.

(vi) Data output shaders, which are used to process the information that is in the buffers generated by the scene image generator 30 during rendering. A data output shader can access the pixel information generated during rendering to, in one embodiment, perform composition operations, complex convolutions, and contour line drawing from the contour point information generated by the shaders of contour generation as described above.

(vii) Three-dimensional volume shaders, which are used to control how light and other visible rays and the like pass through part or all of the empty three-dimensional space in a scene. A three-dimensional volume shader can be used for any of several types of volume effects including, for example

ES 2 255 167 T3 example, fog and procedural effects of the type of smoke, flames, fur and particle clouds. Also, since a three-dimensional volume shader is used in relation to light, they are also useful in relation to shadows that would appear from procedural effects; and (viii) Light shaders, which are used to control the emission characteristics of light sources, including, for example, color, direction, and attenuation characteristics that may result from properties such as the shapes of the corresponding light sources. light, texture projection, shading and other properties of light.

Other types of shaders, which can be useful in relation to scene definition can also be used in a phenomenon.

A phenomenon is defined by (i) a description of the externally controllable parameters of the phenomenon, (ii) a primary root node and optionally one or more optional root nodes, (iii) a description of the internal structure of the phenomenon, including the identification of the shaders to be used as nodes and how they are interconnected to form a DAG or a plurality of cooperating DAGs, and (iv) optionally, a description of dialog boxes and the like that can be defined by the phenomenon for use by the phenomenon editor 26 to allow the operator to provide values for the parameters or properties to be used in evaluating the corresponding phenomenon.

Furthermore, a phenomenon can include external declarations and executable code via links from libraries, as is standard in programming.

As highlighted above, a phenomenon can include a plurality of cooperating DAGs. In such a phenomenon, during rendering, the information generated from the processing of one or more nodes of a first phenomenon DAG can be used in the processing in relation to one or more nodes of a second phenomenon DAG. The two DAGs are, however, processed independently and can be processed at different stages of the rendering process. The information generated by a corresponding node of the first DAG that can be "cooperating" with a node of the second DAG (that is, that can be used by the node of the second DAG in its processing), can be transferred from the corresponding node of the first DAG to the node of the second DAG through any convenient communication channel, of the type of a buffer memory that can be assigned to it. Providing all the DAGs that may need to cooperate in this way in a single phenomenon ensures that all conditions for cooperation will be satisfied, which may not be the case if the DAGs are provided not encapsulated or separated in different phenomena or in other entities.

As an example of a phenomenon that includes multiple cooperating DAGs, a phenomenon may include multiple DAGs, including a material shader DAG, a data output shader DAG, and instructions for generating a tag identifier buffer. The material shader DAG includes at least one material shader to generate a color value for a material and also stores labeling information about the objects that are found during the processing of the material shader DAG in the buffer memory of the material. labeling identifiers that is established in relation to the processing of the generation instructions of the labeling identifier buffer memory. The data output shader DAG, in turn, includes at least one data output shader that retrieves labeling information from label identifier buffer memory to facilitate the execution of object-specific composition operations. In addition to the label identifier buffer generation instructions, the phenomenon may also have instructions to control modes of operation of the scene imager 30 such that both DAGs can function and cooperate. For example, such instructions can control the minimum sample density required by the two DAGs to be evaluated.

As a second example of a phenomenon that includes multiple cooperating shader DAGs, a material phenomenon can represent a material that is simulated by both a photon shader DAG, which includes at least one photon shader, and a material shader, which includes at least one material shader. During rendering, the photon shader DAG will be evaluated during caustics and global illumination preprocessing and the material shader DAG will be evaluated later during image rendering. During the processing of the photon shader DAG, the information representing the simulated photons will be stored in such a way that it can be used during the post-processing of the material shader DAG to add lighting contributions from the caustics or lighting pre-processing stage. global. In one embodiment, the photon shader DAG stores the simulated photon information in a photon map, which is used by the photon shader DAG to communicate the simulated photon information to the material shader DAG.

As a third example of a phenomenon that includes multiple cooperating shader DAGs, a phenomenon may include a contour shader DAG, which includes at least one contour shader type shader, and a data output shader DAG, which includes at least one data output shader. The contour shader DAG is used to determine how to draw contour lines by storing "points" of a selected color, transparency, width, and other attributes. The data output shader DAG is used to collect all cells created during rendering and, when rendering is complete, stitch them together into contour lines. The contour shader DAG includes a contour storage shader, a contour contrast shader, and a contour generation shader. The contour storage shader is used to collect the sample information for later use by a contour contrast shader. The contour contrast shader, in turn, is used to determine if the sampling information collected by the contour storage shader is such that a contour point is to be placed on the image and, if so, the shader The contour generation tool actually places the contour point. This example phenomenon illustrates a four-stage cooperation that includes

ES 2 255 167 T3 (1) a first stage, in which the sampling information is collected (by the contour storage shader);

(2) a second stage, in which the decision on whether a contour cell is to be placed (by the contour contrast shader);

(3) a third stage, in which the contour point is created (by the contour generation shader); and (4) a fourth stage, in which the created contour points are created (by the data output shader DAG).

None of the shaders from any of the stages makes use of another shader from another stage but instead they are processed and evaluated individually at different times, but they cooperate to allow the generation of the final result.

As a fourth phenomenon example that includes multiple cooperating shader DAGs, a phenomenon may include a volume shader DAG and a geometry shader DAG. The volume shader DAG includes at least one volume shader that defines properties of a confined volume, for example a fur shader that simulates fur within the confined volume. The geometry shader DAG includes at least one geometry shader that is used to include an outer boundary surface as a new geometry in the scene before rendering begins, with appropriate volume and material shader DAGs assigned to the outer boundary surface to define the calculations to be performed relative to the hair relative to the original volume shader DAG. In this illustrative phenomenon, the cooperation is between the geometry shader DAG and the volume shader DAG, with the geometry shader DAG introducing a procedural geometry in which the geometry shader DAG supports the volume shader DAG. . The volume shader DAG makes use of this geometry, but would not be able to create the geometry itself since the geometry is generated using the geometry shader DAG during a preprocessing operation before rendering, while the DAG of volume shader is used during rendering. The cooperation explained in relation to this fourth illustrative example differs from that explained in relation to the first to third of the illustrative examples in that the shader or shaders comprising the geometry shader procedurally provide elements that are used by the DAG of volume shader, and not only store data, as is the case in relation to the cooperation in relation to the first to third of the illustrative examples.

All of these examples explain computer graphics effects in which an image of a scene can be rendered using multiple cooperating but independent shader DAGs that are grouped and encapsulated into a single phenomenon.

On this basis, the operations performed in relation to the phenomenon creator 24 and the phenomenon editor 26 will be described in relation to Figures 3 and 5, respectively. Furthermore, an illustrative phenomenon created in relation to the phenomenon creator 24 will be described in relation to Figure 4 and details of the operations executed by the phenomenon editor 26 in relation to the phenomenon represented in relation to Figure 4 will be described in in relation to Figures 6A and 6B. Figure 3 depicts a phenomenon creator window 40, which phenomenon creator 24 enables operator interface 27 to display visually to the operator, to allow the operator to define a new phenomenon and modify the definition of an existing phenomenon. The phenomenon creator window 40 includes a plurality of boxes, including an object library box 41, a supported graph nodes box 42, a controls box 43, and a graphics drawing surface box 44. Object library box 41 may include one or more phenomenon icons, generally identified by reference numeral 45, each of which represents a phenomenon that has been, at least partially, defined for use in portion 20 of generation of the scene structure. The supported graph node box 42 includes one or more icons, generally identified by reference numeral 46, that represent entities, such as interfaces, the different types of shaders that can be used in a phenomenon, and the like, that can be selected by the operator for use in a phenomenon. As will be described below, the icons represented in the supported graph nodes box 42 can be used by an operator to form the nodes of the directed acyclic graph that defines a phenomenon to be created or modified. In one embodiment, there are several types of nodes, including:

(i) A primary root node, which forms the root of the directed acyclic graph and forms the connection to the scene and typically provides a color value during rendering.

(ii) Various types of optional root nodes, which can be used as anchor points of a phenomenon DAG to support the main root node (item (i) above). Illustrative types of optional root nodes include:

(a) A lens root node, which can be used to insert lens shaders or lens shader DAGs into a camera for use during rendering;

(b) A volume root node, which can be used to insert a global volume (or atmosphere) shader or shader DAGs into a camera for use during rendering;

(c) A root environment node, which can be used to insert environment shader shaders or DAGs into a camera for use during rendering;

(d) A geometry root node, which can be used to specify geometry shader shaders or DAGs that can be preprocessed during rendering to enable procedural support geometry or other elements of a scene to be added to the database. scene data;

(e) An outline storage root node, which can be used to insert an outline storage shader into the scene options data structure;

ES 2 255 167 T3 (f) A data output root node, which can be used in connection with post-processing after a rendering phase, and (g) A contour contrast root node, which can be used to insert a shader contrast setting in the scene options data structure.

(iii) A shader node, representing a shader, that is, a function written in a high-level language such as C or C ++.

(iv) A light node, used in conjunction with a light source. A light node provides the light source with a shader of light, color, intensity, origin and / or direction and, optionally, a photon emitter shader.

(v) A material node, used in conjunction with a surface. A material node provides a surface with a color value and has data inputs for an opaque indication, which indicates whether the surface is opaque, and for material, volume, ambient, shadow, displacement, photon, photon volume shaders. and outline.

(vi) A phenomenon node, which is a phenomenon instance.

(vii) A constant node, which provides a constant value, which can be input to any of the other nodes. The constant value can be of most of the types of data types used for entities in the programming language, such as shaders, represented by any of the other nodes, such as a scalar, a vector, a logic (a boolean) , color, transformation etc .; and (viii) A dialog node, representing dialog boxes that can be displayed visually by the phenomenon editor 26 to the operator and that can be used by the operator to provide input information to control the phenomenon before or during rendering. . Dialog nodes can enable phenomenon editor 26 to allow buttons, sliders, flyers, etc. to be displayed visually. to allow the operator to specify, for example, the color or other values to be used in relation to the surface to which the phenomenon including the dialog node is connected.

As shown in Figure 3, both the object library box 41 and the supported graph nodes box 42 include right and left arrow icons, generally identified by reference numeral 47, which allow the icons displayed in the corresponding boxes are shifted to the left or right (as shown in Figure 3), to move the icons to be displayed in the phenomenon creator window 40 if there are more entities than could be displayed at one time.

Control box 43 contains icons (not shown) that represent buttons that the operator can use to perform control operations including, for example, deleting or duplicating nodes in the object library box 41 or the supported graph nodes box. 42, start building a new phenomenon, start an online help system, exit phenomenon creator 24, etc.

The phenomenon graphics drawing surface 44 provides an area in which a phenomenon can be created or modified by an operator. If the operator wishes to modify an existing phenomenon, he or she can, using a "drag and drop" methodology that uses a mouse-type pointing device, select and drag the icon 45 from the object library box 41 that represents the phenomenon to the graphics drawing surface 44 of the phenomenon. After the icon 45 associated with the phenomenon to be modified has been dragged onto the phenomenon graphics drawing surface, the operator can enable the icon 45 to expand to display one or more nodes, interconnected by arrows, that represent the graph that defines the phenomenon. A graph 50 representing an illustrative phenomenon is depicted in Figure 3. As shown in Figure 3, graph 50 includes a plurality of graph nodes comprising circles and blocks, each of which is associated with an entity that can be used in a phenomenon, the nodes being interconnected by arrows to define the graphic associated with the phenomenon.

After the graphic associated with the icon that has been dragged onto the phenomenon graphics drawing surface 44 has been expanded to display the graphic defining the phenomenon associated with the icon 45, the operator can modify the graphic defining the phenomenon. . In this operation, the operator can, using the corresponding "drag and drop" methodology, select and drag icons 46 from the box of supported graph nodes 42 that represent entities to be added to the graph of the graph drawing surface 44 of the phenomenon, thereby establishing a new node for the graph. After the new node has been established, the operator can interconnect it to an existing graph node by clicking on both nodes in a suitable way that enables an arrow to be displayed between them. The nodes of the graph may also be disconnected from other nodes, by erasing the arrows that extend between the corresponding nodes, and removed from the graph by appropriate actuation of a delete button in the control box 43.

Similarly, if the operator wishes to create a new phenomenon, he or she can, using the corresponding "drag and drop" methodology, select and drag icons 46 from the box of supported graph nodes 42 that represent the entities to be added. to the graph of the graph drawing surface 44 of the phenomenon, thereby to establish a new graph node to be created. After a new node has been established on the phenomenon graphics drawing surface 44, the operator can interconnect it to an existing graph node by clicking on both nodes in a suitable way that enables an arrow to be displayed between they. The nodes of the graph may also be disconnected from other nodes, by erasing the arrows that extend between the corresponding nodes, and removed from the graph by appropriate actuation of a delete button in the control box 43.

After the operator has specified the cooperating DAG or set of DAGs for the phenomenon, either for a new phenomenon or for a modified phenomenon, and before the phenomenon represented by the graph is stored

ES 2 255 167 T3 in the phenomena database 25, the phenomenon creator 24 will examine the graph of the phenomenon to verify that it is consistent and can be processed during rendering. In this operation, the phenomena creator 24 will ensure that the interconnections between nodes of the graph do not form a cycle, thereby ensuring that the graph or graphs associated with the phenomenon form directed acyclic graphs, and that the interconnections between the nodes of the graph represent the corresponding input and output data types that are consistent. It will be appreciated that if the phenomenon creator 24 determines that the nodes of the graph do cycle, the phenomenon will essentially form an endless loop that generally cannot be processed properly. These operations will ensure that the phenomenon thus created or modified can be processed by the image generation portion of the scene when an image of a scene to which the phenomenon is applied is being rendered.

After the operator has created or modified the phenomenon, it will be stored in the phenomena database 25.

Figure 4 depicts an illustrative phenomenon created in connection with the phenomenon creator 24 that can be generated using the phenomenon creator window described above in connection with Figure 3. The illustrative phenomenon represented in Figure 4, which is identified by reference numeral 60 is one that can be used for the surface characteristics of a wood material. Referring to Figure 4, phenomenon 60 includes a root node, identified by reference numeral 61, which is used to apply phenomenon 60 to an element of the scene. Other nodes in the graph include a material shader node 62, a material texture shader node 63, a coherent noise shader node 64, which respectively represent a material shader, a texture shader, and a shader. coherent noise, and a dialog node 65. Dialog node 65 represents a dialog box that is displayed visually by phenomenon editor 26 to allow the operator to provide input information for use with the phenomenon when the image is rendered.

The details of a material shader, a texture shader, and a coherent noise shader are known to those of skill in the art and will not be described further here. In general, the material shader has one or more output data, represented by "result", which is supplied to the root node 61. The material shader, in turn, has several data inputs, including a "brightness" input, an "ambient" color input, a "diffuse" color input, a "transparency" input, and a " lights ”, and it shows that the material shader node 62 represented by them is receiving inputs from them from the dialog node 65 (in the case of the brightness input), from the texture shader node 63 (in the case of ambient and diffuse color inputs), from a hardware-given constant (in the case of the transparency input) and from a list of lights (in the case of the lights input). The value of the hardware-given constant, indicated as "0.0", supplied in the transparency input indicates that the material is opaque. The "brightness" input is connected to a "brightness" output supplied by the dialog node 65 and, when the material shader represented by node 62 is processed during rendering, it will get the value of the brightness input for it from the dialog box represented by the dialog node, as will be described below in connection with Figures 6A and 6B.

The ambient and diffuse color inputs of the material shader represented by node 62 are provided by the output of the texture shader, as indicated by connecting the "result" output of node 63 to the corresponding inputs of node 62. When the wood material phenomenon 60 is processed during the rendering operation and, in particular, when the material shader represented by node 62 is processed, it will allow the texture shader represented by node 63 to be processed to provide the ambient and diffuse color input values. The texture shader, in turn, has three inputs, including the ambient and diffuse color inputs, represented by the "color 1" and "color 2" inputs shown at node 63, and a "blend" input. The values for the ambient and diffuse color inputs are provided by the operator using the dialog box represented by the dialog node 65, as represented by the connections of the respective diffuse and ambient color outputs of the dialog node 65 with the texture shader node in Figure 4.

Furthermore, the input value for the input of the texture shader represented by node 63 is provided by the coherent noise shader represented by node 64. Thus, when the texture shader represented by node 63 is processed during the operation of rendering, this will allow the coherent noise shader represented by node 64 to be processed to provide the mix input value. The coherent noise shader has two inputs, including a "swirl" input and a "cylindrical" input. The value for the turbulence input is provided by the operator using the dialog box represented by the dialog node 65, as represented by the connections from the turbulence output of the dialog node 65 to the coherent noise shader node. The input value for the cylindrical input, which is displayed as a "TRUE" logic value, is given by hardware in phenomenon 60.

The operations performed by the phenomenon editor 26 will be described in relation to Figure 5. Figure 5 depicts a phenomenon editor window 70 that the phenomenon editor 26 enables to be displayed visually by the operator interface 27 for use. by an operator in an embodiment of the invention to set and adjust the input values for the phenomena that have been applied to the scene. In particular, the operator can use the phenomena editor window to establish values for the phenomena that are supplied by dialog boxes associated with dialog nodes, of the type of node 65 (Figure 4), established by the corresponding phenomena during their creation. or modification as described above in relation to Figure 3. The phenomenon editor window 70 includes a plurality of boxes, including an object library box 71 and a control box 72, and also includes a phenomenon dialog window 73 and a phenomenon preview window 74. The object library box 71 represents icons 80 that

ES 2 255 167 T3 represent the different phenomena that are available for application to a scene. As with the phenomenon creator window 40 (Figure 3), the object library box includes left and right arrow icons, generally identified by reference numeral 81, which allow the icons displayed in the corresponding box to be scrolled left or right (as shown in Figure 3), to scroll the icons to be displayed in the phenomenon editor window 790 if there are more icons than could be displayed at one time.

Control box 72 contains icons (not shown) representing buttons that the operator can use to perform control operations, including, for example, deleting or duplicating icons in object library box 71, starting an on-line help system. line, exit phenomena editor 26, etc.

The operator can select a phenomenon whose parameter values are to be set by proper manipulation of a mouse-type pointing device in order to instantiate a phenomenon. (An instance of a phenomenon corresponds to a phenomenon whose parameter values have been set). After the operator has selected a phenomenon, the phenomenon editor 26 will enable the operator interface 27 to visually display the dialog box associated with its dialog node in the phenomenon dialog window. An illustrative dialog box, used in connection with one embodiment of the wood material phenomenon 60 described above in connection with Figure 4, will be described later in connection with Figures 6A and 6B. As the operator supplies and adjusts the input values that can be supplied through the dialog box, the phenomenon editor 26 effectively processes the phenomenon and visually displays the resulting output data in the phenomenon preview window 74. Thus, the operator can use the phenomenon editor window 70 to see the result of the values he or she sets using the inputs available through the dialog box displayed in the phenomenon dialog window.

Figures 6A and 6B graphically represent details of a dialog node (in the case of Figure 6A) and an associated illustrative dialog box (in the case of Figure 6B), which are used in connection with the material phenomenon 60 wood represented in Figure 4. The dialog node, which is identified by reference number 65 in Figure 4, is defined and created by the operator using the phenomenon creator 24 during the process of creating or modifying the particular phenomenon with which it is associated. Referring to Figure 6A, the dialog box 65 includes a plurality of tiles, namely, an ambient color tile 90, a diffuse color tile 91, a swirl tile 92, and a gloss tile 93. It will be appreciated that the respective tiles 90 to 93 are associated with the corresponding ambient color, diffuse color, turbulence and brightness output values provided by the dialog node 65 as previously described in connection with Figure 4. Ambient and diffuse color tiles are associated with color values, which can be specified using a conventional red / green / blue / alpha, or “RGBA” color / transparency specification, and thus each color tile will be actually associated with multiple input values, one for each of the red, green, and blue colors in the color representation and one for transparency (alpha). On the other hand, each of the turbulence and brightness tiles, 92 and 93, is associated with a scalar value.

Figure 6B depicts an illustrative dialog box 100 that is associated with dialog node 65 (Figure 6A), as displayed on operator interface 27 under control of phenomenon editor 26. In dialog box 100, ambient and diffuse color tiles 90 and 91 of dialog node 65 are each displayed by operator interface 27 as respective sets of sliders, generally identified by reference numerals 101 and 102 , respectively, each of which is associated with one of the colors of the color representation to be used during the processing of the associated phenomenon during rendering. Furthermore, the turbulence and brightness tiles 92 and 93 of the dialog node 65 are each displayed by the operator interface 27 as individual sliders 103 and 104. The slide bars of the respective slide bar assemblies 101 and 102 can be manipulated by the operator, using a mouse-type pointing device, in a conventional manner to thereby enable the phenomenon editor 26 to adjust the corresponding combinations. of colors for the respective values of ambient and diffuse color provided by the dialog node 65 to the shaders associated with the other nodes of the phenomenon 60 (Figure 4). Furthermore, the sliders 103 and 104 associated with the turbulence and brightness inputs can be manipulated by the operator thereby enabling the phenomena editor 26 to adjust the respective values of turbulence and brightness provided by the dialog node 65 to the shaders. associated with the other nodes of the phenomenon 60 of wood material.

Returning to Figure 2, after the operator, using the phenomena editor 26, has set the values for the different phenomena and the phenomena instances associated with a scene, those values are stored with the scene in database 22 of objects in the scene. thereafter, an image of the scene can be rendered by the scene image generation portion 21, in particular by the scene image generator 30 for display by the operator interface 31. The operations performed by the scene imager 30 will be described generally in relation to the flow chart depicted in Figure 7. Referring to Figure 7, the scene imager 30 operates in a series of phases, including a pre-processing phase, a rendering phase, and a post-processing phase. In the pre-processing phase, the scene imager 30 will examine the phenomena that are applied to a scene to determine if it will need to perform pre-processing and / or post-processing operations in relation to them (step 100). The scene imager 30 then determines whether the operations in step 100 indicated that preprocessing operations are required in relation to at least one phenomenon applied to the scene (step 101) and, if so, will execute the preprocessing operations ( step 102). Illustrative preprocessing operations

ES 2 255 167 T3 include, for example, the generation of scene geometry, if a phenomenon applied to the scene includes a geometry shader, to generate the geometry defined by it for the scene. Other illustrative preprocessing operations include, for example, photon and shadow mapping, multiple inheritance resolution, and the like. After step 102, or step 101 if the scene imager 30 makes a negative determination at that step, the scene imager 30 may perform more preprocessing operations that may be required in connection with rendering the scene before rendering, which are not related to the phenomena applied to the scene (step 103).

After step 103, the scene image generator 30 will execute the rendering phase in which it executes the rendering operations in relation to the pre-processed scene representation to generate a rendered image (step 104). In this operation, the scene image generator 30 will identify the phenomena stored in the scene object database 22 that are going to be applied to the different scene components, as generated by the geometric representation generator 23 of entities and apply all the primary and optional root nodes of the respective phenomena to the scene components appropriate to the root node type. After this, the scene imager 30 will render the image. In addition, the scene imager 30 will generate information, as necessary, that can be used in post-processing operations during the post-processing phase.

After the rendering phase (step 104), the scene imager 30 will execute the post-processing phase. In this operation, the scene imager 30 will determine whether the operations performed in step 100 indicated that post-processing operations were required in relation to the phenomena applied to the scene (step 105). If the scene imager 30 makes a positive determination in step 105, it will execute the required post-processing operations in relation to the phenomena applied to the scene (step 106). In addition, the scene image generator 30 may also perform other post-processing operations that are unrelated to the phenomena of step 106. The scene imager 30 can perform post-processing operations in relation to manipulating the pixel values for color correction, filtering to provide different optical effects. In addition, the scene imager 30 can perform post-processing operations if, for example, a phenomenon applied to the scene includes a data output shader that defines post-processing operations, such as depth-of-field calculations or motion blur. which can be, in one embodiment, done entirely in a data output shader, for example, depending on the speed and depth information stored in relation to each pixel value, relative to the rendered image.

The invention provides several advantages. In particular, the invention provides a computer graphics system that provides tools for creating (referring to phenomena creator 24) and manipulating (referring to phenomena editor 26) phenomena. The phenomena thus created are processed by the phenomenon creator 24 to ensure that they are coherent and that they can be processed during rendering. Since phenomena are created before being applied to a scene, it will be appreciated that they can be created by programmers or others who are skilled in developing computer programs, thereby relieving others, such as artists, cartoonists, and the like of the need to develop them. Also, phenomena relieve the artist of the complexity of instrumenting the scene with many different and interrelated shaders by separating it (that is, the complexity) into a separate task henceforth executed by an expert user of the phenomenon creator. With phenomena, instrumentation becomes largely automated. Once a phenomenon or phenomenon instance has been created, it is independent of the scene and can be reused in many scenes thus avoiding repetitive work.

It will be appreciated that various changes and modifications can be made to the invention. As noted above, since phenomena can be created separately from their use in relation to a scene, the phenomena creator 24, used to create and modify phenomena, and the phenomena editor 26, used to create instances of phenomena, can be fed to separate computer graphics systems. For example, a computer graphics system 10 that includes a phenomenon editor 26 need not include a phenomenon creator 24 if, for example, the phenomenon database 25 includes the appropriate previously created phenomena and the operator will not need to create or modify phenomena.

Furthermore, as noted above, the parameter values of a phenomenon can be fixed or they can vary based on a function of one or more variables. For example, if one or more values of the respective parameters vary according to time as a variable, the phenomenon instance can be made time dependent, or "animated". This is normally discretized in time intervals that are labeled by the frame numbers of a series of frames that comprise an animation, but the time dependence can, however, take the form of any function evaluated in the time of phenomenon parameters. , each of which can be labeled with an absolute time value, so that even if an image is rendered in successive frame numbers, shaders are not tied to discrete intervals.

In this regard, the phenomenon editor is used to select time-dependent values for one or more parameters of a phenomenon, creating a time-dependent "phenomenon instance". The selection of time-dependent values for the parameters of a phenomenon is carried out, in a particular embodiment, by means of the graphically interactive assignment of what will be referred to hereinafter as "phenomenon property control trees" to a phenomenon. A phenomenon property control tree, which may be in the form of a tree or a DAG, is assigned to the parameters of the phenomenon, actually outside the phenomenon, and is stored with the phenomenon in the database of phenomena instances. A control tree of properties of the phenomenon

ES 2 255 167 T3 consists of one or more nodes, each of which is a shader in the sense of the functions that it provides, for example, motion curves, data search functions and the like. A phenomenon property control tree can preferably remain shallow and will normally have only very few levels of branching. A phenomenon property control tree can consist of a single shader, which defines a function to compute the value for the parameter associated with it at runtime. A phenomenon property control tree can remain shallow because the phenomenon allows and stimulates the encapsulation of complicated shader trees or DAGs, facilitating their evaluation in an optimized way during the rendering step by, for example, data storage. for reuse. Allowing the operator to assign such phenomenon property control trees to control the phenomenon parameters increases the flexibility of the user to carry out custom effects based on the use of a predefined packed phenomenon. The number of distinct phenomenon instances that can be created in this way is thereby greatly increased, while ease of use is not compromised thanks to the encapsulation of all the complexity of the phenomenon.

Furthermore, it will be appreciated that the appearance and structures of the windows used in relation to the phenomenon creator 24 and the phenomenon editor 26, described in connection with Figures 3 and 5, may differ from those described herein.

It will be appreciated that a system in accordance with the invention may be constructed in whole or in part from special purpose hardware or a general purpose computer system, or any combination thereof, any portion of which may be controlled by a suitable program. Any program may, in whole or in part, comprise part of or be stored in the system in a conventional manner or it may, in whole or in part, be provided to the system through a network or other mechanism to transfer information in a conventional manner. . Furthermore, it will be appreciated that the system may be operated and / or otherwise controlled by means of information provided by an operator using the operator input elements (not shown) that may be directly connected to the system or that may transfer the information. to the system through a network or other mechanism to transfer information in a conventional way.

The foregoing description has been limited to a specific embodiment of this invention. It will be clear, however, that different variations and modifications can be made to the invention with some or all of the advantages of the invention being obtained.

Contents2

31 members in 10 offices

This recordMember, by publication datePriority claim

Priority claims5

Priority claims
Document	Office	Kind	Date
19970051507P	United States of America	–	1997-07-02
5150797	United States of America	P	1997-07-02
5150797	United States of America	P	1997-07-02
9893096651507P	–	–	–
US19970051507P	–	–	–

Members31

Family members, oldest first
Document	Office	Kind
CA2294233A1	Canada	A1	1999-01-14
WO9901846A1	World Intellectual Property Organization (WIPO)	A1	1999-01-14
AU8123798A	Australia	A	1999-01-25
EP0993659A1	European Patent Office (EPO)	A1	2000-04-19
JP2001509620A	Japan	A	2001-07-24
AU752048B2	Australia	B2	2002-09-05
US6496190B1	United States of America	B1	2002-12-17
US2003001844A1	United States of America	A1	2003-01-02
US6606092B2	United States of America	B2	2003-08-12
US2003222870A1	United States of America	A1	2003-12-04
EP0993659B1	European Patent Office (EPO)	B1	2005-11-30
AT311637T	Austria	T	2005-12-15
ATE311637T1	Austria	T1	2005-12-15
DE69832611D1	Germany	D1	2006-01-05
DK0993659T3	Denmark	T3	2006-03-27
ES2255167T3This record	Spain	T3	2006-06-16
DE69832611T2	Germany	T2	2006-08-10
AU2006265815A1	Australia	A1	2007-01-11
CA2613541A1	Canada	A1	2007-01-11
WO2007005739A2	World Intellectual Property Organization (WIPO)	A2	2007-01-11
US2007018980A1	United States of America	A1	2007-01-25
US7173617B2	United States of America	B2	2007-02-06
CA2294233C	Canada	C	2007-06-05
EP1907964A2	European Patent Office (EPO)	A2	2008-04-09
WO2008073876A1	World Intellectual Property Organization (WIPO)	A1	2008-06-19
US2008150943A1	United States of America	A1	2008-06-26
WO2007005739A3	World Intellectual Property Organization (WIPO)	A3	2008-09-18
JP2009500730A	Japan	A	2009-01-08
US7548238B2	United States of America	B2	2009-06-16
EP1907964A4	European Patent Office (EPO)	A4	2009-08-12
US9007393B2	United States of America	B2	2015-04-14