CN110458933B - Methods, systems, and computer readable media for tracking rays within a 3D scene - Google Patents

Abstract

Embodiments of the present disclosure relate to methods, systems, and computer readable media for tracking rays within a 3D scene. Aspects relate to tracking light in a 3D scene that includes objects defined by or with implicit geometries. In an example, the trap element defines a portion of 3D space in which implicit geometry exists. When a ray is found to intersect a trap element, a trap element program is executed. The trap element program may include advancing a ray through a 3D volume and evaluating a function defining the implicit geometry for each current 3D position of the ray. The detected intersections with the implicit geometry may be found in parallel with multiple intersections with explicitly defined geometry for the same ray, and data describing these intersections with the ray may be stored and solved.

Description

Methods, systems, and computer readable media for tracking rays within a 3D scene

The present application is a divisional application of the invention patent application with application date 2014, 3-month 11, application number 201410087919.9 and the invention name "3D graphics rendering with implicit geometry".

Technical Field

The following relates to ray tracing and, in particular applications, to ray tracing of computer graphics using displaced geometry.

Background

Rendering realistic 2D images from 3D scene descriptions with ray tracing is well known in the art of computer graphics. Ray tracing generally involves obtaining a scene description consisting of geometric shapes that describe the curved surfaces of structures in the scene. Tracking virtual rays from a point of view ("camera") into the scene; each ray is issued to travel through the corresponding pixel of the 2D display, which ray affects that pixel. Intersection tests with the geometry are performed on the rays to identify the nearest intersection point (if any) of each ray.

These geometric shapes may be composed of multiple primitives, such as triangle primitives. The use of triangle primitive demonstration shapes provides a demonstration that can be easily consumed by some ray tracing renderers and can complete intersection testing of rays with triangles according to a variety of algorithms. However, for high quality rendering, e.g. in order to generate HD resolution images from virtual 3D scenes, such as for high quality video games or animations, a fine object model is beneficial. The use of only the fine object model defined by the triangle primitives consumes a significant amount of memory compared to other presentations. For example, a smooth surface that exposes objects using only triangle primitives will typically consume more memory than a spline-based exposure. Another example is a topographical feature of a landscape. For example, using only triangle primitives to show actual mountains can be memory intensive, as required for many fine features.

Displacement mapping is a technique that may be used to address these scenarios. Displacement mapping refers to shifting defined geometry data in one or more directions such that the geometry that is ultimately used to render the 3D scene is modified according to a displacement strategy. The present geometry can be considered as a displaced geometry. In ray tracing, rendering using displaced geometry involves intersection testing of the displaced geometry. This is in contrast to a concave-convex mapping, which involves performing intersection tests of light with the source geometry, and after identifying the intersection points, a concave-convex mapping process may be performed. Thus, the concave-convex map requires less computation of intersection tests because intersection tests with simplified source geometries are performed on rays instead of intersection tests with displaced geometries that may have more primitives. However, the concave-convex map allows a more limited set of behaviors to be achieved.

Disclosure of Invention

In one aspect, a method of intersection testing a light ray with an implicit surface includes entering the light ray into a surface of a housing surrounding a 3D volume. The housing defines a maximum extent of the implicitly defined geometry within the housing. The method includes iteratively stepping a current 3D position of the ray through a 3D volume defined by the shell along a path of the ray. For each current 3D position, the current 3D position of the ray is projected onto the current 2D position on the explicitly defined surface enclosed by the shell, and the current 2D position on the explicitly defined surface is used to generate data of an implicitly defined geometry at the current 3D position. The generated data is used to characterize the ray as either impinging or missing an implicitly defined geometry at the current 3D position. The ray data structure may store data generated for the detected intersection with the implicitly defined geometry. The intersection may first be expressed in a reference coordinate system and converted to an overall coordinate system for comparison with other detected intersections.

The enclosure element may enclose the housing. The bounding element may be identified with a marker that indicates that the bounding element should be traversed using implicit geometry intersections. The step size of the steps may be different. The step size may be set based on a light differential or a level of detail indication. A set of volume-excluding elements may be defined within the surrounding element, each volume-excluding element excluding a portion of the 3D volume between the surrounding element and the range of the implicit geometry. The set of volume excluding elements may be defined during the execution step and stored in association with an acceleration structure for the 3D scene. These are example aspects included in the following detailed description.

Drawings

FIG. 1 depicts examples of explicitly defined geometry elements associated with artist-provided vectors used in a method of intersection testing a ray of light with an implicitly defined surface;

FIG. 2 depicts a shell defined based on vectors provided by an artist according to FIG. 1;

FIG. 3 depicts an example process of traversing a ray through a 3D scene using explicit and implicit geometry definitions;

FIG. 4 depicts an example method of traversing a ray through a 3D volume that may contain implicitly defined geometry;

FIG. 5 depicts an acceleration structure with surrounding elements and trapping elements;

fig. 6 depicts an example housing surrounded by a trapping element;

FIG. 7A depicts a sub-volume of the example housing of FIG. 6;

FIG. 7B depicts a bilinear patch that may be used to define a sub-volume of the example housing;

FIG. 8 depicts a set of shapes that may be used to define a sub-volume of the example housing;

FIG. 9 depicts an example of traversing a sub-volume and projecting a current 3D position of a ray onto a 2D position in order to determine one or more implicit geometric features;

FIG. 10 depicts an example of a final geometry surface surrounding an implicit definition within an element;

FIG. 11 depicts an example of a volume exclusion element formed within the surrounding element based on the final geometry surface of FIG. 10;

FIG. 12 depicts a case where an instance of a geometry is enclosed within a trap element

FIG. 13 depicts a pre-execution process of a geometry program or other evaluation of implicit geometry definition data to determine the extent of the final geometry;

FIG. 14 depicts a process of intersection testing within surrounding elements that overlap in 3D space;

FIG. 15 depicts a trap element setup and conversion process;

FIG. 16 depicts an example system in which the disclosed aspects may be implemented;

FIG. 17 depicts an example of a bounded function circuit that may be included within a system implementation in accordance with FIG. 16;

FIG. 18 depicts an example process in which intersection disambiguation of parallel intersection tests of multiple portions of a ray path may be performed;

FIG. 19 depicts an example operation of a throughput computing unit; and

fig. 20 depicts an example of implementing quality of service aware throughput computation.

Detailed Description

Vector displacement may be used to implement the displaced geometry. Vector displacement allows any vector or vectors to control the displacement of elements of the scene geometry or a portion thereof. In some implementations, vector displacement allows any element of the geometry to be shifted entirely arbitrarily. For example, elements of the geometry may be shifted by any magnitude in any direction. Vector displacement thus provides a high degree of control over displacement, but presents a difficult rendering task.

