U.S. patent application number 11/460797 was filed with the patent office on 2008-01-31 for cache utilization optimized ray traversal algorithm with minimized memory bandwidth requirements.
Invention is credited to Robert Allen Shearer.
Application Number | 20080024489 11/460797 |
Document ID | / |
Family ID | 38814481 |
Filed Date | 2008-01-31 |
United States Patent
Application |
20080024489 |
Kind Code |
A1 |
Shearer; Robert Allen |
January 31, 2008 |
Cache Utilization Optimized Ray Traversal Algorithm with Minimized
Memory Bandwidth Requirements
Abstract
Embodiments of the invention provide methods and apparatus for
recording the traversal history of a ray through a spatial index
structure and utilizing the recorded traversal history. An image
processing system may initially determine which nodes a ray
intersects as it traverses through a spatial index. Results of the
node intersection determinations may be recorded as the ray
traverses the spatial index, and the recorded determinations may be
associated with the ray. Furthermore, the image processing system
may decide upon a traversal path based upon some probability of
striking primitives corresponding to the nodes which make up the
spatial index. This traversal path may also be recorded and
associated with the ray. If the image processing system needs to
re-traverse the spatial index at a later time, the recorded
traversal history may be used to eliminate the need to recalculate
ray-node intersections, and eliminate incorrect traversal path
determinations.
Inventors: |
Shearer; Robert Allen;
(Rochester, MN) |
Correspondence
Address: |
IBM CORPORATION, INTELLECTUAL PROPERTY LAW;DEPT 917, BLDG. 006-1
3605 HIGHWAY 52 NORTH
ROCHESTER
MN
55901-7829
US
|
Family ID: |
38814481 |
Appl. No.: |
11/460797 |
Filed: |
July 28, 2006 |
Current U.S.
Class: |
345/421 |
Current CPC
Class: |
G06T 15/06 20130101;
G06T 15/50 20130101 |
Class at
Publication: |
345/421 |
International
Class: |
G06T 15/40 20060101
G06T015/40 |
Claims
1. A method of ray tracing utilizing a spatial index having nodes
defining bounded volumes of a three dimensional scene comprising:
generating a ray into the scene; traversing the spatial index by
taking branches from internal nodes until a leaf node is reached,
wherein branches are taken based on whether the ray intersects
bounding volumes defined by the nodes; recording a traversal
history indicating one or more nodes defining bounding volumes the
ray intersects and branches taken when traversing the spatial
index; determining if the ray hits a primitive contained in the
bounding volume defined by the leaf node; and if the ray does not
hit a primitive contained in the bounding volume defined by the
leaf node, re-traversing the spatial index using the recorded
traversal history.
2. The method of claim 1, wherein the spatial index contains a
plurality of internal node levels, and the traversal history is
recorded for each node level.
3. The method of claim 1, wherein the spatial index contains a
plurality of internal node levels and the traversal history
comprises four bits for each internal node level of the spatial
index
4. The method of claim 3, wherein two of the traversal history bits
indicate whether the ray intersects bounding volumes defined by a
node located within one of the internal node levels, and wherein
two of the traversal history bits indicate branches taken when
traversing the spatial index from the node on one of the internal
node levels.
5. The method of claim 1, further comprising: storing the ray
traversal history with information defining the ray; and
transmitting information defining the ray and the traversal history
from a workload manager executing on a first processing element to
a vector throughput engine executing on a second processing
element, wherein the workload manager and the vector throughput
engine communicate through a memory mapped address space.
6. The method of claim 5, wherein the workload manager determines
whether the ray intersects bounding volumes defined by the nodes,
wherein the workload manager records the traversal history, and
wherein the vector throughput engine determines if the ray hits a
primitive contained in the bounding volume defined by the leaf
node.
7. The method of claim 6, wherein the workload manager and the
vector throughput engine are located on the same processing
element.
8. The method of claim 6, wherein the workload manager and the
vector throughput engine are located on separate processing
elements.
9. The method of claim 1, wherein re-traversing the spatial index
using the recorded traversal history comprises, determining a
lowest level on the spatial index where bounding volumes
corresponding to a node were intersected by the ray, but a branch
from the node was not taken; traversing the spatial index based on
the branches taken and recorded in the traversal history to the
lowest level; taking the branch from the node not yet taken; and
traversing the spatial index below lowest level by taking branches
from internal nodes until a leaf node is reached, wherein branches
are taken based on whether the ray intersects bounding volumes
defined by the nodes; recording a traversal history below the
lowest level indicating one or more nodes defining bounding volumes
the ray intersects and branches taken when traversing the spatial
index; and determining if the ray hits a primitive contained in the
bounding volume below the lowest level and defined by the leaf
node.
10. A computer readable medium containing a program which, when
executed, performs an operation for ray tracing utilizing a spatial
index having nodes defining bounded volumes of a three dimensional
scene, the operation comprising: generating a ray into the scene;
traversing the spatial index by taking branches from internal nodes
until a leaf node is reached, wherein branches are taken based on
whether the ray intersects bounding volumes defined by the nodes;
recording a traversal history indicating one or more nodes defining
bounding volumes the ray intersects and branches taken when
traversing the spatial index; determining if the ray hits a
primitive contained in the bounding volume defined by the leaf
node; and if the ray does not hit a primitive contained in the
bounding volume defined by the leaf node, re-traversing the spatial
index using the recorded traversal history.
11. The computer readable medium of claim 10, wherein the spatial
index contains a plurality of internal node levels, and the
traversal history is recorded for each node level.
12. The computer readable medium of claim 10, wherein the spatial
index contains a plurality of internal node levels and the
traversal history comprises four bits for each internal node level
of the spatial index, wherein two of the traversal history bits
indicate whether the ray intersects bounding volumes defined by a
node on one of the internal node levels, and wherein two of the
traversal history bits indicate branches taken when traversing the
spatial index from the node on one of the internal node levels.
13. The computer readable medium of claim 10, wherein the
operations further comprise: storing the ray traversal history with
information defining the ray; and transmitting information defining
the ray and the traversal history from a workload manager executing
on a first processing element to a vector throughput engine
executing on a second processing element, wherein the workload
manager and the vector throughput engine communicate through a
memory mapped address space.
14. The computer readable medium of claim 13, wherein the workload
manager determines whether the ray intersects bounding volumes
defined by the nodes, wherein the workload manager records the
traversal history, and wherein the vector throughput engine
determines if the ray hits a primitive contained in the bounding
volume defined by the leaf node.
15. The computer readable medium of claim 10, wherein re-traversing
the spatial index using the recorded traversal history comprises:
determining a lowest level on the spatial index where bounding
volumes corresponding to a node were intersected by the ray, but
the branch from the node was not taken; traversing the spatial
index based on the branches taken and recorded in the traversal
history to the lowest level; taking the branch from the node not
yet taken; and traversing the spatial index below lowest level by
taking branches from internal nodes until a leaf node is reached,
wherein branches are taken based on whether the ray intersects
bounding volumes defined by the nodes; and wherein the operations
further comprise: recording a traversal history below the lowest
level indicating one or more nodes defining bounding volumes the
ray intersects and branches taken when traversing the spatial
index; and determining if the ray hits a primitive contained in the
bounding volume below the lowest level and defined by the leaf
node.
16. A system, comprising: a spatial index having nodes defining
bounded volumes of a three dimensional scene; and a first
processing element, wherein the first processing element is
configured to: generate a ray into the scene; traverse the spatial
index by taking branches from internal nodes until a leaf node is
reached, wherein branches are taken based on whether the ray
intersects bounding volumes defined by the nodes; record a
traversal history indicating one or more nodes defining bounding
volumes the ray intersects and branches taken when traversing the
spatial index; determine if the ray hits a primitive contained in
the bounding volume defined by the leaf node; and if the ray does
not hit a primitive contained in the bounding volume defined by the
leaf node, re-traverse the spatial index using the recorded
traversal history.
17. The system of claim 16, wherein the first processing element
further comprises: a plurality of threads; and a memory mapped
address space; and the first processing element is further
configured to: store the ray traversal history with information
defining the ray; and transmit information defining the ray and the
traversal history from a workload manager executing on a first
processing element thread to a vector throughput engine executing
on a second processing element thread, wherein the workload manager
and the vector throughput engine communicate through the memory
mapped address space.
18. The system of claim 17, wherein the workload manager determines
whether the ray intersects bounding volumes defined by nodes, the
workload manager records the traversal history, and the vector
throughput engine determines if the ray hits a primitive contained
in the bounding volume defined by the leaf node.
19. The system of claim 17, wherein the system further comprises: a
second processing element comprising a second plurality of threads
and a second memory mapped address space; a high speed bus coupling
the first processing element to the second processing element; and
wherein the workload manager executes on the first processing
element and the vector throughput engine executes on the second
processing element, and wherein the workload manager and the vector
throughput engine communicate through the high speed bus and the
memory mapped address spaces.
20. The system of claim 16, wherein re-traversing the spatial index
using the recorded traversal history comprises, determining a
lowest level on the spatial index where bounding volumes
corresponding to a node that were intersected by the ray, but a
branch from the node was not taken; traversing the spatial index
based on the branches taken and recorded in the traversal history
to the lowest level; taking the branch from the node not yet taken;
and traversing the spatial index below lowest level by taking
branches from internal nodes until a leaf node is reached, wherein
branches are taken based on whether the ray intersects bounding
volumes defined by the nodes; and wherein the system is further
configured to: record a traversal history below the lowest level
indicating one or more nodes defining bounding volumes the ray
intersects and branches taken when the system traverses the spatial
index; and determine if the ray hits a primitive contained in the
bounding volume below the lowest level and defined by the leaf
node.
Description
BACKGROUND OF THE INVENTION
[0001] 1. Field of the Invention
[0002] Embodiments of the invention generally relate to the field
of image processing.
[0003] 2. Description of the Related Art
[0004] The process of rendering two-dimensional images from
three-dimensional scenes is commonly referred to as image
processing. As the modern computer industry evolves image
processing evolves as well. One particular goal in the evolution of
image processing is to make two-dimensional simulations or
renditions of three-dimensional scenes as realistic as possible.
One limitation of rendering realistic images is that modern
monitors display images through the use of pixels.
[0005] A pixel is the smallest area of space which can be
illuminated on a monitor. Most modern computer monitors will use a
combination of hundreds of thousands or millions of pixels to
compose the entire display or rendered scene. The individual pixels
are arranged in a grid pattern and collectively cover the entire
viewing area of the monitor. Each individual pixel may be
illuminated to render a final picture for viewing.
[0006] One technique for rendering a real world three-dimensional
scene onto a two-dimensional monitor using pixels is called
rasterization. Rasterization is the process of taking a
two-dimensional image represented in vector format (mathematical
representations of geometric objects within a scene) and converting
the image into individual pixels for display on the monitor.
Rasterization is effective at rendering graphics quickly and using
relatively low amounts of computational power; however,
rasterization suffers from some drawbacks. For example,
rasterization often suffers from a lack of realism because it is
not based on the physical properties of light, rather rasterization
is based on the shape of three-dimensional geometric objects in a
scene projected onto a two dimensional plane. Furthermore, the
computational power required to render a scene with rasterization
scales directly with an increase in the complexity of the scene to
be rendered. As image processing becomes more realistic, rendered
scenes also become more complex. Therefore, rasterization suffers
as image processing evolves, because rasterization scales directly
with complexity.
[0007] Another technique for rendering a real world
three-dimensional scene onto a two-dimensional monitor using pixels
is called ray tracing. The ray tracing technique traces the
propagation of imaginary rays, rays which behave similar to rays of
light, into a three-dimensional scene which is to be rendered onto
a computer screen. The rays originate from the eye(s) of a viewer
sitting behind the computer screen and traverse through pixels,
which make up the computer screen, towards the three-dimensional
scene. Each traced ray proceeds into the scene and may intersect
with objects within the scene. If a ray intersects an object within
the scene, properties of the object and several other contributing
factors are used to calculate the amount of color and light, or
lack thereof, the ray is exposed to. These calculations are then
used to determine the final color of the pixel through which the
traced ray passed.
[0008] The process of tracing rays is carried out many times for a
single scene. For example, a single ray may be traced for each
pixel in the display. Once a sufficient number of rays have been
traced to determine the color of all of the pixels which make up
the two-dimensional display of the computer screen, the two
dimensional synthesis of the three-dimensional scene can be
displayed on the computer screen to the viewer.
[0009] Ray tracing typically renders real world three dimensional
scenes with more realism than rasterization. This is partially due
to the fact that ray tracing simulates how light travels and
behaves in a real world environment, rather than simply projecting
a three dimensional shape onto a two dimensional plane as is done
with rasterization. Therefore, graphics rendered using ray tracing
more accurately depict on a monitor what our eyes are accustomed to
seeing in the real world.
[0010] Furthermore, ray tracing also handles increases in scene
complexity better than rasterization as scenes become more complex.
Ray tracing scales logarithmically with scene complexity. This is
due to the fact that the same number of rays may be cast into a
scene, even if the scene becomes more complex. Therefore, ray
tracing does not suffer in terms of computational power
requirements as scenes become more complex as rasterization
does.
[0011] One major drawback of ray tracing is the large number of
calculations, and thus processing power, required to render scenes.
This leads to problems when fast rendering is needed. For example,
when an image processing system is to render graphics for animation
purposes such as in a game console. Due to the increased
computational requirements for ray tracing it is difficult to
render animation quickly enough to seem realistic (realistic
animation is approximately twenty to twenty-four frames per
second).
[0012] Therefore, there exists a need for more efficient techniques
and devices to perform ray tracing.
SUMMARY OF THE INVENTION
[0013] Embodiments of the present invention generally provide
methods and apparatus for performing ray tracing.
[0014] According to one embodiment of the invention a method of ray
tracing utilizing a spatial index having nodes defining bounded
volumes of a three dimensional scene is provided. The method
generally comprising: generating a ray into the scene; traversing
the spatial index by taking branches from internal nodes until a
leaf node is reached, wherein branches are taken based on whether
the ray intersects bounding volumes defined by the nodes; recording
a traversal history indicating one or more nodes defining bounding
volumes the ray intersects and branches taken when traversing the
spatial index; determining if the ray hits a primitive contained in
the bounding volume defined by the leaf node; and if the ray does
not hit a primitive contained in the bounding volume defined by the
leaf node, re-traversing the spatial index using the recorded
traversal history.
[0015] According to another embodiment of the invention a computer
readable medium containing a program which, when executed, performs
an operation for ray tracing utilizing a spatial index having nodes
defining bounded volumes of a three dimensional scene is provided.
The operation generally comprising: generating a ray into the
scene; traversing the spatial index by taking branches from
internal nodes until a leaf node is reached, wherein branches are
taken based on whether the ray intersects bounding volumes defined
by the nodes; recording a traversal history indicating one or more
nodes defining bounding volumes the ray intersects and branches
taken when traversing the spatial index; determining if the ray
hits a primitive contained in the bounding volume defined by the
leaf node; and if the ray does not hit a primitive contained in the
bounding volume defined by the leaf node, re-traversing the spatial
index using the recorded traversal history.
[0016] According to another embodiment of the invention a system,
is provided. The system generally comprising a spatial index having
nodes defining bounded volumes of a three dimensional scene; and a
first processing element, wherein the first processing element is
generally configured to: generate a ray into the scene; traverse
the spatial index by taking branches from internal nodes until a
leaf node is reached, wherein branches are taken based on whether
the ray intersects bounding volumes defined by the nodes; record a
traversal history indicating one or more nodes defining bounding
volumes the ray intersects and branches taken when traversing the
spatial index; determine if the ray hits a primitive contained in
the bounding volume defined by the leaf node; and if the ray does
not hit a primitive contained in the bounding volume defined by the
leaf node, re-traverse the spatial index using the recorded
traversal history.
BRIEF DESCRIPTION OF THE DRAWINGS
[0017] FIG. 1 illustrates a multiple core processing element,
according to one embodiment of the invention.
[0018] FIG. 2 illustrates multiple core processing element network,
according to one embodiment of the invention.
[0019] FIG. 3 is an exemplary three dimensional scene to be
rendered by an image processing system, according to one embodiment
of the invention.
[0020] FIGS. 4A-4C illustrate a two dimensional space to be
rendered by an image processing system and a corresponding spatial
index created by an image processing system, according to one
embodiment of the invention.
[0021] FIG. 5 illustrates a spatial index and a corresponding data
structure for storing traversal history of a ray through the
spatial index, according to one embodiment of the invention.
[0022] FIGS. 6 and 7 are flowcharts illustrating methods for
traversing a spatial index, according to one embodiment of the
invention.
[0023] FIG. 8 is an exemplary two dimensional space to be rendered
by an image processing system, according to one embodiment of the
invention.
[0024] FIGS. 9A-9G illustrate the traversal of a ray through a
spatial index, according to one embodiment of the invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0025] Embodiments of the invention provide techniques and systems
for recording the traversal history of a ray through a spatial
index structure and utilizing the recorded traversal history of a
ray through the spatial index. An image processing system may
initially determine which nodes a ray intersects as it traverses
through a spatial index. Results of the node intersection
determinations may be recorded as the ray traverses the spatial
index, and the recorded determinations may be associated with the
ray. Furthermore, the image processing system may decide upon a
traversal path based upon some probability of striking primitives
corresponding to the nodes which make up the spatial index. This
traversal path may also be recorded and associated with the ray. If
the image processing system needs to re-traverse the spatial index
at a later time, the recorded traversal history may be used to
eliminate the need to recalculate ray-node intersections, and
eliminate incorrect traversal path determinations.
[0026] In the following, reference is made to embodiments of the
invention. However, it should be understood that the invention is
not limited to specific described embodiments. Instead, any
combination of the following features and elements, whether related
to different embodiments or not, is contemplated to implement and
practice the invention. Furthermore, in various embodiments the
invention provides numerous advantages over the prior art. However,
although embodiments of the invention may achieve advantages over
other possible solutions and/or over the prior art, whether or not
a particular advantage is achieved by a given embodiment is not
limiting of the invention. Thus, the following aspects, features,
embodiments and advantages are merely illustrative and are not
considered elements or limitations of the appended claims except
where explicitly recited in a claim(s). Likewise, reference to "the
invention" shall not be construed as a generalization of any
inventive subject matter disclosed herein and shall not be
considered to be an element or limitation of the appended claims
except where explicitly recited in a claim(s).
An Exemplary Processor Layout and Communications Network
[0027] FIG. 1 illustrates a multiple core processing element 100,
according to one embodiment of the invention. The multiple core
processing element 100 includes a plurality of basic throughput
engines 105 (BTEs). A BTE 105 may contain a plurality of processing
threads and a core cache (e.g., an L1 cache). The processing
threads located within each BTE may have access to a shared
multiple core processing element cache 110 (e.g., an L2 cache).
[0028] The BTEs 105 may also have access to a plurality of inboxes
115. The inboxes 115 may be memory mapped address space. The
inboxes 115 may be mapped to the processing threads located within
each of the BTEs 105. Each thread located within the BTEs may have
a memory mapped inbox and access to all of the other memory mapped
inboxes 115. The inboxes 115 make up a low latency and high
bandwidth communications network used by the BTEs 105.
[0029] The BTEs may use the inboxes 115 as a network to communicate
with each other and redistribute data processing work amongst the
BTEs. For some embodiments, separate outboxes may be used in the
communications network, for example, to receive the results of
processing by BTEs 105. For other embodiments, inboxes 115 may also
serve as outboxes, for example, with one BTE 105 writing the
results of a processing function directly to the inbox of another
BTE 105 that will use the results.
[0030] The aggregate performance of an image processing system may
be tied to how well the BTEs can partition and redistribute work.
The network of inboxes 115 may be used to collect and distribute
work to other BTEs without corrupting the shared multiple core
processing element cache 110 with BTE communication data packets
that have no frame to frame coherency. An image processing system
which can render many millions of triangles per frame may include
many BTEs 105 connected in this manner.
[0031] In one embodiment of the invention, the threads of one BTE
105 may be assigned to a workload manager. An image processing
system may use various software and hardware components to render a
two dimensional image from a three dimensional scene. According to
one embodiment of the invention, an image processing system may use
a workload manager to traverse a spatial index with a ray issued by
the image processing system. A spatial index, as described further
below with regards to FIG. 4, may be implemented as a tree type
data structure used to partition a relatively large three
dimensional scene into smaller bounding volumes. An image
processing system using a ray tracing methodology for image
processing may use a spatial index to quickly determine
ray-bounding volume intersections. In one embodiment of the
invention, the workload manager may perform ray-bounding volume
intersection tests by using the spatial index.
[0032] In one embodiment of the invention, other threads of the
multiple core processing element BTEs 105 on the multiple core
processing element 100 may be vector throughput engines. After a
workload manager determines a ray-bounding volume intersection, the
workload manager may issue (send), via the inboxes 115, the ray to
one of a plurality of vector throughput engines. The vector
throughput engines may then determine if the ray intersects a
primitive contained within the bounding volume. The vector
throughput engines may also perform operations relating to
determining the color of the pixel through which the ray
passed.
[0033] FIG. 2 illustrates a network of multiple core processing
elements 200, according to one embodiment of the invention. FIG. 2
also illustrates one embodiment of the invention where the threads
of one of the BTEs of the multiple core processing element 100 is a
workload manager 205. Each multiple core processing element
220.sub.1-N in the network of multiple core processing elements 200
may contain one workload manager 205.sub.1-N, according to one
embodiment of the invention. Each processor 220 in the network of
multiple core processing elements 200 may also contain a plurality
of vector throughput engines 210, according to one embodiment of
the invention.
[0034] The workload managers 220.sub.1-N may use a high speed bus
225 to communicate with other workload managers 220.sub.1-N and/or
vector throughput engines 210 of other multiple core processing
elements 220, according to one embodiment of the invention. Each of
the vector throughput engines 210 may use the high speed bus 225 to
communicate with other vector throughput engines 210 or the
workload managers 205. The workload manager processors 205 may use
the high speed bus 225 to collect and distribute image processing
related tasks to other workload manager processors 205, and/or
distribute tasks to other vector throughput engines 210. The use of
a high speed bus 225 may allow the workload managers 205.sub.1-N to
communicate without affecting the caches 230 with data packets
related to workload manager 205 communications.
An Exemplary Three Dimensional Scene
[0035] FIG. 3 is an exemplary three dimensional scene 305 to be
rendered by an image processing system. Within the three
dimensional scene 305 may be objects 320. The objects 320 in FIG. 3
are of different geometric shapes. Although only four objects 320
are illustrated in FIG. 3, the number of objects in a typical three
dimensional scene may be more or less. Commonly, three dimensional
scenes will have many more objects than illustrated in FIG. 3.
[0036] As can be seen in FIG. 3 the objects are of varying
geometric shape and size. For example, one object in FIG. 3 is a
pyramid 320.sub.A. Other objects in FIG. 3 are boxes 320.sub.B-D.
In many modern image processing systems objects are often broken up
into smaller geometric shapes (e.g., squares, circles, triangles,
etc.). The larger objects are then represented by a number of the
smaller simple geometric shapes. These smaller geometric shapes are
often referred to as primitives.
[0037] Also illustrated in the scene 305 are light sources
325.sub.A-B. The light sources may illuminate the objects 320
located within the scene 305. Furthermore, depending on the
location of the light sources 325 and the objects 320 within the
scene 305, the light sources may cause shadows to be cast onto
objects within the scene 305.
[0038] The three dimensional scene 305 may be rendered into a
two-dimensional picture by an image processing system. The image
processing system may also cause the two-dimensional picture to be
displayed on a monitor 310. The monitor 310 may use many pixels 330
of different colors to render the final two-dimensional
picture.
[0039] One method used by image processing systems to rendering a
three-dimensional scene 320 into a two dimensional picture is
called ray tracing. Ray tracing is accomplished by the image
processing system "issuing" or "shooting" rays from the perspective
of a viewer 315 into the three-dimensional scene 320. The rays have
properties and behavior similar to light rays.
[0040] One ray 340, that originates at the position of the viewer
315 and traverses through the three-dimensional scene 305, can be
seen in FIG. 3. As the ray 340 traverses from the viewer 315 to the
three-dimensional scene 305, the ray 340 passes through a plane
where the final two-dimensional picture will be rendered by the
image processing system. In FIG. 3 this plane is represented by the
monitor 310. The point the ray 340 passes through the plane, or
monitor 310, is represented by a pixel 335.
[0041] As briefly discussed earlier, most image processing systems
use a grid 330 of thousands (if not millions) of pixels to render
the final scene on the monitor 310. Each individual pixel may
display a different color to render the final composite
two-dimensional picture on the monitor 310. An image processing
system using a ray tracing image processing methodology to render a
two dimensional picture from a three-dimensional scene will
calculate the colors that the issued ray or rays encounters in the
three dimensional scene. The image processing scene will then
assign the colors encountered by the ray to the pixel through which
the ray passed on its way from the viewer to the three-dimensional
scene.
[0042] The number of rays issued per pixel may vary. Some pixels
may have many rays issued for a particular scene to be rendered. In
which case the final color of the pixel is determined by the each
color contribution from all of the rays that were issued for the
pixel. Other pixels may only have a single ray issued to determine
the resulting color of the pixel in the two-dimensional picture.
Some pixels may not have any rays issued by the image processing
system, in which case their color may be determined, approximated
or assigned by algorithms within the image processing system.
[0043] To determine the final color of the pixel 335 in the two
dimensional picture, the image processing system must determine if
the ray 340 intersects an object within the scene. If the ray does
not intersect an object within the scene it may be assigned a
default background color (e.g., blue or black, representing the day
or night sky). Conversely, as the ray 340 traverses through the
three dimensional scene the ray 340 may strike objects. As the rays
strike objects within the scene the color of the object may be
assigned the pixel through which the ray passes. However, the color
of the object must be determined before it is assigned to the
pixel.
[0044] Many factors may contribute to the color of the object
struck by the original ray 340. For example, light sources within
the three dimensional scene may illuminate the object. Furthermore,
physical properties of the object may contribute to the color of
the object. For example, if the object is reflective or
transparent, other non-light source objects may then contribute to
the color of the object.
[0045] In order to determine the effects from other objects within
the three dimensional scene, secondary rays may be issued from the
point where the original ray 340 intersected the object. For
example, one type of secondary ray may be a shadow ray. A shadow
ray may be used to determine the contribution of light to the point
where the original ray 340 intersected the object. Another type of
secondary ray may be a transmitted ray. A transmitted ray may be
used to determine what color or light may be transmitted through
the body of the object. Furthermore, a third type of secondary ray
may be a reflected ray. A reflected ray may be used to determine
what color or light is reflected onto the object.
[0046] As noted above, one type of secondary ray may be a shadow
ray. Each shadow ray may be traced from the point of intersection
of the original ray and the object, to a light source within the
three-dimensional scene 305. If the ray reaches the light source
without encountering another object before the ray reaches the
light source, then the light source will illuminate the object
struck by the original ray at the point where the original ray
struck the object.
[0047] For example, shadow ray 341.sub.A may be issued from the
point where original ray 340 intersected the object 320.sub.A, and
may traverse in a direction towards the light source 325.sub.A. The
shadow ray 341.sub.A reaches the light source 325.sub.A without
encountering any other objects 320 within the scene 305. Therefore,
the light source 325.sub.A will illuminate the object 320.sub.A at
the point where the original ray 340 intersected the object
320.sub.A.
[0048] Other shadow rays may have their path between the point
where the original ray struck the object and the light source
blocked by another object within the three-dimensional scene. If
the object obstructing the path between the point on the object the
original ray struck and the light source is opaque, then the light
source will not illuminate the object at the point where the
original ray struck the object. Thus, the light source may not
contribute to the color of the original ray and consequently
neither to the color of the pixel to be rendered in the
two-dimensional picture. However, if the object is translucent or
transparent, then the light source may illuminate the object at the
point where the original ray struck the object.
[0049] For example, shadow ray 341.sub.B may be issued from the
point where the original ray 340 intersected with the object
320.sub.A, and may traverse in a direction towards the light source
325.sub.B. In this example, the path of the shadow ray 341.sub.B is
blocked by an object 320.sub.D. If the object 320.sub.D is opaque,
then the light source 325.sub.B will not illuminate the object
320.sub.A at the point where the original ray 340 intersected the
object 320.sub.A. However, if the object 320.sub.D which the shadow
ray is translucent or transparent the light source 325.sub.B may
illuminate the object 320.sub.A at the point where the original ray
340 intersected the object 320.sub.A.
[0050] Another type of secondary ray is a transmitted ray. A
transmitted ray may be issued by the image processing system if the
object with which the original ray intersected has transparent or
translucent properties (e.g., glass). A transmitted ray traverses
through the object at an angle relative to the angle at which the
original ray struck the object. For example, transmitted ray 344 is
seen traversing through the object 320.sub.A which the original ray
340 intersected.
[0051] Another type of secondary ray is a reflected ray. If the
object with which the original ray intersected has reflective
properties (e.g. a metal finish), then a reflected ray will be
issued by the image processing system to determine what color or
light may be reflected by the object. Reflected rays traverse away
from the object at an angle relative to the angle at which the
original ray intersected the object. For example, reflected ray 343
may be issued by the image processing system to determine what
color or light may be reflected by the object 320.sub.A which the
original ray 340 intersected.
[0052] The total contribution of color and light of all secondary
rays (e.g., shadow rays, transmitted rays, reflected rays, etc.)
will result in the final color of the pixel through which the
original ray passed.
An Exemplary kd-Tree
[0053] One problem encountered when performing ray tracing is
determining quickly and efficiently if an issued ray intersects any
objects within the scene to be rendered. One methodology known by
those of ordinary skill in the art to make the ray intersection
determination more efficient is to use a spatial index. A spatial
index divides a three-dimensional scene or world into smaller
volumes (smaller relative to the entire three-dimensional scene)
which may or may not contain primitives. An image processing system
can then use the known boundaries of these smaller volumes to
determine if a ray may intersect primitives contained within the
smaller volumes. If a ray does intersect a volume containing
primitives, then a ray intersection test can be run using the
trajectory of the ray against the known location and dimensions of
the primitives contained within that volume. If a ray does not
intersect a particular volume then there is no need to run
ray-primitive intersection tests against the primitives contained
within that volume. Furthermore, if a ray intersects a bounding
volume which does not contain primitives then there is no need to
run ray-primitive intersections tests against that bounding volume.
Thus, by reducing the number of ray-primitive intersection tests
which may be necessary, the use of a spatial index greatly
increases the performance of a ray tracing image processing system.
Some examples of different spatial index acceleration data
structures are octrees, k dimensional Trees (kd-Trees), and binary
space partitioning trees (BSP trees). While several different
spatial index structures exist, for ease of describing embodiments
of the present invention, a kd-Tree will be used in the examples to
follow. However, those skilled in the art will readily recognize
that embodiments of the invention may be applied to any of the
different types of spatial indexes.
[0054] A kd-Tree uses axis aligned bounding volumes to partition
the entire scene or space into smaller volumes. That is, the
kd-Tree may divide a three dimensional space encompassed by a scene
through the use of splitting planes which are parallel to known
axes. The splitting planes partition a larger space into smaller
bounding volumes. Together the smaller bounding volumes make up the
entire space in the scene. The determination to partition (divide)
a larger bounding volume into two smaller bounding volumes may be
made by the image processing system through the use of a kd-tree
construction algorithm.
[0055] One criterion for determining when to partition a bounding
volume into smaller volumes may be the number of primitives
contained within the bounding volume. That is, as long as a
bounding volume contains more primitives than a predetermined
threshold, the tree construction algorithm may continue to divide
volumes by drawing more splitting planes. Another criterion for
determining when to partition a bounding volume into smaller
volumes may be the amount of space contained within the bounding
volume. Furthermore, a decision to continue partitioning the
bounding volume may also be based on how many primitives may be
intersected by the plane which creates the bounding volume.
[0056] The partitioning of the scene may be represented by a binary
tree structure made up of nodes, branches and leaves. Each internal
node within the tree may represent a relatively large bounding
volume, while the node may contain branches to sub-nodes which may
represent two relatively smaller partitioned volumes resulting
after a partitioning of the relatively large bounding volume by a
splitting plane. In an axis-aligned kd-Tree, each internal node may
contain only two branches to other nodes. The internal node may
contain branches (i.e., pointers) to one or two leaf nodes. A leaf
node is a node which is not further sub-divided into smaller
volumes and contains pointers to primitives. An internal node may
also contain branches to other internal nodes which are further
sub-divided. An internal node may also contain the information
needed to determine along what axis the splitting plane was drawn
and where along the axis the splitting plane was drawn.
Exemplary Bounding Volumes
[0057] FIGS. 4A-4C illustrate a two dimensional space to be
rendered by an image processing system and a corresponding kd-tree.
For simplicity, a two dimensional scene is used to illustrate the
building of a kd-Tree, however kd-Trees may also be used to
represent three dimensional scenes. In the two dimensional
illustration of FIGS. 4A-4C splitting lines are illustrated instead
of splitting planes, and bounding areas are illustrated instead of
bounding volumes as would be used in a three dimensional structure.
However, one skilled in the art will quickly recognize that the
concepts may easily be applied to a three dimensional scene
containing objects.
[0058] FIG. 4A illustrates a two dimensional scene 405 containing
primitives 410 to be rendered in the final picture to be displayed
on a monitor 310. The largest volume which represents the entire
volume of the scene is encompassed by bounding volume 1 (BV.sub.1).
In the corresponding kd-Tree this may be represented by the top
level node 450, also known as the root or world node. In one
embodiment of an image processing system, an image processing
system may continue to partition bounding volumes into smaller
bounding volumes when the bounding volume contains, for example,
more than two primitives. As noted earlier the decision to continue
partitioning a bounding volume into smaller bounding volumes may be
based on many factors, however for ease of explanation in this
example the decision to continue partitioning a bounding volume is
based only on the number of primitives. As can be seen in FIG. 4A,
BV.sub.1 contains six primitives, therefore kd-Tree construction
algorithm may partition BV.sub.1 into smaller bounding volumes.
[0059] FIG. 4B illustrates the same two dimensional scene 405 as
illustrated in FIG. 4A. However, in FIG. 4B the tree construction
algorithm has partitioned BV.sub.1 into two smaller bounding
volumes BV.sub.2 and BV.sub.3. The partitioning of BV.sub.1, was
accomplished, by drawing a splitting plane SP.sub.1 415 along the
x-axis at point x.sub.1. This partitioning of BV.sub.1 is also
reflected in the kd-Tree as the two nodes 455 and 460,
corresponding to BV.sub.2 and BV.sub.3 respectively, under the
internal or parent node BV.sub.1 450. The internal node
representing BV.sub.1 may now store information such as, but not
limited to, pointers to the two nodes beneath BV.sub.1 (e.g.,
BV.sub.2 and BV.sub.3), along which axis the splitting plane was
drawn (e.g., x-axis), and where along the axis the splitting plane
was drawn (e.g., at point x.sub.1).
[0060] The kd-Tree construction algorithm may continue to partition
bounding volume BV.sub.3 because it contains more than the
predetermined threshold of primitives (e.g., more than two
primitives). However, the kd-Tree construction algorithm may not
continue to partition bounding volume BV.sub.2, because bounding
volume BV.sub.2 contains less than or equal to the number of
primitives (e.g., only two primitives 410.sub.A). Nodes which are
not partitioned or sub-divided any further, such as BV.sub.2, are
referred to as leaf nodes.
[0061] FIG. 4C illustrates the same two dimensional scene 405 as
illustrated in FIG. 4B. However, in FIG. 4C the kd-Tree
construction algorithm has partitioned BV.sub.3 into two smaller
bounding volumes BV.sub.4 and BV.sub.5. The kd-construction
algorithm has partitioned BV.sub.3 using a partitioning plane along
the y-axis at point y.sub.1. Since BV.sub.3 has been partitioned
into two sub-nodes it may now be referred to as an internal node.
The partitioning of BV.sub.3 is also reflected in the kd-Tree as
the two leaf nodes 465 and 470, corresponding to BV.sub.4 and
BV.sub.5 respectively. BV.sub.4 and BV.sub.5 are leaf nodes because
the volumes they represent are not further divided into smaller
bounding volumes. The two leaf nodes, BV.sub.4 and BV.sub.5, are
located under the internal node BV.sub.3 which represents the
bounding volume which was partitioned in the kd-Tree.
[0062] The internal node representing BV.sub.3 may store
information such as, but not limited to, pointers to the two leaf
nodes (i.e., BV.sub.4 and BV.sub.5), along which axis the splitting
plane was drawn (i.e., y-axis), and where along the axis the
splitting plane was drawn (i.e., at point y.sub.1).
[0063] The kd-Tree construction algorithm may now stop partitioning
the bounding volumes because all bounding volumes located within
the scene contain less than or equal to the maximum predetermined
number of primitives which may be enclosed within a bounding
volume. The leaf nodes may contain pointers to the primitives which
are enclosed within the bounding volumes each leaf represents. For
example, leaf node BV.sub.2 may contain pointers to primitives
410.sub.A, leaf node BV.sub.4 may contain pointers to primitives
410B, and leaf node BV.sub.5 may contain pointers to primitives
410.sub.C.
[0064] A ray tracing image processing system may use the workload
manager 205 to traverse the spatial index (kd-Tree). Traversing the
kd-Tree may include selecting a branch to a node on a lower level
(sub-node) of the kd-Tree to take or proceed to in order to
determine if the ray intersects any primitives contained within the
sub-node. A workload manager 205 may use the coordinates and
trajectory of an issued ray to traverse or navigate through the
kd-Tree. By executing ray-bounding volume intersection tests, the
workload manager 205 may determine if the ray intersects a plane of
the bounding volumes represented by nodes within the kd-Tree
structure. If the ray intersects a bounding volume which contains
only primitives (i.e., a leaf node), then the workload manager 205
may send the ray and associated information to a vector throughput
engine 210 for ray-primitive intersection tests. A ray-primitive
intersection test may be executed to determine if the ray
intersects the primitives within the bounding volume. This
methodology results in fewer ray-primitive intersection tests
needed to determine if a ray intersects an object within the scene,
in comparison to running ray-primitive intersection tests for a ray
against each primitive contained within the scene.
[0065] The resulting kd-Tree structure, or other spatial index
structure, may be stored in a processor cache 230. The kd-Tree and
the size of corresponding data which comprises the kd-Tree may be
optimized for storage in a processor cache 230. The storage of the
kd-Tree in a processor cache 230 may allow a workload manager 205
to traverse the kd-Tree with a ray that has been issued by the
image processing system without having to retrieve the kd-Tree from
memory every time a ray is issued by the image processing
system.
An Exemplary kd-Tree and Corresponding Node History Data
Structure
[0066] A node history may be stored for each level of internal node
depth within the spatial index (e.g., kd-Tree). The node level
history may be used to store information relating to bounding
volume-ray intersection tests and kd-Tree traversal. By saving the
results of previous tests and kd-Tree traversal the image
processing system may take advantage of prior test results to
reduce the amount processing necessary to determine a ray-primitive
intersection. According to one embodiment of the invention, node
history bits for each level may be stored in a nibble of a node
history data structure sent along with (e.g., appended to) the
information which describes the ray.
[0067] FIG. 5 illustrates an exemplary kd-Tree 550 and a
corresponding exemplary node history data structure 545, according
to one embodiment of the invention. The exemplary kd-Tree 550 is
illustrated as containing eight levels of internal node depth
(L.sub.1-L.sub.8). According to one embodiment of the invention,
the corresponding node history 545 may contain the same number of
nibbles as the kd-Tree 550 contains internal node levels
(L.sub.1-L.sub.8). Therefore, according to one embodiment of the
invention, the node history 545 may contain eight nibbles (i.e., 32
bits) which may record the history of ray-intersection tests and
kd-Tree traversal. According to one embodiment of the invention,
the most significant nibble L.sub.1 may correspond to the first
level L.sub.1 (i.e., the root or world node) within the kd-Tree 550
and the least significant nibble L.sub.8 may correspond to the
lowest level L.sub.8 within the kd-tree 550.
[0068] Each nibble within the node history data structure 545 may
contain four bits. The two most significant bits 525 of each nibble
may correspond to a node located to the left and below an internal
node. The two least significant bits 530 of each nibble may relate
to a node located to the right and below an internal node. The most
significant bit 505 of each nibble may be set (e.g., to a high
state, or a "1") if the ray-bounding volume intersection test was
executed and the ray intersected the bounding volume represented by
the node to the left and below an internal node. The second most
significant bit 505 may be set if the workload manager 205 "took"
the branch or traversed to the node, located to the left and below
the internal node, while traversing the kd-tree. As used herein, a
path is considered "taken" if the kd-tree was traversed to reach an
internal or leaf node along the path.
[0069] The third most significant bit 515 may be set if the
ray-bounding volume intersection test was executed and the ray
intersected the bounding volume represented by the node located to
the right and below the internal node. The least significant bit
520 may be set if the workload manager 205 "took" the branch or
traversed to the node, located to the right and below the internal
node, while traversing the kd-tree 550.
[0070] Thus, one nibble of history bits per level is all that is
needed to record the results of ray-bounding volume intersection
tests and whether a path has been taken or not. Of course, to
determine which node has been reached at any particular level, the
history bits at the preceding level(s) need to be examined. Thus,
once all paths at a particular level have been taken when searching
for a leaf node with primitives that a given ray intersects, node
history bits at that level and below should be cleared and a
different path from a higher level should be taken.
An Exemplary kd-Tree Traversal Algorithm Utilizing Node History
[0071] FIG. 6 is a flowchart illustrating a method 600 for
traversing a kd-Tree. The method 600 beings at step 605 when an
image processing system issues a ray to be traced into a three
dimensional scene. The image processing system may use the workload
manager 205 to execute tasks related to traversing the kd-Tree with
an issued ray. Next, at step 610, the image processing system
starts at the root or world node. From the root node, the image
processing system may proceed to step 615 where the image
processing system may select a branch to take.
[0072] Step 615 may initiate within the image processing system a
sub-routine which traverses the kd-Tree according to node history
bits as described in greater detail below with reference to FIG.
7.
[0073] FIG. 7 is a flowchart which illustrates the method of
traversing the kd-Tree according to node history bits 500. The
method 700 begins at, step 705, when the image processing system
reaches an internal node (i.e., a node containing branches to
sub-nodes). Next, at step 710, the image processing system may
determine if there is node level history information corresponding
to the issued ray. If not, the image processing system proceeds to
step 715 where the workload manager 205 may perform ray-bounding
volume intersection tests for each of the bounding volumes
represented by the nodes branched to from the internal node
currently being traversed. Next, at step 720, the image processing
system may update the node level history bits corresponding to the
node level. Specifically, the image processing system may update
the "hit node" bits 505 and 515 which represent whether or not the
ray intersected the bounding volume corresponding to each of the
nodes branched to from the internal node. Next, the image
processing system may proceed to step 725.
[0074] At step 725 the image processing system may determine if
both bounding volumes represented by the nodes which are branched
to by the internal node were intersected by the ray. If both
bounding volumes were intersected the image processing system may
proceed to step 727 where the image processing system may select
the path to the node nearest to the origin of the ray. However, if
only one node was intersected, at step 729 the image processing
system may select the path to the node which was intersected. After
steps 727 and 729, the image processing system may proceed to step
730. At step 730 the image processing system updates the taken bit
in the node level history to reflect the path/branch selected by
the image processing system. After step 730, the image processing
system takes the selected path/branch at step 735.
[0075] If, at step 710, the image processing system determined that
the ray did have node level history information, the image
processing system may proceed to step 740. At step 740, the image
processing system may determine the lowest node depth that the
image processing system has previously determined that a bounding
volume was intersected by the ray, but the image processing system
did not take the path/branch to that bounding volume.
[0076] A ray which has stored node level history information is a
ray that the image processing system has traversed the spatial
index (e.g., the kd-Tree) with, however the ray did not intersect a
primitive within the bounding volume against which ray-primitive
intersection tests were run (i.e., a miss occurred). After a miss,
in order to determine the lowest internal node depth at which a
bounding volume was intersected but not taken, the image processing
system may specifically look for the occurrence of a `10` in a node
level history. The image processing system may look for a `10` in
either the pair which makes up the most significant two bits of the
node level history, or the pair of bits which makes up the least
significant two bits of the node level history. A `10` in either of
those two pairs represents that the bounding volume represented by
that node was intersected by the ray, but a ray primitive
intersection test has yet to be run for one of the bounding volumes
beneath that node level (i.e., that corresponding path was not
taken).
[0077] For example, at a certain level of the kd-Tree a ray may
intersect both bounding volumes represented by the sub-nodes
beneath an internal node. The image processing system may have
determined during a previous traversal of the kd-Tree that the
bounding volume represented by the sub-node to the left and below
the internal node of the kd-Tree was intersected by the ray before
the bounding volume represented by the sub-node to the right and
below the internal node. The image processing system may have taken
the sub-node on the left and a history bit may have been updated to
show such traversal.
[0078] As an example, according to one embodiment of the invention,
if each node level is represented by a nibble, the node history
bits corresponding to this internal node level would be `1110`
which can be read as: hit left node, took branch to left node, hit
right node, branch to right node not yet taken. The sub-node to the
right and below the internal node was intersected by the ray but
has not been tested for a ray-primitive intersection, as is
represented by the `10` in the internal node level history.
[0079] After determining the lowest node level history where a
bounding volume was intersected but not taken the image processing
system may proceed to step 745. At step 745 the image processing
system may clear all of the node level history bits for internal
node levels below the lowest node level where a bounding volume was
intersected but not taken level. This step ensures that as the
image processing system traverses the kd-Tree, any history
previously recorded for branches, nodes, or leaf nodes below the
point at which an incorrect traversal path decision was made does
not affect the future traversal of the kd-Tree.
[0080] Next, at step 750, the image processing system may traverse
the kd-Tree based on the node level history from the root node to
the lowest node depth at which a bounding volume was intersected
but not taken. Step 750 may ensure that the proper pointers to
internal nodes on lower levels or to leaf nodes are retrieved by
the image processing system from the cache 230. Next, at step 755,
the image processing system selects the path/branch to the node
that has not been taken by the image processing system (i.e., the
path represented by the `10` in the node history for the lowest
node level where a bounding volume was intersected but not taken).
After step 755, the image processing system proceeds to step 730.
At step 730 the image processing system updates the taken bit in
the node level history to reflect the path selected by the image
processing system. After step 730, the image processing system
takes the selected path at step 735.
[0081] After the path has been taken the image processing system
returns to method 600. The image processing system resumes the
method 600 at step 620. At step 620, the image processing system
determines whether the path taken has resulted in the image
processing system reaching a leaf node. If not, the image
processing system returns to step 615 to select a branch to
take.
[0082] However, if the workload manager 205 determined at step 620
that the path taken resulted in the workload manager 205 reaching a
leaf node, the workload manager 205 may send, via the inboxes 115
or via the network 225, the ray, the ray history data structure,
and the leaf node information (e.g., pointers to the primitives
bound by the leaf node) to a vector throughput engine 210 for
ray-primitive intersection tests.
[0083] The vector throughput engine 210 may execute the
ray-primitive tests to determine whether or not the ray which hit
the bounding volume represented by the leaf node actually hit any
of the primitives contained within the bounding volume. If the ray
did hit any of the primitives within the bounding volume, the
vector throughput engine 210 may assign a color (e.g., the color of
the primitive) to the ray. However, the vector throughput engine
210 may also determine that the ray did not hit any of the
primitives within the bounding volume.
[0084] Some time later, the vector throughput engine 210 returns
the ray and an indication of whether or not the ray hit or missed
the primitives contained within the bounding volume. The image
processing system, at step 630, may then determine if the
information returned by the vector throughput engine 210 indicates
that the ray hit a primitive, or if the information indicates that
the ray missed all of the primitives contained within the bounding
volume.
[0085] If the ray hit a primitive, the image processing system may
then assign the color returned from the vector throughput engine
210 to the pixel 335 on the monitor 310 through which the ray
passed. The image processing system may then proceed to issue
another ray to traverse the kd-Tree or perform other operations
related to rendering the two dimensional picture from the three
dimensional scene.
[0086] If the vector throughput engine 210 determined that the ray
missed the primitives contained within the bounding volume, the
workload manager 205 may return to step 610. At step 610, the
workload manager 205 may begin traversing the kd-Tree again
starting at the root node, with the ray history helping to avoid
unnecessarily re-running ray-bounding volume intersection tests, as
well as avoiding traversing the tree to paths that lead to leaf
nodes having primitives a given ray did not inersect.
kd-Tree Traversal Example
[0087] FIG. 8 illustrates an exemplary scene 800 which has been
partitioned into bounding volumes (BV.sub.1-BV.sub.5). FIG. 8 is
similar to the scene used in FIG. 4 to illustrate the building of a
kd-Tree. Also illustrated in FIG. 8 is a ray 805 issued by the
image processing system. The ray 805 may be used to traverse the
kd-Tree. The ray intersects BV.sub.2 at a first point 805 and exits
BV.sub.2 at a second point 815. The ray intersects BV.sub.3 and
BV.sub.4 at the second point 815 and exits BV.sub.3 and BV.sub.4 at
a third point 820.
[0088] FIG. 9A is an exemplary kd-Tree 900 corresponding to the
partitioned scene 800 in FIG. 8. FIG. 9A also illustrates a first
nibble 905 of an exemplary internal node history data structure
associated with the ray 805 and the first level of the kd-Tree 900
(i.e., the root node BV.sub.1). Furthermore, also illustrated is a
second nibble 910 of the exemplary internal node history data
structure associated with the ray 805 and the second level of the
kd-Tree. FIG. 9A illustrates the initial state (all bits
unasserted) of the node history data structure before the workload
manager 205 has begun traversing the kd-Tree with the ray 805.
[0089] As described with respect to method 500 in FIG. 5, the
workload manager 205 may perform operations related to traversing
the kd-Tree 900 after a ray 805 has been issued by the image
processing system. For example, as was described in step 615 of
method 600, the workload manager 205 may execute ray-bounding
volume intersection tests to determine if the ray 805 intersects
the bounding volumes corresponding to the child nodes, BV.sub.2 and
BV.sub.3, of the root node BV.sub.1. As can be seen in FIG. 8, the
ray 805 intersects both of the bounding volumes corresponding to
the child nodes, BV.sub.2 and BV.sub.3. The ray 805 intersects
BV.sub.2 at a first point 810, and exits BV.sub.2 at a second point
815. The ray intersects BV.sub.3 at the second point 815 and exits
BV.sub.3 at a third point 820.
[0090] After the workload manager 205 has executed the ray-bounding
volume intersection tests, the workload manager 205 may update the
node history nibble 905 corresponding to the root node BV.sub.1
level to reflect the results of the ray-bounding volume
intersection test. The updating of the root node level history
nibble 905 is illustrated in FIG. 9B. Due to the fact that the ray
805 intersects both of the child nodes, BV.sub.2 and BV.sub.3, the
workload manager 205 may assert the "hit node" bits in the node
level history which correspond to each of the child nodes, BV.sub.2
and BV.sub.3. Therefore, the workload manager 205 may assert the
most significant bit of the root node level history 905, which
represents that the ray 805 hit the bounding volume corresponding
to the left child node (BV.sub.2). Furthermore, the workload
manager 205 may assert the third most significant bit of the root
node level history 905, which represents that the ray 805 hit the
bounding volume corresponding to the right child node
(BV.sub.3).
[0091] Next, the workload manager 205 may determine a path to be
taken down the kd-Tree 900 based on the bounding volume
intersection tests. As illustrated in FIG. 9C, in one embodiment of
the invention, if both child nodes, BV.sub.2 and BV.sub.3, of the
parent node BV.sub.1, in this case the root node, the workload
manager 205 may proceed to the first (e.g., nearest) bounding
volume which was intersected by the ray. In the immediate example,
the ray 805 first intersects BV.sub.2. Therefore, the workload
manager 205 may traverse to BV.sub.2 and update the root node level
history 905 to show the workload manager 205 "took" the branch to
BV.sub.2 (i.e., took left node). The updating of the node level
history for the root node is illustrated in FIG. 9C.
[0092] The workload manager 205 may now determine whether or not
the BV.sub.2 is a leaf node (i.e., a node that does not branch to
other nodes). Since the node BV.sub.2 is a leaf node, the workload
manager 205 may now send the ray 805, the node history 905 and 910
for the ray, and pointers to the primitives contained within the
leaf node BV.sub.2 to the vector throughput engine 210 as
illustrated in FIG. 9D. The vector throughput engine 210 may then
execute ray-primitive intersection tests to determine if the ray
805 intersects (hits) any primitives contained within BV.sub.2.
[0093] As illustrated in FIG. 8, the ray 805 does not intersect any
primitives located within BV.sub.2. Therefore, the vector
throughput engine 210 may return the ray and the corresponding
history to the workload manager 205 indicating that the ray 805 did
not intersect any primitives within BV.sub.2 (i.e., a miss).
[0094] After the ray is returned from the vector throughput engine
210, the workload manager 205 may determine that the ray node level
history contains information. The workload manager 205 may utilize
the history to facilitate traversal of the kd-Tree. The workload
manager 205 may utilize the ray history to determine the lowest
level node history indicating where a bounding volume was
intersected but a corresponding branch was not taken. This may be
accomplished by determining the lowest node history which contains
a `10` in the node history. Thus, as illustrated in FIG. 9E, the
workload manager 205 may determine that the root node level of the
kd-Tree is the lowest level on the kd-Tree where a bounding volume
was intersected but not taken. This may be determined by examining
the root node level history 905 which contains a `10` indicating a
hit in a bounding volume corresponding to the right branch, but
that the right branch was not taken. After determining that the
root node level was the lowest level, the workload manager 205 may
clear the node level history for all node levels below the root
node.
[0095] Next, the workload manager 205 may begin traversing the
kd-Tree 900 at the root node BV.sub.1. The workload manager 205 may
then use the node level history 905 to aid in traversal of the
kd-tree 900. Based on the node level history 905 for the root node,
the workload manager may determine to take the branch that has yet
to be taken. By examining the node level history 905, the workload
manager may determine that both the left and the right node were
intersected by the ray 805. This may be determined by examining the
first and the third bits of the root node level history nibble 905.
Both of these bits are asserted (i.e., a `1`), and therefore both
were determined to have been intersected in a previous ray-bounding
volume intersection test. Furthermore, the workload manager 205 may
determine that the workload manager previously "took" the branch to
the left sub-node (i.e., sent the ray to be tested against the
primitives contained within BV.sub.2). This is determined by
examining the second bit of the node level history, which is
asserted. Therefore, the workload manager may not proceed to or
"take" the other branch to the right node (i.e., BV.sub.3) which
was intersected by the ray 805. As illustrated in FIG. 9F, the
workload manager 205 may also update the took right bit of the root
node level history nibble 905 to indicate the traversal to
BV.sub.3.
[0096] The workload manager 205 may determine if the traversed to
node BV.sub.3 is a leaf node. As can be seen in FIG. 9E, the node
BV.sub.3 is not a leaf node, but an internal node. Therefore, the
workload manager 205 may execute ray-bounding volume intersection
tests to determine if the ray 805 intersects the bounding volumes
corresponding to the nodes beneath or on a lower level than
BV.sub.3 (i.e., BV.sub.4 and BV.sub.5).
[0097] As illustrated in FIG. 8 the ray 805 intersects BV.sub.4 at
point 815, however the ray does not intersect BV.sub.5. Therefore,
the results of the ray-bounding volume intersection test may
indicate that the ray 805 does not intersect BV5. The workload
manager 205 may now update the BV.sub.3 node level history 910 to
reflect the results of the ray-bounding volume intersection tests.
Therefore, as illustrated in FIG. 9F, the workload manager 205 may
place a "1," or assert the bit, in the most significant bit
location within the BV.sub.3 node history 910 to reflect the fact
that the ray intersects BV.sub.3. Next, the workload manager 205
may determine what branch/path "to take," based on the BV.sub.3
node level history 910.
[0098] By examining the BV.sub.3 node level history 910 the
workload manager 205 may determine that only one node beneath
BV.sub.3 is intersected by the ray 805, and therefore the workload
manager 205 may traverse to the intersected node BV.sub.4. As
illustrated in FIG. 9G, the workload manager 205 may update the
BV.sub.3 node level history 910 to reflect the traversal from node
BV.sub.3 to node BV.sub.4 by asserting the second most significant
bit (indicating left branch taken) in the BV.sub.3 node level
history.
[0099] The workload manager 205 may now determine whether or not
the left child node, BV.sub.4 is a leaf node (i.e., the node does
not have children). Since the node BV.sub.4 is a leaf node, the
workload manager 205 may now send the ray 805, the node level
history (905 and 910) for the ray, and pointers to the primitives
contained within the leaf node BV.sub.4 to the vector throughput
engine 210. The vector throughput engine 210 may then execute
ray-primitive intersection tests to determine if the ray 805
intersects (hits) any primitives contained within BV.sub.4. As can
be seen in FIG. 8, the ray 805 intersects a primitive within
BV.sub.4. Therefore, the vector throughput engine 210 may assign a
color to the pixel through which the ray 805 passed and return the
information to the workload manager 205.
[0100] Those skilled in the art will appreciate that when a ray
does intersect with a primitive of a leaf node, additional rays may
be spawned, for example, corresponding to reflection, transmission,
refraction, and the like. While the iterative process of spawning
such rays is well known, each of these rays may be efficiently
traced using the techniques described herein to determine final
pixel values.
CONCLUSION
[0101] Embodiments of the invention provide techniques and systems
for recording the traversal history of a ray through a spatial
index structure and utilizing the recorded traversal history of a
ray through the spatial index. An image processing system may
initially determine which nodes a ray intersects as it traverses
through a spatial index. Results of the node intersection
determinations may be recorded as the ray traverses the spatial
index, and the recorded determinations may be associated with the
ray. Furthermore, the image processing system may decide upon a
traversal path based upon some probability of striking primitives
corresponding to the nodes which make up the spatial index. This
traversal path may also be recorded and associated with the ray. If
the image processing system needs to traverse the spatial index at
a later time, the recorded traversal history may be used to
eliminate the need to recalculate ray-node intersections, and
eliminate duplicating incorrect traversal path determinations.
[0102] While the foregoing is directed to embodiments of the
present invention, other and further embodiments of the invention
may be devised without departing from the basic scope thereof, and
the scope thereof is determined by the claims that follow.
* * * * *