In some aspects herein, displacement is implicitly limited to a limit that is set based on one or more predefined vectors, in which limit a maximum displacement may be set for those vectors. In one example approach, the vector provided by the artist may be associated with a vertex defining the source geometry. An artist may be any person, machine, or process that generates a vector. The term is used to distinguish these vectors from other vectors that may be associated with the source geometry, such as normals that may be associated with vertices and primitives of the source geometry. For any point on a 2D surface, the displacement may be limited to a vector determined along two or more vectors provided by interpolation of an artist associated with the 2D surface. Thus, a fully generic displacement may be limited to the analysis result determined by the interpolated vector and the maximum displacement limit.

To determine a displacement geometry based on a given element of the source geometry, vectors provided by an artist for two or more vertices defining the element of the source geometry may be used to control how or otherwise define limits of possible displacements for specific locations on the element of the source geometry. The source geometry may be shifted according to a certain procedure and according to the determined control vector. The displacement geometry may then be used in ray intersection testing, and optionally for other purposes.

Some aspects of the present disclosure relate to exemplary systems and processes by which source geometry may be shifted and techniques that may be used in intersection testing of shift geometry.

Fig. 1 depicts a triangle primitive 10 associated with a geometric normal (which in turn may be defined by the vertices forming the winding order of the primitive and the locations of those vertices in space (the locations of which establish a plane with a normal direction and which direction the normal points are conventionally along), hi fig. 1, the vertices forming the primitive 10 are also associated with artist-provided vectors 13-15. Here, "artist-provided" refers to the concept that these vectors need not define the surface or location of the primitive 10 or its relationship to other primitives (such as a primitive grid).

Fig. 2 depicts primitive mesh 18 (e.g., the cross-section of the primitive mesh roughly defines a sphere). The primitive 10 is identified along with vectors 14 and 15 provided by the artist. An interpolated vector 16 is shown between vectors 14 and 15 provided by these artists. The vectors provided by the artist of the primitive forming the sphere are used to collectively define a shell 20. The housing 20 is depicted as a smooth shape; however, the shell 20 will be faceted to a determinable extent by whether and to what extent each of the original primitives is subdivided. In one example, the primitives are not subdivided, and the shell 20 will have one facet for each original primitive. In other examples, each primitive will have a corresponding plurality of facets within the housing 20. The housing according to the example housing 20 may be used to facilitate ray tracing implicitly defined geometries in accordance with the disclosure below. The displacement geometry provides an example of an implicit geometry according to the present disclosure. Herein, implicit geometry includes a method of storing a set of geometry data prior to being used in some way to generate a "run time" between final geometry surfaces. In one example, a function may be associated with primitive 10 and may be evaluated based on one or more inputs generated during runtime to evaluate the presence of a final geometry within a particular volume or at a point within 3D space.

FIG. 3 depicts an overview of how rays are tracked within a 3D scene having implicitly defined and explicitly defined geometry. At step 302, it is determined to track one or more rays through a volume within the 3D space. Such a volume may be the whole or a part of the 3D scene. This determination may be implemented, for example, by emitting light during the rendering of the image. At step 205, such one or more rays begin (or continue) traversing the acceleration structure. The acceleration structure includes a graph of a plurality of elements, each element surrounding a corresponding portion of the 3D scene. Traversal of the graph allows for the identification of a final subset of the geometry for which the intersection test(s) of the ray(s) is (are) performed. In some implementations, this traversal is not performed in the order in which the rays travel in the scene. For example, breadth first testing may be performed on each ray, the rays may be grouped and regrouped for testing according to criteria, and traversal of the rays issued together may not begin together. Thus, in typical usage, a given ray may have candidate intersections that are not identified in distance order, and such intersections should be further processed to ultimately identify the closest intersection for the ray.

At 207, the traversal causes one or more elements of the ray to be identified and thus requires further processing to determine whether there is an intersection of each such ray. At 209, it is determined whether the element is a trap element. The trap element may have the same shape as other acceleration structure elements, but may be associated with a marker indicating its state as a trap element. Fig. 5 depicts an acceleration structure with both non-trapped elements (e.g., surrounding elements 303, 305, 307, 315, and 316) and trapped elements 309-313. Each of these elements is displayed with one connection to at least one other element and will be located within the 3D space. Some implementations may have a single type of trap element; other implementations may have multiple trap element types. Such an implementation may have multiple bits allocated to indicate the type of trap element. In some examples, indicating that the element is a trap element causes execution of the trap element program 211. When an implementation includes multiple types of trap elements, a different trap element program may be executed for each type. The trap elements may also be stored in separate acceleration structures that may be traversed separately/additionally from a surrounding explicitly defined geometry. Here, the trap element type relates to what procedure or different calculation protocol should be followed when entering the trap element. For example, the mousetrap element may be provided to evaluate with a non-uniform rational B-spline (NURBS) surface or subdivision surface to determine a level of detail (LOD), perform motion blur calculations, and so forth. As will be explained further below, the acceleration structure may comprise a plurality of elements for different purposes. For example, trap elements 309-311 may enclose a presentation of different levels of detail for the same geometry. As explained below, some aspects of the present disclosure provide tester circuitry that can selectively traverse acceleration structures (such as without intervention of a general purpose programmable computing unit or program that emits traversed rays).

If the element is not a mousetrap element, then at 215 it is determined if the element directly surrounds the geometry (e.g., it is a leaf node in a homogeneous acceleration structure). If not, at 205, traversal of the subsequent element (e.g., sub-elements of the previously identified element) continues. The reference count is updated (233) as explained below. If there is a directly enclosed geometry, then at 217, the geometry is subjected to an intersection test with the ray or rays, and at 219, the results of such a test are output. The results of the intersection test may include an identifier for the intersection of the primitive with each or every plurality of rays, a distance to the intersection, parametric coordinates determined for the intersecting surface, some combination thereof, or other data and combinations thereof.

In using the trap element, completing the traversal of the ray thoroughly may involve creating a plurality of different ray segments, each ray segment defined by a corresponding different ray data structure. The reference count may be maintained within each trap element and also across all ray segments used to thoroughly track a given ray (e.g., rays that may have different origins and/or endpoints along the ray's path). For example, the trapping element may have an acceleration structure separate from the main acceleration structure of the 3D scene, the light line segment may be located within several elements within the acceleration structure; after solving the reference count for the trap element, the ray segment may be completed, but the entire ray (of which the ray segment is a part) may not be completed.

Since other intersections of each ray have been identified, at 221, the intersection or intersections for each ray trace may be updated. For example, if an intersection that is closer than the previously identified nearest intersection is identified, the new nearest intersection is maintained to support (in far of) the previous intersection. At 223, one or more reference counts for each of the rays are updated according to the traversal. In particular, a count may be maintained for each ray that tracks how many acceleration structure elements currently exist rays (where multiple segments are used for one ray, then the distributed reference count may be maintained and eventually solved). For example, when a ray-to-element test is completed, the count is decremented, but if the ray is indicated for a test for a child element, the count is incremented. A count of zero is reached indicating that the ray has completed traversal (although testing of the ray with all geometries may not have been completed, depending on the implementation).

Returning to 209 and 211, the trap element may be used to indicate that there is an implicitly defined geometry within the 3D volume enclosed by the trap element. Various process and system aspects are disclosed with respect to the following figures of fig. 3. With respect to the remainder of FIG. 3, the output of the trap element program may include an indication of the nearest intersection of the ray with the geometry (implicit or explicit); this defines the maximum distance that the ray needs to be traced when the nearest intersection point is desired. As explained below, the ray may also be associated with minimum distance information, which may be used to exclude acceleration structural elements or geometries. These intersections are eventually fed into the process portion 213. If the intersection test is complete at 218, one or more intersections may be identified for shading at 225 and shading program code may be executed at 227. In some implementations, more than one intersection value may be provided for a single intersection, and at 229 one of these values may be selected for use as the origin of the sub-ray emission occurring at 231. For example, as explained below, different intersection values may be selected for reflected light rays rather than refracted light rays.

FIG. 4 depicts a first example of a process for identifying intersections between rays and implicit geometries. In one example, intersecting trapping elements are found to surround a housing (and source geometry for the housing) as disclosed with respect to fig. 1 and 2. At 245, the intersection point between each ray or rays and the surface of the housing is found. Such that after determining that the light ray or rays are about to enter the trapping element, the light ray or rays may be projected onto the curved surface of the housing at one or more points.

Fig. 6 depicts a trapping element 534 surrounding the faceted shell 323. The facet housing 323 may be formed by highlighting the set of primitives along a direction defined by a vector (fig. 1 and 2) provided by an artist. For example, the primitives 332 may be highlighted to define the segment 324 of the shell 323. Thus, in one approach, there is a 1:1 correspondence between the facets of the shell and the original primitives of the source geometry. Fig. 7A depicts a segment 324 as composed of a collection of primitives 332 of a source geometry and bilinear patches connecting the primitives 332 to a facet 325. For example, as shown in fig. 7B, bilinear patch 350 connects vertices 355 and 356 of primitive 332 to vertices 358 and 359 of facet 325, respectively. The use of bilinear patches to define the edges of each segment allows the segments to be non-parallel to each other by allowing the edges of the segments to be non-parallel to each other. Fig. 8 depicts an alternative configuration of the segments of the housing. In the example of FIG. 8, a set of bounding shapes 365-367 (e.g., tetrahedrons) are provided that collectively define the segment.

Fig. 6 also depicts that an inlet 330 of a section of the housing 323 may be tracked, which corresponds to an outlet point 331. Segment 324 has an entry point 339 and an exit point 340. In some cases, a ray may enter the housing but not leave the housing where it will first intersect the source geometry primitive. Any of these entry points (including the first entry point of the housing) and each segment entered may be considered an entry point or intersection with the housing curved surface. With respect to the entry point of each segment of the shell, tracking as light enters a different segment of the shell allows a particular geometry procedure to be associated with each primitive and executed to evaluate the implicit geometry within that segment of the shell.

Returning to fig. 4, the rays then step through the volume enclosed by the housing to establish a current 3D position for each ray. The step has a certain spacing (epsilon). At 239, ε may be set. Epsilon may be set, for example, based on various inputs, such as level of detail indicator 235 or light differential 237. Epsilon may be fixed or variable; fig. 4 includes a description of a variable epsilon implementation. For the remainder of fig. 4, a single ray is depicted, although multiple rays may be processed in parallel. At 247, the light is stepped. At 248, it is determined whether the ray is at a curved surface of a volume excluding element within the housing. The volume excluding element defines a sub-portion of the space within the housing within which no implicit geometry will exist. With respect to fig. 10 and 11, a further description of the volume excluding elements is provided. Briefly, the volume exclusion element may be identified by determining a final extent of the implicit geometry within the shell and then defining a set of bounding volumes enclosing a spatial region without geometry. The sizes of the bounding volumes may be different in order to fit within different portions of the final range of the implicit geometry.

If the ray has entered the volume excluding element, then at 249, an exit point from the volume excluding element is determined, and at 250, the current 3D position of the ray is incremented to the exit point, and the determination is performed again at 248. If the current 3D position is not within a volume exclusion element, then at 251, the current 3D position is projected onto a curved surface of the primitive, the curved surface being projected to define that portion of the shell. An example of such projection is depicted in fig. 9. Fig. 9 depicts stepping ray 335 multiple times along the ray's direction of travel (to identify current 3D locations 405) and identifying a corresponding 2D location 406 on primitive 332 for each current 3D location. Each of these 2D locations may be expressed, for example, as a parametric coordinate pair, or using barycentric coordinates. These 2D locations may be used as inputs to a program geometry shading program 410 that executes to generate implicit geometry features (collectively indicated at 415 in fig. 9) for each of these 2D locations. As explained with respect to fig. 3, the step size may be set based on the level of detail indicator for each ray. The light differentiation can also be used as an input to set the step size.

Setting the step size is one way to adjust the amount of computation used in the light ray advancing process. In a sense, the amount of computation may be adjusted based on the level of detail desired for a given implicit geometry rendering. However, in other cases, the total amount of computation may be reduced by finding the intersection region between larger steps and then refining the intersection. In some implementations, the regions of the 3D location can be aligned (snap) to the same 2D location based on a level of detail or light differentiation. For example, even if the step size is set to one size, several steps of the ray may be aligned to evaluate based on the same function. In another example, a larger step may be taken and one or more intermediate steps may be interpolated from the end of the step. For example, when the level of detail is low, a larger step may be taken, a larger region of the 2D surface may all evaluate to the same function value, or an interpolated value may be taken for an intermediate value, or some combination of these options.

In one example, these 2D locations may also be used as inputs to a function that outputs the height of the implicit geometry for the 2D location. Here, the height may refer to a distance along the path; such a path may be a line segment. The line segment may be defined by interpolating vectors defined by the artist (see fig. 1 and 2). In other examples, the path may be defined by a function or program associated with the source primitive or a portion thereof. When an implementation shifts along a line segment, an intersection may be detected by comparing the current height of the ray above the surface within 3D space with the height generated by the implicit geometric function being evaluated for the 2D location. In one example, such comparison may include subtraction. When the result of the subtraction changes sign, then the following can be concluded: the ray has intersected the implicit geometry somewhere between the previous and current steps. These operations are examples of the operations depicted in fig. 4, including running a geometry process to determine the geometry characteristics of the projected current ray point at 253 and comparing 255. The subtraction implements overlap determination 257. If there is no overlap (e.g., the ray's height is still greater than the implicit geometry at the given point), the process returns to 269 to perform another step of the ray. If an overlap is detected (e.g., a sign change of the subtraction result), then at 259 a bisection process may be performed to further refine the intersection point. At 261, a pair of 3D locations describing the interval of the rays containing the intersection may be identified. At 263, these points may be returned as points of intersection exhibiting the ray and implicit geometry. Since a geometry that is closer than the implicit geometry of the intersection may be to be tested, it is to be determined whether this intersection is the closest intersection.

Instead of comparing the heights, collision detection algorithms may be used to compare the current 3D position to the implicit geometry. The current 3D position may be modeled as having a range of spheres or shapes. This range may be controlled by distance hierarchy information, light differentiation, or some combination thereof. In some applications, the implicit geometry in which the intersection test is performed may be derived from the volumetric dataset. For example, the volumetric dataset may be expressed as data within a uniform or hierarchical voxel structure. For example, the data may originate from 3D scanning technologies such as medical imaging scanners, such as Computed Tomography (CT) scanners, and the like.

Fig. 10 depicts a curve 430 (shown in 2D for clarity) showing the final curved surface of the implicitly defined geometry. The surrounding element 429 encloses this geometry (the housing and the trapping element, if provided). Regarding the trapping element, the size and overall dimensions of the trapping element may be affected by limitations on the form of the trapping element (e.g., axis alignment box, square, sphere, etc.). Such limitations may affect the closeness of fit that can be achieved for a given housing. Fig. 11 depicts the repulsive elements (specifically identified 431 and 432) filling the space between the final geometry 430 and the surrounding element 429. The size of these repulsive elements can also be determined and positioned according to the restrictions on the shapes that can be used for these elements. A further limitation may relate to the amount of memory dedicated to these elements. For example, a minimum size of elements may be required, or a maximum memory size may be set that is required to store data defining the rejection elements within a particular trap element. These decisions may be made based on the characteristics of the computing platform on which the stepping algorithm is to be implemented, including memory bandwidth and size characteristics, power consumption limitations, latency requirements, throughput, etc. Fig. 13 depicts an example process by which a volume excluding element may be generated. At 451, a portion of the implicit geometry is identified (e.g., programmatically defined displacement). Such identification may be done in a pre-execution environment where the source geometry may be submitted with one or more functions, one or more programs, or other definitions of how the implicit geometry is to be determined when needed (e.g., for intersection testing). At 455, these functions, procedures, etc. are optionally evaluated or executed to obtain the final geometry range. In some cases, such final geometry range will depend on information that is only available during run-time, or more generally, information that is not yet available (e.g., the evaluation depends on the value retrieved (retrievable) during the lookup operation). In this case, the source geometry, function or program may be associated with information of a range of values that may be expected from the lookup. In other implementations, an expression may be provided that describes the value returned by the lookup, and the final range of the implicit geometry may be evaluated based on the joint evaluation of the sources.

Based on this evaluation, at 457, a repulsive volume is defined within the maximum range of the final geometry and within the shell (see fig. 6). Examples of implementations of the repulsive volume include voxel structures, which may be hierarchical, such as octree. In an alternative implementation, the housing may be omitted and the repulsive volume will be defined based on the range of trapping elements that will encompass the final geometry. If the housing is omitted, it will generally be expected that a large volume of the repulsive elements will be required, as the entrapment elements will not surround the final geometry as tightly as the housing. At 459, the definitions of these exclusion volumes are stored for later access. In addition to defining the rejection volume in the pre-pass, the volume portion may be rejected based on the characteristics of the function describing the implicit geometry surface.

Fig. 12 depicts more details on how a trap element may be used for intersection testing of implicit geometry and more generally for abstracting portions of 3D space. As an additional example usage, the trap elements may be used to abstract instances of the same geometric object even though they do not use implicit geometry. Fig. 12 gives an example of a toy that is a tree of geometric objects, where instances 405-407 of the geometric objects are surrounded by corresponding trap elements 434-436. These trapping elements may in turn be surrounded by a surrounding body 420 (see fig. 5). Instance 431 is shown overlapping with instance 432. This overlap in a 3D scene may be the case where branches of these tree instances are entangled, such that they occupy overlapping volumes of space. Ray 438 is traversed in the scene. FIG. 3 depicts a process of using the trapped element program 211; fig. 15 depicts an example of a trap element program 211.

In FIG. 15, when a ray encounters a trapped element, the ray is converted to the coordinate system to which the trapped element refers in 461 in order to perform intersection tests on the ray with the geometry within the trapped element. At 463, one or more processes are performed. These processes may vary significantly based on the characteristics of the trapping element. For example, an implicit geometry procedure may be performed. Alternatively, the geometry enclosed within the trapping element may be tested. Finally, at 465, result data is generated. For example, based on the geometry tested or the procedure performed, this result data is the closest intersection point found. As a result of the intersection test within the trapped element, various data may be generated, including barycentric coordinates, distances to the intersection point, points within 3D space identifying the intersection point, or another expression of the intersection point location.

When this data contains positional information, it may be expressed in the coordinate system to which the trapping element refers. At 467, the location information and associated information are converted from the reference coordinate system to an overall coordinate system (or another coordinate common to other operations to be performed). Such a conversion may be performed immediately, but in another implementation a conversion matrix may be provided that will allow the conversion to be validated at a later time. For example, the result data structure may contain the result data within the reference coordinate system and the transformation matrix. The transformation matrix may be applied to the resulting data later in the course of an intersection disambiguation or classification process. This implementation may be suitable when the functional unit performing the intersection test may not have the ability to perform matrix transformations or may not be able to perform such transformations efficiently. If the trapping element is not referenced to a coordinate system other than the global coordinate system, a transformation matrix may not be required.

Returning to fig. 12, in this figure, light rays originate within both trap element 434 and trap element 435. In some systems according to the present disclosure, it may be the case that: before determining that ray 438 also intersects trap element 434 (and/or geometry within 434), it is found that trap element 435 (and/or geometry within 435) intersects ray 438 (e.g., if each ray begins testing at the root of the hierarchical acceleration structure, ray 438 would first access trap element 435). This may occur due to the latency of some intersecting tests or the delay propagation of intermediate results of the tests, or simply based on how the test is planned, for example. Thus, instance 432 may be evaluated for intersection prior to instance 431, even though the portions of instance 431 are closer to the origin of ray 438. FIG. 14 depicts an example method of intersection testing to explain these cases.

Fig. 14 depicts the results of the test against the implicit geometry generated at 411 and the results of the test against the implicit geometry for the same ray generated at 413. In the process of FIG. 14, there are multiple intersection results available for a given ray. More generally, it may be desirable to maintain a single nearest intersection point of a ray and identify the intersection result of the ray each time, compare it to the nearest intersection point, and maintain the single nearest intersection point. Here, however, at the resolution at which these results are expressed (e.g., single precision floating point), a simple distance evaluation may not be sufficient to immediately distinguish which intersection point is nearest, or in other cases, there may be two intersection points with indistinguishable distances from each other. In these cases, a method of providing reproducible results may be important even if there is more than one "effective" solution. In the case of an accelerating structural element (trapped or regular), if any portion of the volume of the element overlaps with the range defined by the minimum distance and the current nearest intersection point, the accelerating element will not be rejected into the nearest intersection point (i.e., maximum t) for testing (accelerating structural element does not establish a ray).

Fig. 14 depicts a determination at 415 that any two or more of the plurality of intersection results are at an indistinguishable distance. In the present case, there may be some geometrical intersections that are evaluated that are clearly not the nearest geometrical intersection. These intersections can be excluded; if they were performed prior to the process of FIG. 14, the determination 415 may be ignored for those intersections, but the overlapping acceleration structure elements would still need to be identified or maintained for testing. If all geometric body phase results are at different intersection distances, then the nearest intersection point (set of intersection points) may be used (where a set of intersection points may be a pair of points returned, for example, by demarcating the intersection of a ray with a curved surface, as the result of the ray advancing back discussed with respect to FIG. 9).

At 419, the ID of each object (e.g., acceleration structure element or primitive) having an indifferent distance from the comparison object is accessed. Based on the IDs of these objects, one or more objects may be rejected, or selected, from further processing. At 423, intersection information for the ray is updated based on 421. At 425, the reference count for the ray is updated. If indicated previously for a test, the reference count of the ray is increased when the reference count of the ray is added for a test that accelerates a structural element, and is decreased when the element is purged or when it is rejected from the test.

Considering 421 in more detail, if the identifier of the acceleration structure element indicates that it has entered for testing, the acceleration structure element may be excluded from further processing. This may be determined by comparing at least a portion of the identifier of the acceleration structure element with stored or associated identifier information for the ray. Such information stored with the ray may include the identifier of the acceleration structure element having the highest value in the sequence of identifiers that have been entered for the ray (e.g., all of the identifiers have a relative order, and the ray maintains the identity of the highest order element). One particular example may be considered with respect to ray 440. It can be seen that ray 440 first enters trap element 434. When the trap element is entered, a minimum value t will be established for the trap element. Ray 440 also intersects trap element 435, but at a different distance from the intersection with trap element 434. However, this is also the case when the intersection with trap element 435 remains within the volume of trap element 434. Thus, in this case, the trap element 434 may be re-entered or processed. In one approach, the minimum value t can be used to exclude from retesting geometries surrounded by surrounding elements that do not overlap with another element.

Instances of the same geometry may be spread throughout the 3D scene, with each instance enclosed by a different trapping element. Each trap element includes a world space coordinate location (and/or range). Each trap element may be different in size and may be oriented differently. For example, the trapping element may be scaled and rotated. Each instance space may use a reference coordinate system. Each trap element may also include information about a transformation to be applied on the light for translating between world space and the reference coordinate system of the instance. As explained above, each mousetrap element may also include references to objects or other data within the mousetrap element, e.g., implicit geometry and other data. In another example, each element of the acceleration structure may have an identifier, and the acceleration structure elements exhibiting the same geometry in which the trapping element encapsulates may have a number of bits in common. Rays intersecting these different instance elements may be collected and together they may begin intersection testing. When each trap element has a reference to an instance space, then the reference can be used to collect rays that would require testing of the referenced instance space. When elements referencing the same instance space share a portion of an identifier, the identifier portion may be used to collect rays.

Fig. 16 depicts a system 501 in which aspects disclosed herein may be implemented. The system 501 includes a computing cluster 502 that may have a set of cores, each capable of executing instructions from a corresponding independent instruction stream. Each core may have a private cache and may share a secondary cache with one or more other cores; other cache configurations may be implemented. For example, cores 503 and 504 each have a dedicated L1 cache, 505 and 506, respectively. Cores 503 and 504 may share L2 cache 507. The computing cluster 502 may read from the acceleration structure memory 509 and from the geometry memory 508. Various algorithms may be executed to assist in computing cluster 502, such as the rendering algorithm of throughput computing unit 515. The computing unit 515 includes a task collector 521, a plurality of ray/primitive intersection test units 520, and a plurality of ray/box test units 516. Each of these units may be configured to perform one or more defined intersection algorithms. When the light originates from outside the box, the light/box test units 516 may be implemented such that they create a distance from the origin of the light to the intersection with the box. When the light originates within the box, light/box test units 516 may also be implemented such that they return the distance that the light travels to the exit point of the box (e.g., the distance that light 438 originates within trap element 435 and light/box test units 516 may return to exit trap element 435). The light/box test unit is an example of a test unit for a specific kind of shape. The test unit may be provided for other kinds of shapes, or in addition to or instead of the cartridge test unit.

In some examples, each test unit includes fixed function circuitry that performs at least a portion of a given intersection algorithm. Example primitive tests include intersection tests with triangle primitives, such as barycentric coordinates tests. The box being subjected to the intersection test may be, for example, an axis alignment bounding box. Other methods of accelerating the structural test include kd-Tree testing. In addition to these intersecting test units, the computing unit 515 may include a set (one or more) of limited programmability circuits 512, which may be associated with the corresponding test units or included within the task collector 521.

Each intersection test cell may use a corresponding local optical data store 514. As a specific example, ray data 518 includes a plurality of ray definition data sets. Each ray definition dataset includes a minimum distance identification (minimum value t). In one example, as explained above, the minimum distance may be used to step through a set of elements without having to test them for each step in the same process. A maximum distance identification (maximum t) may also be stored, which identifies the nearest current intersection of the ray. Data about the current nearest intersection, such as interpolated changes to the intersection, barycentric coordinates, and primitive identifiers, may be stored. In general, the stored data may be selected based on the data that is required to execute the shading program for the ray (if the intersection to which the data relates is the intersection that triggered the shading program to execute). When the intersection points relate bounding box elements (e.g., trapping elements) to a reference coordinate system, a transformation matrix describing the mapping between the whole and local coordinates may be stored.

As explained above, task collector 521 forms a computation packet (e.g., a grouping of rays that may be tested together). The ray packet may identify the acceleration structure to be tested. In some examples, the acceleration element may be an element that defines a given object (or portion thereof) under a corresponding LOD. These elements may enclose such different LOD geometries within the overlapping space. In one implementation, these elements may be trap elements. The ray may be associated with a LOD identifier, a ray derivative, a spreading factor, or there may be another mechanism for determining the LOD in which the geometry to be presented is located. The limited programmability circuit may select one or more collections, each collection being associated with a corresponding acceleration element into which the ray is to be placed. For example, even though the acceleration structure element being tested may have multiple sub-acceleration structure elements, the limited programmable circuit selects only a subset of those sub-acceleration structure elements. For example, an acceleration structure element associated with a particular level of detail (LOD) may be selected. In some examples, a ray may be within a transition region between two levels of detail, and the ray may be added to two collections such that the ray is traversed within a geometry at multiple levels of detail. The attenuation of the light may be adjusted based on what the finite programmability circuit does, such as reducing the importance of each of a plurality of light rays originating from a single original light ray. As another example, the limited programmability circuit may ignore adding rays to any collection, even if intersecting a parent element. Thus, the limited programmability circuit may influence or control subsequent testing of the light.

The system 501 may also provide a result return path 511. In some cases, the result may require further processing that is performed by program code that is different from the program code that generated the task that caused the result. In some cases, however, this further processing may use some portion of the data common to the program code that generated the task. Depending on the architecture of the computing cluster 502 and as a particular example, depending on the efficiency of moving data from one core to another (e.g., across different L2 caches 507), the result return path may be configured to return results to the core using the L2 cache 507 that has already stored data to be used in this further processing. In some implementations, a destination identifier may be associated with a task when the task is generated, and the destination identifier may be used to direct results back to the source of the task.

Fig. 17 depicts an example of one or more limited-programmability circuits 550, which may be used to implement the limited-programmability circuit 512 depicted in fig. 16. The one or more circuits 550 may include a plurality of predefined mathematical functions 552 and a plurality of programmable function implementations 554. These predefined mathematical functions 552 may include a set of functions that may be evaluated to different values for one or more independent variables of the functions. Such a predefined mathematical function may comprise a matrix transformation according to a 3D space of transformation matrices provided to the finite programmability circuit. In another example, the programmable function implementation may perform or repeat one predefined operation or set of operations multiple times.

Examples of how a circuit may be of limited programmability include: the circuitry can execute a limited number of instructions or otherwise need to be completed in a fixed period of time; program avoids loops or branches; or the circuit has no instruction fetch pipeline. In one example, branching is supported by executing multiple paths through a code segment and then selecting results or masking undesired results. When the limited programmability circuit does not support instruction fetching, the instruction set may be preloaded through the control path. As explained above, limited memory may be provided for storing these instructions and may be designed to support a maximum latency or time period (timeframe) of execution. Thus, the finite programmability circuit may work in conjunction with the test unit to implement forward, iterative, step-by-step refinement, halving, successive approximation, displacement, vector graphics, volumetric effects, and the like.

FIG. 18 depicts an overall flow of ray information in one example implementation. Shading program code 580 and shading program code 582 may each emit light; such rays may be defined by data contained within a ray data structure. The data within the ray data structure may be generated by shading program code modules, which may submit the data using API 575. For example, API 575 may have a ray emission call that accepts a data set for a ray. The collect tracking function 584 may receive data from these ray data structures and collect each new ray to begin traversal with one or more other rays. There may be various intermediate steps or functional elements between the emission of the ray and the tracking of the ray in the collection, and fig. 18 does not imply a direct link.

The ray collection generated by the collection tracking function 584 may be transmitted or submitted to begin traversal (e.g., collections 586 and 588). Intersection test function 590 (which may be implemented by a primitive test unit and an acceleration structure element test unit, in one example) may receive these collections for traversal. For one or more instances in which an implicit geometry is to be traversed or subjected to intersection testing, the intersection test function 590 can activate the implicit geometry shading program function 592.

The intersection test function 590 and the implicit geometry shading program function 592 may each generate ray data structure updates, those ray data structure updates from the geometry shading program function 592 are numbered 594-596, and those ray data structure updates from the intersection test function 590 are numbered 600-602. The intersection disambiguation function 606 may receive the data structure updates from the sources (or other sources, if any) and generate an output that updates the collection of rays in which rays are to be traced (608) during further traversal (finding the nearest intersection), and initiates ray shading (609) (for the identified nearest intersection), which causes further rays to be launched for traversal. Generating the data structure update may be a suitable implementation in which the geometry shading program function, or at least some portion thereof, is implemented by a limited programmability or fixed function element coupled with the intersection test 590. In such an implementation, the generic part of the code may not be called for the geometry shading program function, or such generic part of the code may set the limited programmability unit, but not perform all the calculations. FIG. 18 depicts aspects of an alternative implementation in which a geometry shading program function 592 may be implemented by code executing on a general purpose computing element. In such an implementation, geometry shading program function 592 may be considered a "peer" of shading program codes 580 and 582, in that geometry shading program function 592 may be invoked in response to ray intersection, as code 580 and 582 do, and the output of such geometry shading program function 592 may be affected by ray emission calls using API 575. Thus, after the ray completes the intersection test, geometry shader functions 592 can be invoked using the same semantics as are used to invoke shading programs. However, the geometry shading program function 592 is run during an intermediate stage of intersection testing to produce results for testing light and implicit geometry. The results of this test may be carried with new light rays that are transmitted through API 575. Thus, throughout the traversal of a given ray path, multiple different rays may be emitted, and intersections may be accumulated throughout the path. Some implementations may use the geometry shading program function 592 to compare intersections associated with the ray causing the shading program call and ultimately determine whether the newly identified intersection is closer to the origin of the ray path and only hold the closer intersections. In other implementations, test unit 520 may compare the intersection points stored within localization ray data 514 with the identified intersection points within the arrival ray data structure and maintain a closer intersection point. In such an implementation, test unit 520 maintains current candidates for the nearest intersection within its localization ray data 514 by comparing intersections from geometry shading program function 592 and/or from its own test operations.

The intersection disambiguation function 606 takes a set of intersections for a given ray path and determines the closest intersection between the set of intersections. For example, when a given ray path has traversed one or more instances of a trapped element, there may be a local intersection for that trapped element, while there may also be an intersection of the ray with a geometry that is not surrounded by the trapped element, which may be found during parallel testing of the ray. The intersections can be stored in different data structures and the intersections collected for comparison purposes. For example, multiple individually instantiated rays may ultimately be used to track a single ray path entirely, and those rays may be tracked in parallel in the scene. In other implementations, multiple portions of a single ray path may be tracked serially, with one ray being completed (i.e., the data structure defines the ray along the ray path, but likely only along a limited ray path segment) and another ray being issued and carrying information about the completed portion of the intersection test. A reference count across these multiple portions of the ray path may also be maintained as each segment completes. The functions disclosed with respect to fig. 18 may be implemented in fixed function hardware or in configurable hardware or in software programmed hardware.

Further with respect to trapping elements, the above disclosure provides examples relating to displacement geometries. A trap element may be provided for handling a variety of situations. For example, motion blur may be implemented within the trap element by performing calculations using time values associated with rays to test where the intersection with the moving object occurs under a temporal sequence. These results may then be mixed to determine motion blur characteristics. While the trapping element may refer to a coordinate system other than the world space coordinate system, the trapping element may also use world space coordinates.

Fig. 19 depicts an example operation of the throughput calculation unit 515. The task to be processed 705 is input to the calculation unit 515. For example, each task may include a collection key 710, a data reference 711, and an optional prioritization indicator 712. In some implementations, the key 710 identifies an input or portion of a computational problem to be shared among multiple computational processes. In some implementations, the data reference 711 identifies the portion of data to be processed as one data element within a vector of data elements, where the input or computation problem is identified by the key 710. For example, the key 710 may identify an acceleration structure element, and the data reference 711 may identify a ray to be subjected to an intersection test with the acceleration structure element. The key 710 may identify a program or procedure to be executed on or with the data referenced by the data reference 711. As another example, key 710 may identify coefficients to be multiplied by data identified by data reference 711. Other data describing task 705 may be used in the system or provided within a data structure, but not all of this data may be moved around within throughput computing unit 515. For example, each task may be associated with additional data to be used in further processing based on the results of the task, but the additional data is not necessary for the execution of the task itself.

These tasks 705 (or portions of the illustrative information of these tasks, such as keys 710, data references 711, and prioritization 712) may be provided to a task collector 521 (fig. 16), which is shown here when a collection formation/update module 715 is included. Module 715 may be implemented with a collected cache that stores data references 711 in conjunction with corresponding keys 710. For example, multiple data references may be stored in conjunction with a single key. As a summary of the above, fig. 19 depicts a collection memory 718 that includes a plurality of keys 720-723, each key having a data reference box associated therewith. A priority may be generated for each collection based on a prioritization indicator 712 associated with each task with which the data reference for each task is associated. For example, each collection may be given a priority based on the highest priority task within the collection. The same task (e.g., a data reference from the task) may exist within multiple collections. In the context of ray tracing, each collection may be associated with a shape to be tested for intersection with a collection of rays that are collected into the collection associated with the shape. In an implementation, the collection memory 718 may include a cross-cache in which keys (e.g., 720-723) are hashed or masked to identify candidate locations where the collection of keys may be placed. Collisions between collections may be resolved by evicting the collections.

The scheduler 733 uses the data in the collection memory 718 to form packets that include data from different tasks associated with a given key in the collection from the collection memory 718. The scheduler 733 may communicate with the collect formation/update module 715 to coordinate the formation of the collection and eviction from the collection memory 718. The scheduler 733 may store packets awaiting transmission to one or more packet queues (two queues 734 and 735 are depicted). When multiple queues are used, packets may be classified based on their priority. The plurality of queues may be implemented within non-transitory memory as a first-in-first-out memory, a linked list, a ring buffer, etc. Packets from queues 734 and 735 may be distributed (e.g., distribution packet 719). Distribution package 719 is depicted as including package ID, package priority, and key set, and a plurality of associated data references. In one example, the package may include a single key identifying the program to be executed, data elements to be used in the execution, or both.

The prioritization indicator 712 may be implemented in a variety of ways. The indicator 712 may simply be a sequence identifier (e.g., an incremented number) that indicates the relative order or time when the tasks were transmitted. In one approach, the present sequence identifier allows for a minimum quality of service per task completion. Tasks may also have corresponding indicators 712 that may be interpreted as higher or lower priority than the lowest quality of service level. Even though the normal case provides an incremental identifier, the task need not have a unique identifier 712. For example, a relatively higher priority of a new transmission task may be achieved by copying a sequence identifier that is closer to the current task gap number (as explained with respect to fig. 20), and implementations according to the present disclosure may process the new transmission task at the same priority as a previously transmitted task with the same sequence identifier. Other implementations may provide a sequence identifier and a separate prioritization field.

Test units 516/520 (see FIG. 16) receive inputs at corresponding input buffers 740-742. These inputs may be selected for allocation at test unit 516/520 based on which of the test units store localized data for execution in relation to those inputs. For example, definition data for a ray identified by a particular data reference 711 may be stored in the local memory of only one of test units 516/520, and that data reference will be assigned to that test unit along with a reference to shape or shape data to be tested for that ray. Task state feedback 749 may be implemented by the limited programmability circuit(s) 550. In an example of traversing a ray through the acceleration structure, the feedback may include selecting from a plurality of subelements for which subelements the ray should be collected next. That would be affected by providing a key 710 for the task for each subelement. More generally, the one or more circuits 550 can calculate references or addresses of programs, acceleration structure elements, or data elements to be used in subsequent processing or to be processed in accordance with the next step of the specific data reference 711.

In one example, code modules may execute on computing cluster 502 to set up relevant data in the local memory of test unit 516/520. However, in some implementations, the task memory maintenance module 716 can set data in those local memories based on information in the arrival task definition. For example, module 716 may schedule direct memory transfer requests from shared coherent memory to the local memory of test unit 516/520. These transfers may be scheduled with the awareness of which packets the scheduler 733 has queued. Although the exact timing of when test units 716/720 perform a given task may not be deterministic, a small cache may be provided to buffer data retrieved from shared memory until it is used and then discarded.

Fig. 20 depicts an example of implementing quality of service aware throughput computation. As shown in fig. 19, the task collector may produce a collection of tasks to be performed on the set of computing elements. The task collector may establish groupings of tasks that may be performed in parallel for at least some of those tasks. The task collector can delay the start of executing specific tasks, which is beneficial to overall increase of the throughput of task completion. However, if tasks are selected for execution only in view of throughput, some tasks may not be completed in time. In the context of ray tracing, a relatively small amount of rays may end up in a rarely accessed portion of the 3D scene. Thus, sufficient rays are not available for sufficient collection for those portions, and so if scheduling heuristics are performed to choose sufficient collection to maximize computational parallelism, these rays may not be scheduled for further traversal. In a general computing scenario, a set of code modules, routines, or segments may have portions that are accessed much more frequently than other portions. Execution of these code elements may be scheduled by: requests for such execution are collected and the collection is selected based at least on the corresponding number of requests collected for the different code elements. And here, if scheduling is done only on throughput decisions, some requests may be weakened.

In one example, starting from the task launch point 631, the defined task (defined task defined as 625) can be given an incremented identifier. Tasks may be selected and processed for throughput considerations, but in addition, task gap points 632 must be maintained. Task gap point 632 identifies where in the identifier sequence all lower task identifiers are located that are to be prioritized for completion. As depicted in fig. 20, some tasks (e.g., task 642) that are larger than task gap point 632 may have been completed. As point 632 moves, the scheduler 733 of FIG. 19 may identify collections within collection memory 718 that contain the task (644), select those collections for eviction, and distribute (644) in accordance with the corresponding packets (e.g., in a fast packet queue, e.g., 735). Task results may be obtained 646 and a decision, such as whether the task has been completed, may be made based on those results. If the task is not complete, then a further collection within which the task is to be placed is selected/updated (650). If the task is completed, processing may continue 651 for other tasks.

In the scheduling method according to fig. 20, scheduling may be performed mainly based on throughput, but it is ensured that a given task does not stay longer than a predetermined time (e.g., processor cycle) before advancing the given task. Giving a task a higher priority is accomplished by giving the task a lower sequence identifier than that given to other tasks, which causes the task to reach gap point 632 faster than it would otherwise reach. As explained above, a separate priority indicator may also be maintained. In the specific context of an animation, a sequence of frames may be rendered. The task identifier may include data related to the number of frames (e.g., absolute or relative numbers of frames in flight) that may be used for prioritization. The level of light may also be prioritized by this technique, such as light from a certain shading program module, a certain type of light, etc. Implementations may provide a latency time limit for unidirectional tasks or classes of tasks, lights, or classes of lights. To generalize to computing tasks, multiple classes of tasks (e.g., tasks originating from specific sources, or tasks referencing specific datasets) may be given specific latency. Other ways of relatively prioritizing rays or tasks may be provided in implementations that typically prioritize throughput, but may also avoid exceeding the latency time of a single element of computation.

Multiple tasks between task gap point 632 and task launch point 631 are optional and may be modulated according to real-time system conditions. For example, if rendering is implemented on a processing system that may also intermittently perform more time-critical digital signal processing tasks, or when available memory is currently limited, task gap point 632 may be made more closely follow emission point 631.

If implemented in firmware and/or software, the functions may be presented as one or more instructions or code on a computer-readable medium, which in one example is non-transitory. Examples include computer readable media encoded with a data structure and computer readable media encoded with a computer program. The machine-readable medium includes non-transitory machine-readable media. Other types of media include transmission media. The non-transitory medium may be any tangible medium that can be accessed by a machine. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a machine.

The description of the features of the various aspects is provided to enable any person skilled in the art to make and use the systems and devices and to perform the disclosed methods. Various modifications will be apparent to those skilled in the art, and the principles described in this document may be applied to other aspects without departing from the spirit and scope of the disclosure. Accordingly, the description is not intended to limit the claims. Rather, the claims will be accorded the scope consistent with the principles and novel features disclosed herein.

The drawings include the relative arrangement of the structures and ordering of the process components, and are merely helpful in understanding the present description. These relative arrangements and numbering are not meant to limit the ordering or arrangement of elements or steps in the claims specifically. Process limitations may be interchanged sequentially without departing from the scope of the disclosure, and claims and means-plus-function phrases are intended to cover what is described as performing the recited function, including not only structural equivalents but also equivalent structures.

While various examples and other information are used to explain aspects within the scope of the appended claims, no limitation to the claims should be implied based on the specific features or arrangements in such examples as one of ordinary skill will be able to derive a wide variety of implementations using such examples. Further, and although certain subject matter has been described in language specific to structural features and/or methodological steps, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts. For example, such functionality may be distributed among, or performed in, components other than those identified herein, additional components, or fewer components. Rather, the features and steps are disclosed as examples of components of systems and methods that are within the scope of the appended claims.

Claims (10)

1. A method of tracking rays within a 3D scene, comprising:

traversing a ray in an acceleration structure comprising a plurality of elements;

determining whether an element of the acceleration structure intersected by the ray includes an object instance;

converting data defining the ray from a scene-wide coordinate system to a reference coordinate system for the element of the acceleration structure;

determining a result of testing the intersection of the ray with a geometric body located within the element, the result comprising identification data for a nearest intersection point with the geometric body within the element and a distance to the nearest intersection point;

converting the results of the test from the reference coordinate system to the scene global coordinate system; and

upon completion of the traversal of the ray, the generally closest intersection point for the ray is determined.

2. The method of tracking rays within a 3D scene of claim 1, wherein determining a result of testing the ray intersecting a geometry located within the element comprises: a result of testing the ray for intersection with implicitly defined geometry located within the element is determined.

3. The method of tracking rays within a 3D scene as recited in claim 1, wherein determining an overall nearest intersection point for the ray comprises: the identification data is used to select an intersection point from a plurality of intersection points having the same intersection point distance.

4. The method of tracking rays within a 3D scene as recited in claim 1, further comprising: maintaining a minimum distance and a maximum distance for the ray, wherein the maximum distance identifies a current nearest intersection point for the ray; and excluding one or more elements of the acceleration structure from other tests, wherein elements of the acceleration structure that overlap with a range defined by the minimum distance and the maximum distance are not excluded from other tests.

5. A system configured to track light rays within a 3D scene, the system configured to:

traversing a ray in an acceleration structure comprising a plurality of elements;

determining whether an element of the acceleration structure intersected by the ray includes an object instance;

converting data defining the ray from a scene global coordinate system to a reference coordinate system for the element of the acceleration structure using a programmable circuit;

determining, using a test unit, a result of testing the intersection of the ray with a geometry located within the element, the result comprising identification data for a closest intersection point with the geometry within the element and a distance to the closest intersection point;

converting the result of the test from the reference coordinate system to the scene global coordinate system using a programmable circuit; and

Upon completion of the traversal of the ray, the generally closest intersection point for the ray is determined.

6. The system of claim 5, wherein determining a result of testing the ray intersecting a geometry located within the element comprises: a result of testing the ray for intersection with implicitly defined geometry located within the element is determined.

7. The system of claim 5, wherein determining the overall nearest intersection point for the ray comprises: the identification data is used to select an intersection point from a plurality of intersection points having the same intersection point distance.

8. The system of claim 5, wherein the system is further configured to: maintaining a minimum distance and a maximum distance for the ray, wherein the maximum distance identifies a current nearest intersection point for the ray; and excluding one or more elements of the acceleration structure from other tests, wherein elements of the acceleration structure that overlap with a range defined by the minimum distance and the maximum distance are not excluded from other tests.

9. A system of tracking rays within a 3D scene, the system configured to perform the method of any of claims 1-4.

10. A computer readable medium comprising instructions which, when executed by a processor, cause the processor to perform the method of any one of claims 1 to 4.

Images