CN116664747A - Intersection testing in ray tracing systems - Google Patents

Intersection testing in ray tracing systems Download PDF

Info

Publication number
CN116664747A
CN116664747A CN202310160870.4A CN202310160870A CN116664747A CN 116664747 A CN116664747 A CN 116664747A CN 202310160870 A CN202310160870 A CN 202310160870A CN 116664747 A CN116664747 A CN 116664747A
Authority
CN
China
Prior art keywords
primitive
intersection
ray
primitives
distance
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310160870.4A
Other languages
Chinese (zh)
Inventor
P·史密斯-莱西
S·芬尼
G·克拉克
R·金
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Imagination Technologies Ltd
Original Assignee
Imagination Technologies Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Imagination Technologies Ltd filed Critical Imagination Technologies Ltd
Publication of CN116664747A publication Critical patent/CN116664747A/en
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/00—3D [Three Dimensional] image rendering
    • G06T15/06—Ray-tracing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/20—Processor architectures; Processor configuration, e.g. pipelining
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/00—3D [Three Dimensional] image rendering
    • G06T15/10—Geometric effects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T17/00—Three dimensional [3D] modelling, e.g. data description of 3D objects
    • G06T17/20—Finite element generation, e.g. wire-frame surface description, tesselation
    • G06T17/205—Re-meshing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T7/00—Image analysis
    • G06T7/10—Segmentation; Edge detection
    • G06T7/136—Segmentation; Edge detection involving thresholding
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T7/00—Image analysis
    • G06T7/50—Depth or shape recovery

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Graphics (AREA)
  • Geometry (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Software Systems (AREA)
  • Analysing Materials By The Use Of Radiation (AREA)
  • Image Analysis (AREA)
  • Navigation (AREA)

Abstract

The application relates to intersection testing in ray tracing systems. A method and an intersection test module for performing intersection tests in a ray tracing system are provided. Determining that a difference between an intersection distance at which the ray intersects the first primitive and an intersection distance at which the ray intersects the second primitive meets a comparison condition with respect to a threshold; determining that the orientation of the first primitive and the second primitive is different. An intersection of the ray with one of the first primitive and the second primitive is selected based on the one of the first primitive and the second primitive having a particular orientation.

Description

Intersection testing in ray tracing systems
Cross Reference to Related Applications
The present application claims priority from uk patent applications GB2202657.9, GB2202658.7 and GB2202659.5 filed on 25 months 2 of 2022, which are incorporated herein by reference in their entirety.
Technical Field
The present disclosure relates to techniques for performing intersection testing in a ray tracing system.
Background
Ray tracing is a computational rendering technique for generating images of a scene (e.g., a 3D scene) by tracing an optical path ('ray') in the scene, typically from the perspective of the camera. Each ray is modeled as originating from a camera and entering the scene through a pixel. As a ray traverses a scene, it may intersect objects within the scene. The intersection between a ray and its intersecting object can be modeled to create a realistic visual effect. For example, in response to determining that a ray intersects an object, a shader program (i.e., a portion of computer code) may be executed for the intersection. A programmer may write a shader program to define how the system reacts to an intersection (which may, for example, result in one or more secondary rays being emitted into the scene), for example, to represent reflection of a ray from an intersecting object or refraction of a ray through an object (e.g., if the object is transparent or translucent). As another example, the shader program may cause one or more rays to be emitted into the scene for determining whether an object is in a shadow at an intersection. The result of executing the shader program (and processing the associated secondary ray) may be to calculate the color value of the pixel through which the ray passed.
Rendering an image of a scene using ray tracing may involve performing many intersection tests, such as performing billions of intersection tests to render an image of a scene. To reduce the number of intersection tests that need to be performed, the ray tracing system may generate an acceleration structure, where each node of the acceleration structure represents an area within the scene. The acceleration structure is typically hierarchical (e.g., has a tree structure) such that it contains multiple levels of nodes, where nodes near the top of the acceleration structure represent relatively large areas in the scene (e.g., the root node may represent the entire scene), and nodes near the bottom of the acceleration structure represent relatively small areas in the scene. The leaf nodes of the acceleration structure represent regions in the scene surrounding one or more primitives and have pointers to the surrounding primitives.
An acceleration structure may be used to perform intersection testing of a ray by first testing the ray for intersection with a root node of the acceleration structure (e.g., in a recursive manner). If a ray is found to intersect a parent node (e.g., root node), then the test may proceed to a child node of the parent node. In contrast, if a ray is found not to intersect a parent node, intersection testing of child nodes of the parent node may be avoided, thereby saving computational effort. If a ray is found to intersect a leaf node, the ray may be tested against objects within the region represented by the leaf node to determine which object(s) the ray intersects. "primitives" may be used to represent objects. The primitives represent geometric units in the system and may be, for example, convex polygons. The primitives are typically triangles, but may also be other shapes, such as squares, rectangles, pentagons, hexagons, etc. Furthermore, some primitives may not be convex polygons, or even polygons. For example, the primitives may be disk-shaped or some other surface or volume.
Ray (r) may be defined as r=o+dt, where O is a vector representing the origin of the ray, D is a vector representing the direction of the ray, and t represents the distance along the ray from the origin relative to the magnitude of D. Primitives may be represented as convex polygons (e.g., triangles) defined by an ordered set of planar vertices, whereby successive pairs of vertices define edges of the primitive, and the overall vertex order gives the winding order of the primitives. The orientation of the primitives with respect to the ray (i.e., clockwise or counterclockwise) depends on the wrapping order of the primitives as well as the origin and direction of the ray. A flag may be set in the ray tracing system (e.g., by a user) to indicate whether the clockwise or counterclockwise orientation corresponds to a forward facing primitive. The winding order of the primitives may be used with the predetermined orientation as facing forward (clockwise or counter-clockwise) to mark one side of the primitive as the front and the other side as the back. Depending on which side is observed for a given ray, it is determined whether the primitive is forward facing or backward facing, clockwise or counterclockwise, at least from the perspective of the ray.
To determine whether a ray intersects a planar primitive, the intersection of the ray with the plane containing the primitive may be determined, and then it may be determined whether the intersection is internal to the primitive. In this way, given a ray/primitive pair, the primitive intersection stage may determine whether a ray intersects a primitive and output it as a "hit" result. When a ray intersects a primitive (i.e., a hit is set), the primitive intersection stage may also calculate additional attributes such as orientation (clockwise/counter-clockwise or forward/backward facing), intersection distance, and/or barycentric coordinates indicating the location of the intersection point on the primitive. In particular, the distance calculation may generate a floating point value that indicates a multiple of the length of the ray required to travel from the ray origin to the intersection point (e.g., indicated using the value t) (this multiple may be negative if the intersection occurs behind the origin).
A ray may intersect more than one primitive in the scene. Thus, after the primitive intersection phase, if an intersection is found between the ray and the primitive, the intersection selection phase determines whether a new intersection or an old intersection of the ray should be selected. Typically, the closer of the two intersections is selected (i.e., the first intersection that the ray encounters in the scene is selected). The term "closer" may mean closer to the origin of the ray, or it may mean closer to minus infinity, depending on the particular implementation (these two concepts are generally equivalent, as this is common practice, but not necessary, for the minimum distance of the ray to be greater than or equal to zero). The selected intersections are then used for further processing of the ray, while the unselected intersections are discarded. This process is also known as hidden surface determination, display surface determination, hidden Surface Removal (HSR), occlusion Culling (OC), or Visible Surface Determination (VSD). The current closest intersection point is an attribute of each ray and thus may be stored as ray data.
The "closer intersection" of the two intersections may be selected purely based on the intersection distance values output from the primitive intersection stage. However, in some cases this is not possible or does not provide good results. For example, if the ray is equal to the intersection distance of two different primitives, it is not possible to distinguish them based on the intersection distance alone. In this case, some form of tie-breaking rule may be used, but known tie-breaking rules do not always select the "best" intersection in terms of reducing perceived rendering artifacts.
It should be noted that it is not uncommon for a ray to be equidistant from the intersection of two different primitives because an object is typically represented using multiple primitives, such as using a primitive mesh, resulting in a shared vertex defining two or more of the primitives. Furthermore, primitives may have shared edges, i.e., edges where both endpoints are shared vertices. If a ray intersects a point on a shared edge or vertex, then the intersection distance with the two primitives that share that edge or vertex should be equal. An intersection test is described as "tight" if it ensures that a ray that intersects a point or shared vertex on a shared edge intersects at least one of the primitives. If the intersection test ensures that a ray intersecting a point or shared vertex on a shared edge of a closed fan intersects one (and only one) of the primitives, then the intersection test is described as "non-redundancy tight", it being noted that in this case only a (strict) subset of its boundaries can be considered part of the primitive. A (closed) sector may be encoded as (a subset of) a list of vertices with or without repeated vertices (indicating the central vertices of the sector) and with an implicit primitive topology, e.g. given by a vertex order (e.g. a list of vertex tuples, or a triangle sector or triangle strip compactly represented in a computer graphics system), or with an explicit primitive topology, e.g. given by a (subset of) a list of vertex index tuples.
If a ray intersecting a point on the shared edge is found to intersect a zero primitive, it may behave as if there were holes in the primitive mesh, so that the color behind the primitive mesh may be seen through the mesh in the rendered image (which may occur if the intersection test is not tight, but not tight). For example, if the colors behind the primitive mesh are significantly different from the colors of the primitive mesh, these kinds of rendering errors may be very noticeable. Furthermore, if a ray that intersects a point on a shared edge (which may include vertices defining the edge) is found to intersect more than one primitive (which may be referred to as a "double-intersection"), the color rendered at the location of the shared edge may depend on the order in which the test primitives intersect, such that the rendering may become ambiguous. These kinds of rendering errors may be detrimental to the perceived quality of the rendered image. Additional reasons for having non-redundant tight intersection testing include: (i) To avoid redundant work, and (ii) to avoid shadow discontinuities at any double/multiple hits in transparent objects caused by repeated intersections. The test of the ray intersecting the first primitive is typically performed independently of the test of the ray intersecting the second primitive, and it should be noted that ensuring tightness, and in particular non-redundant tightness for intersecting tests, is not straightforward.
Another problem with using the intersection distance alone to perform intersection selection is that there may be some error in the calculated intersection distance. For example, distance calculations that determine the intersection distance typically operate on floating point numbers, which may have significantly different scales. When floating point numbers are used in the calculation, some rounding of the values is typically done, which may introduce errors in the results. Rounding errors are particularly pronounced when values of very different magnitudes are used in the same operation. These errors in the intersection distance calculation may cause errors in determining which intersection is closest. The error in determining which intersection is closest may be referred to as a "depth conflict" and may cause rendering artifacts where a surface that should be hidden by another surface at a pixel location is visible. Depth conflicts tend to occur when two overlapping surfaces are close to each other.
Disclosure of Invention
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
A computer-implemented method of performing intersection testing in a ray tracing system is provided, the method comprising:
determining that a difference between an intersection distance at which a ray intersects a first primitive and an intersection distance at which the ray intersects a second primitive meets a comparison condition with respect to a threshold;
determining that the first primitive and the second primitive are oriented differently; and
an intersection of the ray with one of the first primitive and the second primitive is selected based on the one of the first primitive and the second primitive having a particular orientation.
The comparison condition may be satisfied with respect to the threshold value if the difference between the intersection distance at which the ray intersects the first primitive and the intersection distance at which the ray intersects the second primitive is less than the threshold value.
The comparison condition may be satisfied with respect to the threshold value if the difference between the intersection distance at which the ray intersects the first primitive and the intersection distance at which the ray intersects the second primitive is less than or equal to the threshold value.
The determining that the difference between the intersection distance of the ray intersecting the first primitive and the intersection distance of the ray intersecting the second primitive satisfies the comparison condition with respect to the threshold may include: determining the intersection distance of the ray and the first primitive; determining the intersection distance at which the ray intersects the second primitive; and comparing the determined intersection distances.
The threshold may be non-zero.
The primitives with the particular orientation may be forward-facing primitives, and wherein the primitives with different orientations than the particular orientation may be backward-facing primitives.
The method may also include determining that the ray intersects the first primitive and the second primitive.
The method may further comprise: the intersection of the ray with the one of the first primitive and the second primitive having the smaller intersection distance is selected if the difference between the intersection distance of the ray with the first primitive and the intersection distance of the ray with the second primitive does not satisfy the comparison condition relative to the threshold.
The method may further comprise: if the intersection distance of the ray with the first primitive is equal to the intersection distance of the ray with the second primitive, and if the orientations of the first primitive and the second primitive are the same, the intersection of the ray with one of the first primitive and the second primitive is selected based on a unique primitive ID associated with the first primitive and the second primitive.
The method may also include rendering an image in the ray tracing system using the selected intersection.
An intersection test module for use in a ray tracing system is provided, the intersection test module comprising:
intersection selection logic configured to:
determining that a difference between an intersection distance at which a ray intersects a first primitive and an intersection distance at which the ray intersects a second primitive meets a comparison condition with respect to a threshold;
determining that the first primitive and the second primitive are oriented differently; and
an intersection of the ray with one of the first primitive and the second primitive is selected based on the one of the first primitive and the second primitive having a particular orientation.
The comparison condition may be satisfied with respect to the threshold value if the difference between the intersection distance at which the ray intersects the first primitive and the intersection distance at which the ray intersects the second primitive is less than the threshold value.
The comparison condition may be satisfied with respect to the threshold value if the difference between the intersection distance at which the ray intersects the first primitive and the intersection distance at which the ray intersects the second primitive is less than or equal to the threshold value.
The intersection test module may further include intersection determination logic configured to: determining that the ray intersects the first primitive and determining the intersection distance at which the ray intersects the first primitive; and determining that the ray intersects the second primitive and determining the intersection distance at which the ray intersects the second primitive.
An intersection test module may be provided that is configured to perform any of the methods described herein.
A computer-implemented method of performing intersection testing in a ray tracing system may be provided, the method comprising:
if a difference between an intersection distance at which a ray intersects a first primitive and an intersection distance at which the ray intersects a second primitive meets a comparison condition with respect to a threshold, and if the orientations of the first primitive and the second primitive are different, an intersection of the ray with one of the first primitive and the second primitive having a particular orientation is selected. A computer-implemented method of performing intersection testing in a ray tracing system may be provided, the method comprising:
determining that the intersection distance of the ray intersecting the first primitive is equal to the intersection distance of the ray intersecting the second primitive;
Determining that the first primitive and the second primitive are oriented differently; and
an intersection of the ray with one of the first primitive and the second primitive is selected based on the one of the first primitive and the second primitive having a particular orientation.
An intersection test module for use in a ray tracing system may be provided, the intersection test module comprising:
intersection selection logic configured to: if a difference between an intersection distance at which a ray intersects a first primitive and an intersection distance at which the ray intersects a second primitive meets a comparison condition with respect to a threshold, and if the orientations of the first primitive and the second primitive are different, an intersection of the ray with one of the first primitive and the second primitive having a particular orientation is selected.
An intersection test module for use in a ray tracing system may be provided, the intersection test module comprising:
intersection selection logic configured to:
determining that the intersection distance of the ray intersecting the first primitive is equal to the intersection distance of the ray intersecting the second primitive;
determining that the first primitive and the second primitive are oriented differently; and
An intersection of the ray with one of the first primitive and the second primitive is selected based on the one of the first primitive and the second primitive having a particular orientation.
A computer-implemented method of performing intersection testing in a ray tracing system may be provided, the method comprising:
determining a first offset intersection distance equal to a sum of an intersection distance of a ray with a first primitive and a first offset dependent on an orientation of the first primitive;
determining a second offset intersection distance equal to a sum of an intersection distance of the ray with a second primitive and a second offset dependent on an orientation of the second primitive;
comparing the determined first offset intersection distance with the determined second offset intersection distance to select an intersection of the ray with one of the first primitive and the second primitive.
An intersection test module for use in a ray tracing system may be provided, the intersection test module comprising:
intersection selection logic configured to:
determining a first offset intersection distance equal to a sum of an intersection distance of a ray with a first primitive and a first offset dependent on an orientation of the first primitive;
Determining a second offset intersection distance equal to a sum of an intersection distance of the ray with a second primitive and a second offset dependent on an orientation of the second primitive;
comparing the determined first offset intersection distance with the determined second offset intersection distance to select an intersection of the ray with one of the first primitive and the second primitive.
The intersection test module may be embodied in hardware on an integrated circuit. A method of manufacturing an intersection test module at an integrated circuit manufacturing system may be provided. An integrated circuit definition data set may be provided that, when processed in an integrated circuit manufacturing system, configures the system to manufacture intersection test modules. A non-transitory computer-readable storage medium may be provided having stored thereon a computer-readable description of an intersection test module that, when processed in an integrated circuit manufacturing system, causes the integrated circuit manufacturing system to manufacture an integrated circuit embodying the intersection test module.
An integrated circuit manufacturing system may be provided, comprising: a non-transitory computer-readable storage medium having stored thereon a computer-readable description of the intersection test module; a layout processing system configured to process the computer-readable description to generate a circuit layout description of the integrated circuit embodying the intersection test module; and an integrated circuit generation system configured to fabricate the intersection test module from the circuit layout description.
Computer program code for performing any of the methods described herein may be provided. A non-transitory computer readable storage medium may be provided having stored thereon computer readable instructions that, when executed at a computer system, cause the computer system to perform any of the methods described herein.
As will be apparent to those skilled in the art, the above features may be suitably combined and combined with any of the aspects of the examples described herein.
Drawings
Examples will now be described in detail with reference to the accompanying drawings, in which:
FIG. 1 illustrates a ray tracing system according to examples described herein;
FIG. 2 shows one ray and two primitives in a scene to be rendered;
FIG. 3a shows a grid of primitives forming a circular band, indicating which edges are considered part of which primitives in a "wrapping/orientation independence" scheme;
FIG. 3b shows a grid of primitives forming a circular band, wherein it is indicated which edges are considered part of which primitives in a "wrap/orientation dependent" scheme;
FIG. 4a illustrates an intersection test module for use in a ray tracing system according to examples described herein;
FIG. 4b is a high-level flow chart illustrating an intersection test procedure for rays in a ray tracing system;
FIG. 5 is a flow chart of a first method of performing intersection testing;
FIG. 6a shows a grid of primitives forming a circular band, indicating which edges are considered part of which primitives in a "wrap/orientation independence" scheme that prioritizes clockwise orientation;
FIG. 6b shows a grid of primitives forming a circular band, wherein it is indicated which edges are considered part of which primitives in a "wrap/orientation independence" scheme that prioritizes counter-clockwise orientation;
FIG. 6c shows a grid of primitives forming a circular band, wherein it is indicated which edges are considered part of which primitives in a "wrap/orientation-dependent" scheme that prioritizes clockwise orientation;
FIG. 6d shows a grid of primitives forming a circular band, wherein it is indicated which edges are considered part of which primitives in a "wrap/orientation-dependent" scheme that prioritizes counter-clockwise orientation;
FIG. 7a shows a grid of primitives forming a circular band, indicating which edges are considered part of which primitives in a "wrapping/orientation independence" scheme, which shows areas where depth conflicts are likely to occur;
FIG. 7b shows a grid of primitives forming a circular band, indicating which edges are considered part of which primitives in a "wrap/orientation dependent" scheme, which shows areas where depth conflicts are likely to occur;
FIG. 8 is a flow chart of a second method of performing intersection testing;
FIG. 9a shows a grid of primitives forming a circular band, wherein it is indicated which edges are considered part of which primitives in a "wrapping/orientation independence" scheme, wherein primitives with clockwise orientation have been shifted forward relative to primitives with counterclockwise orientation;
FIG. 9b shows a primitive mesh forming a circular band, indicating which edges are considered part of which primitives in a "wrap/orientation-dependent" scheme, wherein primitives with a clockwise orientation have been offset forward relative to primitives with a counter-clockwise orientation;
FIG. 10 is a flow chart of a third method of performing intersection testing;
FIG. 11 illustrates a computer system in which a ray tracing system including an intersection test module is implemented; and is also provided with
FIG. 12 illustrates an integrated circuit manufacturing system for generating an integrated circuit embodying an intersection test module.
The figures illustrate various examples. Skilled artisans will appreciate that element boundaries (e.g., blocks, groups of blocks, or other shapes) illustrated in the figures represent one example of boundaries. In some examples, it may be the case that one element may be designed as a plurality of elements, or that a plurality of elements may be designed as one element. Where appropriate, common reference numerals have been used throughout the various figures to indicate like features.
Detailed Description
The following description is presented by way of example to enable a person skilled in the art to make and use the invention. The invention is not limited to the embodiments described herein and various modifications to the disclosed embodiments will be apparent to those skilled in the art.
Embodiments will now be described by way of example only.
Fig. 1 shows a ray tracing system 100 comprising a ray tracing unit 102 and a memory 104. Ray tracing unit 102 includes a processing module 106, an intersection test module 108, and processing logic 110. Intersection test module 108 includes one or more box intersection test units 112 and one or more primitive intersection test units 114. In operation, ray traced unit 102 receives geometric data defining objects within a 3D scene. Ray tracing unit 102 also receives ray data defining rays of the intersection to be tested. The light may be primary or secondary. The processing module 106 is configured to generate an acceleration structure based on the geometric data and send the acceleration structure to the memory 104 for storage therein. After the acceleration structure has been stored in the memory 104, the intersection test module 108 can retrieve nodes of the acceleration structure (e.g., including data defining an axis alignment box corresponding to the nodes) from the memory 104 to perform ray intersection tests for the retrieved nodes. To avoid reading the entire acceleration structure at a time, the intersection test module 108 retrieves a subset of the boxes from a layer of acceleration structure from the memory 104 at each stage based on the results of previous intersection tests. The box intersection test unit 112 performs an intersection test to determine whether a ray intersects each of the bounding boxes corresponding to the nodes of the acceleration structure (where a miss may cull a large piece of the hierarchical acceleration structure). If a leaf node intersection is determined, primitive intersection test unit 114 performs one or more primitive intersection tests to determine which object(s), if any, the ray intersects. In this example, the primitives are triangles, but it should be noted that in other examples, the primitives may be other shapes, such as other convex planar polygons (such as squares, rectangles, pentagons, hexagons, etc.), non-convex polygonal or non-polygonal planar shapes (e.g., disk-shaped), or even non-planar shapes (e.g., shapes isomorphic to disk-shaped). Furthermore, primitives may be assumed to be non-degenerate (i.e., 2D) because the intersection with the degenerate primitive (i.e., 1D or 0D primitive) may be considered a miss. The results of the intersection test indicate which object in the scene the ray intersects, and these results may also indicate other intersection data, such as the location on the object where the ray intersects the object (e.g., barycentric coordinates), may also indicate distances along the ray where the intersection occurred, such as Euclidean distances or (signed) multiples of the ray length, and may also indicate perceived orientation (e.g., clockwise/counter-clockwise or front-facing/back-facing) of the object as seen from the ray's perspective. In some cases, the intersection determination may be based on whether the distance along the ray at which the intersection occurred is between the minimum clipping distance and the maximum clipping distance of the ray (which may be referred to as t min And t max ). The results of the intersection test are provided to processing logic 110. Processing logic 110 is configured to process the results of the intersection test to determine rendering values for images representing the 3D scene. The rendering values determined by processing logic 110 may be returned to memory 104 for storage therein to represent an image of the 3D scene.
In the examples described herein, ray tracing systems use acceleration structures in order to reduce the number of intersection tests that need to be performed on a ray for a primitive. It should be noted, however, that some other examples may not use acceleration structures and that rays may be simply tested for primitives without first attempting to reduce the number of intersection tests that need to be performed using acceleration structures.
Fig. 2 shows a ray 202 and two primitives 204 and 206 in a scene to be rendered. The two primitives are triangles and share edges such that they form a quadrilateral. In different implementations, the number of primitives tested in a single instance of primitive intersection testing unit 114 may be different. For example, primitive intersection test unit 114 may be a "single tester" (i.e., configured to test the intersection of a ray with a single primitive at a time), a "double tester" (i.e., configured to test the intersection of a ray with a pair of primitives at a time), or the like. The intersection determination logic 402 should process primitives in the same manner regardless of the number of primitives for which the primitive intersection test unit 114 is configured to test a ray in a single instance. Similar toThe primitive intersection test unit 114 is configured to test the number of primitives for which a ray is directed in a single instance without affecting how the intersection selection logic 404 processes the primitives. In fig. 2, the orientation of the two primitives is indicated as clockwise from the light point of view. Primitive 204 is composed of an ordered set of vertices (v 0 ,v 1 ,v 2 ) Is defined, and primitives 206 are defined by an ordered set of vertices (v 1 ,v 3 ,v 2 ) And (5) defining. Vertex v 1 And v 2 The edges in between are shared by primitives 204 and 206. Due to v 1 And v 2 Are defined in the opposite order in primitives 204 and 206 so that edges have opposite directions in one primitive than the other primitive, and thus the two primitives are said to be designated with consistent wrapping. As described above, ray 202r (t) may be represented as r (t) =o+dt, where O is a vector representing the origin 201 of the ray and D is a vector of directions of the ray. In the example shown in FIG. 2, ray 202 intersects primitive 204 at intersection point 208, but ray 202 does not intersect primitive 206.
Primitive intersection test unit 114 uses non-redundant rigorous techniques to sequentially test a ray against multiple primitives in a scene to determine whether the ray intersects each primitive in the multiple primitives. Different techniques may be used in different examples, and we describe one such example herein. It should be particularly noted that the method described below as being performed by the intersection selection logic 404 to address double intersection may be used with other non-redundant tight intersection testing schemes and/or redundant tight intersection testing schemes. In particular, the method described below performed by the intersection selection logic 404 to address double intersections may be equally useful (not less than) for use with redundant tight intersection test schemes, as there will be more double intersections in those intersection test schemes. Moreover, regardless of the tightness, the methods described below may still provide certain benefits (especially in terms of depth conflicts) for any intersection testing scheme.
In the example non-redundant rigorous techniques described herein, primitive test unit 114 determines, for each edge of a primitive, which side of the edge to indicate through which light passesIs used to test the intersection of the ray with the primitive. For example, w may be a signed parameter that, when a direction vector (D) parallel to the ray is projected into a 2D space having axes denoted P and Q in FIG. 2, uses two vertices (v i And v j ) Is a function of the position f (v i ,v j ) (which is referred to herein as a "2D cross product") to determine the parameter. Axes P and Q are both perpendicular to ray direction vector D of ray 202. The P-axis and Q-axis are not parallel to each other. The P-axis and the Q-axis may or may not be perpendicular to each other. The origin of the pair of axes corresponds to the ray origin 201. Two projected vertices v defining an edge i And v j Is a 2D cross product f (v) i ,v j ) Is defined as f (v i ,v j )＝p i q j -q i p j Wherein p is i And q i Is the projection vertex v i Components along respective axes of the pair of axes, and wherein p j And q j Is the projection vertex v j Components along respective axes of the pair of axes. In other examples, the parameter w may be determined using other functions defining the positions of the two projected vertices of the edge. For example, the function may return p i q j And q i p j This will avoid performing a subtraction operation, but will not provide a magnitude for determining the barycentric coordinates.
The sign w of the edge of the primitive indicates the angle from the edge (from v i Pointing v j ) Whether the light passes to the left or right of the edge is seen. On the "left" side of the edge by corresponding to a counter-clockwise rotation relative to the origin from the first end point to the second end point. On the "right" side of the edge by corresponding to a clockwise rotation relative to the origin from the first end point to the second end point. For the above as f= (v i ,v j )＝p i q j -q i p j Given the form of a "2D cross product", and with the first axis (P) pointing to the right and the second axis (Q) pointing upward (if we look along ray 202), left/counter-clockwise corresponds to the positive result of f and right/clockwise corresponds to the negative result of f. Assuming a left-hand system (according to fig. 2), and the first axis P and the second axis Q are directed to the right and to the direction, respectively, in projection spaceUpper alignment means that the third axis (ray direction D) is pointing into the page, giving a corrected perceived orientation. In a right-hand system, the third axis (ray direction D) is pointing out of the page, giving a wrong perceived orientation.
In this example, the primitive intersection test unit 114 of the intersection test module 108 determines whether a ray intersects a primitive based on the w parameter determined for the edge of the primitive. For example, if the w parameters determined for the edges of the primitive all have the same sign, then it is determined that the ray intersects the primitive; and if the w parameters determined for the edges of the primitive do not all have the same sign, determining that the ray does not intersect the primitive. In this way, the parameters determined for the edges of the primitive are used to determine whether the ray passes through the interior of the edges of the primitive, wherein if the ray is determined to pass through the interior of all of the edges of the primitive, the ray is determined to intersect the primitive, and wherein if the ray is determined to pass outside of one or more of the edges of the primitive, the ray is determined to not intersect the primitive. For example, the w-parameter determined for all of the edges of primitive 204 in FIG. 2 will be negative, indicating that from an edge perspective (from v i Pointing v j ) The light passes through the right side of all of the edges. Thus, it will be determined that the ray intersects primitive 204. However, for primitive 206, for slave vertex v 1 To vertex v 3 From vertex v 3 To vertex v 2 The w parameter determined by the edge of (c) will be negative, indicating that from the edge's point of view (from v i Pointing v j ) The ray passes through the right side of those two edges but for the ray from vertex v 2 To vertex v 1 The w parameter determined by the edge of (c) will be positive, indicating that from the edge's point of view (from v 2 Pointing v 1 ) Light passes through the left side of the edge. Since the sign of the w-parameter determined for the edges of the primitive 206 is not all the same, it is determined that the ray does not intersect the primitive 206.
If a ray intersects a location on a shared edge (or shared vertex), then the 2D cross product of that shared edge (or those edges that include the shared vertex) is zero, i.e., f (v i ,v j )＝p i q j -q i p j =0. For example, ray 202 may be associated with primitive 204And 206, i.e. intersecting with the position on the shared edge defined by vertex v 1 And v 2 The locations on the defined edges intersect. As described above, in this case, the intersection test is preferably non-redundancy tight. As described above, an intersection test for a ray with a primitive is "tight" if it is ensured that a ray that intersects a point on a shared edge of multiple primitives or a shared vertex of a closed fan is determined to intersect at least one of the primitives that share that edge or vertex. Furthermore, if a ray that is guaranteed to intersect a point on a shared edge of multiple primitives or a shared vertex of a closed sector is determined to intersect a single one of the primitives that share the edge or vertex (i.e., the ray is determined to intersect one and only one of the primitives that share the edge or vertex), then the intersection of the ray with the primitive is tested to be "non-redundant. As described above, rays are independently tested for intersection for each primitive.
There are different types of schemes to achieve non-redundant tight intersection testing. For example, some schemes are "wrap/orientation independent," meaning that if a ray intersects an edge of a primitive (e.g., if the 2D cross product of the edge is zero), then the determination of whether the ray intersects the primitive is not dependent on the orientation of the primitive. In these schemes, when considering primitives in 2D space (e.g., as viewed along ray direction vectors in the 2D space defined by the P and Q axes mentioned above and shown in fig. 2), a determination may be made based on whether the edges are primarily top, bottom, left or right edges of the primitives, in such a way that opposite intersection determinations will be obtained for a shared edge between two primitives. For example, in a scheme following the upper left rule, all sides surrounding a primitive from above, or surrounding a primitive from the left but exactly perpendicular, are considered part of the boundary of the primitive, while all sides surrounding a primitive from below, or surrounding a primitive from the right but exactly perpendicular, are not considered part of the boundary of the primitive.
Fig. 3a shows a grid of primitives 302 to 320 forming a circular band (i.e. ring) with appropriate shading indicating which edges are considered part of each primitive in a "wrap/orientation independence" scheme. Fig. 3a is a view of a (non-projected) primitive from a point of view slightly above the origin of the camera for a camera that emits a primary ray away from its origin. From the origin of the camera, only primitives 302 through 310 may be visible, while primitives 312 through 320 may be occluded by primitives in front of them. From the viewpoint, the contour boundary of the primitive mesh is given by the boundary between the front primitive and the rear primitive, i.e., the shared edge between primitives 302 and 320 and the shared edge between primitives 310 and 312. The clockwise orientation of the front primitive will have a consistent wrap with the counterclockwise orientation of the rear primitive and the counterclockwise orientation of the front primitive (e.g., primitive 306) will have a consistent wrap with the clockwise orientation of the rear primitive (not shown in fig. 3 a). This can be understood by imagining rotating the primitive bands and considering how the orientation of each primitive changes when it transitions from a front primitive (i.e. in front of the contour) to a rear primitive (i.e. behind the contour) and vice versa. The wrapping order of each primitive can be inferred from its perceived orientation in FIG. 3a, and it can be seen that all of the primitives except primitive 306 have a consistent wrapping order (i.e., each edge has an opposite wrapping direction in the two primitives that share that edge). For visual clarity only, the primitives are alternately color coded as medium gray or black: the color of the primitive is seen in fig. 3a by the color of the winding symbol inside the primitive. The shared edge has a solid black or medium gray line to indicate which of the black or gray primitives sharing the edge will be hit by a ray that exactly intersects the shared edge. The dashed edges in light gray indicate that the primitive shown in FIG. 3a will not be hit by a ray that exactly intersects the edge. The shared edge has a dashed line of both black and middle gray to indicate that both black and middle gray primitives sharing the edge will be hit by rays that precisely intersect the shared edge.
The wrapping/orientation independence scheme ensures non-redundant tightness inside the primitive mesh even if the wrapping order of the primitives is not consistent. However, this may result in a lack of "non-redundant tightness" on the contour edges of the primitive mesh, such as double/zero hits, regardless of the winding order of the two primitives sharing the contour edge. For example, in fig. 3a, no artifacts are rendered within the interior of the primitive mesh (i.e., not on the contour boundary). In particular, even if the primitive 306 has an inconsistent winding order with respect to other primitives, no artifacts are rendered on the edges of the primitive. However, on the left contour shared edge (i.e., the edge shared by primitives 302 and 320), both primitives 302 and 320 will be determined to be hit by rays that precisely intersect the shared edge, as indicated by the dashed black and middle gray shadows. On the right contour shared edge (i.e., the edge shared by primitives 310 and 312), neither primitive 310 or 312 is determined to be hit by a ray that exactly intersects the shared edge, as indicated by the light gray shading of the dashed line.
Fig. 3a shows the result of a scheme implementing the upper left rule as described above. Assuming that rules are consistently used for all intersections, different rules (e.g., lower left, upper right, lower right, upper left, upper right, lower left, and lower right rules) may be used, and this will still maintain non-redundant tight intersection determinations within the primitive mesh interior, but will still result in a lack of non-redundant tightness on the contour edges of the primitive mesh.
Fig. 3b shows the same primitive mesh as that shown in fig. 3a, forming a circular band (i.e. ring-shaped) with appropriate shading to indicate which edges are considered part of each primitive in the "wrapping/orientation dependency" scheme. To modify the "wrapping/orientation independence" scheme to the "wrapping/orientation dependency" scheme (and vice versa), if a ray intersects an edge of a primitive (e.g., if the 2D cross product of the edge is zero), then the same method can be used to perform the intersection test, but a post-processing XOR operation is added to the primitive intersection determination by the indication of the primitive orientation. In this way, when a ray intersects an edge of a primitive, the intersection determination for the primitive is selectively reversed, depending on the orientation of the primitive (from the viewpoint of the ray). For example, by comparing FIG. 3b with FIG. 3a, we can see that on the shared edge, the intersection determination in FIG. 3b is the same as in FIG. 3a for primitives having a clockwise orientation, but the intersection determination in FIG. 3b is opposite to the intersection determination in FIG. 3a for primitives having a counterclockwise orientation.
It should be noted that the shared contour edge between primitives 302 and 320 and the shared contour edge between primitives 310 and 312 return a single hit only in the wrapping/orientation dependency scheme shown in FIG. 3 b. However, because of the inconsistent winding order of primitive 306 relative to other primitives, for inconsistent shared edges between primitives 304 and 306, both primitives will be determined to be hit by rays that precisely intersect the shared edge. Similarly, for a shared edge that is inconsistent between primitives 306 and 308, both primitives will be determined to be hit by a ray that exactly intersects the shared edge. In other examples not shown in fig. 3b, zero hits may occur on shared edges inside the primitive mesh (i.e., not on the contour boundaries) due to inconsistent wrapping. For the "wrap/orientation dependency" approach, two/zero hits may cause render redundancy/artifacts at the locations on such shared edges, respectively.
The occurrence of rendering redundancy/artifacts of the type shown in fig. 3a and 3b is difficult to universally eliminate, but they may be repositioned such that they occur only at the contour edges of the primitive mesh (as in fig. 3 a), or such that they occur only on shared edges between primitives with non-uniform wrapping (as in fig. 3 b). Visual artifacts at the contour edges of the geometry in the rendered image are less noticeable to an observer of the rendered image than in the middle of the object, e.g., in the case of a zero hit, the visual artifacts in the middle of the object may give the appearance of an object with holes therein such that background colors or occluded geometries can be seen through the object. Despite the improvement of visual artifacts, presentation redundancy in the form of double hits still occurs. Thus, in general, in some cases, moving possible rendering artifacts to contour edges by using a wrapping/orientation independent scheme (as in fig. 3 a) may be considered preferable.
If a consistent winding order of the submitted primitives, e.g. an orientable surface, e.g. a loop, is expected (or even guaranteed), a "winding/orientation dependency" scheme (as shown in fig. 3 b) may be preferred. However, if an inconsistent winding order of the submitted primitives is expected (or even unavoidable, e.g., non-orientable surfaces such as Mobius (Mobius) strips), a "winding/orientation independence" scheme (as shown in fig. 3 a) may be preferred.
Fig. 4a shows primitive intersection test cell 114 within intersection test module 108. The primitive intersection test unit includes intersection determination logic 402 and intersection selection logic 404, which may be implemented in hardware (e.g., fixed function circuitry), software, firmware, or a combination thereof. Intersection determination logic 402 is configured to receive ray data for a ray and primitive data defining a new primitive to be tested for intersections with the ray. The ray data may include the origin and direction vectors of the ray, as well as other information associated with the ray, such as a maximum culling distance and/or a minimum culling distance. The primitive data may include location data for primitive vertices (e.g., projected into 2D space, such as space with P and Q axes as described above). Intersection determination logic 402 is configured to perform intersection tests to determine whether a ray intersects a primitive according to a non-redundant, rigorous scheme as described above. The intersection determination logic 402 includes distance calculation logic 406 configured to calculate an intersection distance of the determined intersection. The intersection distance of an intersection may be expressed as t (which may be referred to herein as t) in the equation of the ray (r (t) =o+dt) at which the intersection occurs int ) Is a value of (2). When a hit (i.e., an intersection) of a ray with a new primitive is found, then an indication of the intersection is provided from the intersection determination logic 402 to the intersection selection logic 404 along with data related to the intersection. Intersection data includes intersection distance (e.g., an indication of the value of t in the equation for the ray in which the intersection occurred), as well as other data, such as barycentric coordinates that may indicate the location on the primitive in which the intersection occurred, and the orientation of the intersecting primitive. If a ray has been found to intersect a previous primitive, then the intersection selection logic 404 compares the intersection data of the new intersection with the intersection data of the previous intersection and selects one of the intersections to remain (with the other intersection discarded). The selected intersection may be compared to subsequent intersections found for the ray. The intersection selection logic 404 will desirably select to preserve the closer of the two intersections compared, as indicated by the intersection distance of the two primitives. When the intersection of a ray with all of the primitives it is to test has been tested for, then it is most recentThe selected intersection is the intersection that is ultimately determined for the ray, e.g., which represents the closest intersection of the ray with the primitive in the scene. This selected intersection may be used to render an image of the scene (e.g., by executing a shader program as described above with respect to the intersection with reference to processing logic 110 shown in fig. 1).
FIG. 4b is a high-level flow chart illustrating an intersection test procedure for rays in a ray tracing system, where the intersection of a ray with multiple primitives (referred to as "candidate primitives") is tested. In step S412, the intersection test module 108 determines whether any remaining candidate primitives will be tested for intersection with the ray, for example using a list of remaining candidate primitives that will still be tested for intersection with the ray. If so, the method goes to step S414, and if not, the method goes to step S426.
In step S414, the intersection test module 108 obtains a candidate primitive and removes the candidate primitive from the remaining candidate primitive list for the ray.
In step S416, the intersection test module 108 determines whether the ray intersects a candidate primitive. If the ray did intersect a candidate primitive, the method proceeds to step S418, and if the ray did not intersect a candidate primitive, the method proceeds back to step S412 so that the ray may be tested for the next candidate primitive (if any) for the ray.
In step S418, the intersection test module 108 determines an intersection distance at which the ray intersects the candidate primitive.
In step S420, the intersection test module 108 determines whether the intersection distance is between the minimum culling distance and the maximum culling distance. If the intersection distance is between the minimum culling distance and the maximum culling distance (either not including any of the minimum distance and the maximum distance itself, or including both of the minimum distance and the maximum distance itself), then the method proceeds to step S422, whereas if the intersection distance is not between the minimum culling distance and the maximum culling distance (either not including any of the minimum distance and the maximum distance itself, or including both of the minimum distance and the maximum distance itself), then the method returns to step S412 so that the ray may be tested for the next candidate primitive (if any) of the ray.
In step S422, the intersection test module 108 determines if there has been a previous intersection with another primitive determined for the ray. If a previous intersection with another primitive has been determined for the ray, the method passes to step S424. If a previous intersection with another primitive is not determined for the ray, then the intersection distance for the current intersection is stored and the method returns to step S412 so that the ray may be tested for the next candidate primitive (if any) for the ray.
In step S424, the intersection test module 108 determines which intersection is reserved, i.e., the current intersection of the ray or the previously determined intersection. Typically, more recent ones of the intersections will be selected to remain. Details of how the determination of which intersection is to be preserved may be performed will be described below with reference to the flowcharts of fig. 5, 8, and 10. After step S424, the method returns to step S412 so that the ray may be tested for the next candidate primitive (if any) for the ray.
As described above, if it is determined in step S412 that no candidate primitives remain to be tested for intersection with the ray, the method passes to step S426. In step S426, it is determined whether an intersection has been found for the ray. If an intersection has been found for the ray, the method passes to step S428, and if no intersection has been found for the ray, the method passes to step S430. In step S428, the intersection is reported. In step S430, a miss is reported.
It can be seen that in the method shown in FIG. 4b, the intersection of a ray with multiple candidate primitives is tested and compared such that one intersection is reserved for the ray. The following description provides examples of how two intersections of a ray with two corresponding primitives may be compared such that one of the intersections may be selected (e.g., for rendering an image of a 3D scene in a ray tracing system).
Pre-culling of primitives that fall outside of the user-supplied range of distances may be performed at the intersection determination logic 402 orThe intersection selection logic 404, or in an intermediate stage of its own (not shown in fig. 4a, but shown as step S420 in fig. 4 b). The distance range may be given as [ t ] min ,t max ]、(t min ,t max )、[t min ,t max ) Or (t) min ,t max ]Where a range is indicated, it is noted that brackets indicate that the end point is included within the range and brackets indicate that the end point is excluded from the range. This culling may be considered part of the "hit" determination output from the intersection determination sub-stage, i.e., hit&＝(t min ≤t int ≤t max ) Or hit&＝(t min <t int <t max ) Or hit&＝(t min ≤t int <t max ) Or hit&＝(t min <t int ≤t max ) And therefore unless the value t max The comparison used to store the intersection distance of the previous intersection primitive as an input to the intersection selection, otherwise the culling is independent of the intersection selection, in which case the criterion less than or equal to or less than may be replaced by the comparison logic of the intersection selection logic 404 described herein. Similarly, if t min The comparison of less than or equal to or less than for processing transparent and/or translucent geometries may be replaced by comparison logic of intersection selection logic 404 as described herein.
However, it is possible to find that a ray intersects two (or more) primitives at the same intersection distance, such as when the ray intersects a shared edge or shared vertex of two (or more) primitives. The non-redundant tight intersection test performed by the intersection determination logic 402 reduces the cases where multiple intersections are found at the same intersection distance. However, even when the intersection determination logic uses the non-redundant tight intersection test scheme described above, there are still some situations in which double intersections can be found on the shared edges of the primitives, and in which the two intersection distances are equal. Because the intersection determination logic 402 only partially considers primitives, it cannot eliminate all situations where double intersection may occur, e.g., consider a single primitive at a time if it is implemented as a "single tester," or consider a pair of primitives at a time if it is implemented as a "double tester," etc. For example, in the wrap/orientation independence example shown in FIG. 3a, a double intersection would be found when a ray intersects the left contour edge of the primitive band (i.e., the edge shared by primitives 302 and 320), while in the wrap/orientation dependence example shown in FIG. 3b, a double intersection would be found when a ray intersects the edge shared by primitives 304 and 306, and when a ray intersects the edge shared by primitives 306 and 308.
Enabling backface culling may be used to address some of the double intersections (e.g., on the left contour side of the example shown in fig. 3 a), but the user may choose not to enable backface culling for one of many reasons, such as potential gain in traversal speed (since the backface geometry of an intersection may result in more culling due to earlier box loss), and/or to provide support for rays within the surface to simulate effects such as refraction and subsurface scattering. It would therefore be beneficial to have a method that can address double intersection without enabling backface culling.
In the example shown in fig. 3a and 3b, a problem case of double intersection occurs on a shared edge when two primitives sharing the edge have different orientations. Orientation is a view-dependent property, i.e. it depends on primitives and rays. In the wrapping/orientation independent example shown in fig. 3a, wrapping of primitives 302 and 320 is consistent, but from a ray perspective, the orientations of the two primitives are different because primitive 302 is forward facing and primitive 320 is backward facing. Thus, as shown in FIG. 3a, primitives 302 and 320 have different orientations, particularly primitive 302 has a clockwise orientation and primitive 320 has a counter-clockwise orientation. In the wrapping/orientation-dependent example shown in FIG. 3b, the wrapping of primitive 306 is not consistent with the wrapping of other primitives in the mesh, and therefore, from a ray's perspective, the orientation of primitive 306 is different from the orientation of primitives 304 and 308. Specifically, primitives 304 and 308 have a clockwise orientation and primitive 306 has a counter-clockwise orientation.
In the examples described herein, if the intersection determination logic 404 finds a double intersection (e.g., using one of the redundant rigorous intersection test schemes described above), the intersection selection logic 406 may select one of the intersections based on the orientation of the intersected primitives. For example, an intersection with a forward facing primitive may be prioritized over an intersection with a backward facing primitive. The user may provide a flag to indicate whether the forward facing primitive has a clockwise or counter-clockwise orientation.
Fig. 5 shows a flow chart of a first method of performing intersection testing in ray tracing system 100. The method shown in fig. 5 is performed on the light by the intersection test module 108, for example by the primitive intersection test unit 114.
In step S502, the intersection determination logic 402 determines whether the ray intersects the first primitive. For example, step S502 may involve implementing a non-redundant tight intersection test scheme, such as a winding/orientation independence scheme or a winding/orientation dependency scheme as described above. If it is determined in step S502 that the ray did intersect the first primitive, the method transitions from step S502 to step S504, and if it is determined in step S502 that the ray does not intersect the first primitive, the method transitions from step S502 to step S510.
In step S504, the intersection determination logic 402 (e.g., distance calculation logic 406) determines an intersection distance (t) at which the ray intersects the first primitive int,1 ). The intersection determination logic may also determine other intersection data regarding the intersection of the ray with the first primitive, such as barycentric coordinates indicating where on the first primitive the intersection occurred, and the orientation of the first primitive. The intersection distance (t) determined for the intersection of the ray with the first primitive in step S504 int,1 ) And other intersection data from intersection determination logic 402 to intersection selection logic 404.
In step S506, the intersection determination logic 402 determines whether the ray intersects a second primitive. For example, step S506 may involve implementing a non-redundant tight intersection test scheme, such as a winding/orientation independence scheme or a winding/orientation dependency scheme as described above. If it is determined in step S506 that the ray did intersect the second primitive, the method transitions from step S506 to step S508, and if it is determined in step S506 that the ray does not intersect the second primitive, the method transitions from step S506 to step S510. Step S506 may be performed immediately after step S504, or some other process may be performed between steps S504 and S506.
In step S508, the intersection determination logic 402 (e.g., distance calculation logic 406) determines an intersection distance (t) at which the ray intersects the second primitive int,2 ). The intersection determination logic may also determine other intersection data about the intersection of the ray with the second primitive, such as barycentric coordinates indicating where on the second primitive the intersection occurred, and the orientation of the second primitive. The intersection distance (t) determined for the intersection of the ray with the second primitive in step S508 int,2 ) And other intersection data from intersection determination logic 402 to intersection selection logic 404. After step S508, the method proceeds to step S512.
In step S510, which is performed when the intersection determination logic 402 determines that the ray does not intersect a primitive, the intersection test module then continues with other processing, such as by testing the intersection of the ray with another primitive (e.g., by looping back to step S502 or step S506 for the next primitive), or by testing the intersection of a different ray with a primitive.
In step S512, which is performed when the intersection determination logic 402 determines that the ray intersects the first primitive and the second primitive, the intersection selection logic 404 determines an intersection distance (t int,1 ) Whether or not the intersection distance (t int,2 ). If it is determined that t in step S512 int,1 ＝t int,2 The method proceeds from step S512 to step S514. If it is determined that t in step S512 int,1 ≠t int,2 The method proceeds from step S512 to step S520.
In step S514, the intersection selection logic 404 determines whether the orientations of the first primitive and the second primitive are the same. If it is determined in step S514 that the orientations of the first and second primitives are different, the method proceeds from step S514 to step S516. If it is determined in step S514 that the orientations of the first and second primitives are the same, the method proceeds from step S514 to step S518.
Thus, if t is determined int,1 ＝t int,2 And the orientation of the first primitive and the second primitive are different, the method will perform step S516. In step S516, the intersection selection logic 404 selects an intersection of the ray with one of the first primitive and the second primitive based on the one of the first primitive and the second primitive having the particular orientation. For example, a "particular orientation" may be an orientation (clockwise or counterclockwise) corresponding to a forward facing primitive. In other examples, the particular orientation may be an orientation corresponding to a backward facing primitive. As mentioned above, the user may set an indication (e.g., a flag) to indicate whether the face forward corresponds to clockwise or counterclockwise (and, accordingly, whether the face backward corresponds to counterclockwise or clockwise). In some systems, the correspondence between forward/backward facing primitives and clockwise/counterclockwise orientations may be predetermined without requiring the user to set an indication (e.g., a flag).
The "particular orientation" generally corresponds to the orientation of the primitive as observed by the ray tested for the primitive. In a first sense, the "forward facing orientation" flag may be set to the orientation of the primitive as observed by the light ray tested for the primitive. In a first sense, a "particular orientation" is generally equal to a "forward-facing orientation". In a second sense, the "forward facing orientation" can be set to the orientation of the primitive as observed by light rays originating outside the surface (when this is well defined) regardless of the actual light rays tested for the primitive. In a second sense, the "specific orientation" is typically set to a "forward facing orientation" for light rays originating from outside the surface, and a "backward facing orientation" for light rays originating from inside the surface.
Selected intersection data (i.e., intersection data for the selected intersection) is output from intersection selection logic 404. After step S516, the method goes to step S522.
If it is determined that t int,1 ＝t int,2 And the orientation of the first and second primitives is the same, the method will perform step S518. In step S518, the intersection selection logic 404An intersection of the ray with one of the first primitive and the second primitive is selected using a deterministic back tie breaking rule. For example, the intersection selection logic 404 may select an intersection of the ray with one of the first primitive and the second primitive based on a unique primitive ID associated with the first primitive and the second primitive. Each of the primitives processed by intersection test module 108 can have a unique primitive ID, or alternatively, primitive IDs can be derived from the order in which the primitives are submitted to the system (which may not be the same order for ray test primitives due to acceleration structure). In this way, the primitive ID is used as a second tie-breaking rule used as a fallback in the case where intersections cannot be distinguished by a non-redundant tight intersection test or by selecting an intersection based on the orientation of the intersecting primitive. This second tie-breaking rule is determined, so that the combined tie-breaking rule (i.e., orientation-based tie-breaking and back-off of the tie-breaking based on primitive ID) is also determined, i.e., it is independent of the processing order of the primitives. This certainty means that a stable result (i.e., the same result) is obtained regardless of the order in which the primitives intersect for the ray test. In other examples, a different fallback tie breaking technique may be used in step S518. Any exactly strict order on the primitives will suffice. Primitive selection is determined if the tie-breaking rule encodes a perfectly strict ordering of primitives. Selected intersection data (i.e., intersection data for the selected intersection) is output from intersection selection logic 404. After step S518, the method goes to step S522.
If it is determined that t int,1 ≠t int,2 The method will perform step S520. In step S520, the intersection selection logic 404 selects an intersection of the ray with the one of the first primitive and the second primitive having the smaller intersection distance. Thus, if t int,1 <t int,2 Then in step S520, intersection selection logic 404 selects an intersection with the first primitive, if t int,2 <t int,1 Then in step S520, the intersection selection logic 404 selects an intersection with the second primitive. The selected intersection data (i.e., the intersection data of the selected intersection) is output from intersection selection logic 404. After step S520, the method goes to step S522.
In step S522, the selected intersection is used in a ray tracing system to render an image of the 3D scene. For example, step S522 may include determining whether there are more primitives to be tested for intersections with the ray, and if so, the method may loop back to step S506, which may then be performed for the next primitive (where the primitive involving the selected intersection of the ray is considered the "first primitive" and the next primitive is considered the "second primitive"). In this way, the intersection test module 108 can compare the data of the selected intersection of the ray with the subsequent intersection of the ray to determine which intersection is the most recent intersection of the ray. When the most recent intersection of the ray has been determined and step S522 determines that there are no more primitives to be tested for intersections with the ray, then the data of the most recent intersection of the ray may be passed to processing logic 110, which may execute a shader program to determine how to process the intersection. The final output of processing all of the rays in the ray tracing system may be a rendered image that may be used in any suitable manner, such as being displayed on a display, stored in memory, or transmitted to another device, to name a few examples.
The tie-breaking method (particularly steps S514 and S516) described above with reference to fig. 5 to distinguish intersections based on the orientation of the primitives involved in the intersection may be used to address double-intersections that cannot be resolved simultaneously in all cases using the non-redundant tight intersection test scheme described above. For example, as described above, fig. 3a shows the results of a non-redundant tight intersection test scheme using a wrapping/orientation independence technique, and it can be seen that there is a double intersection on the left contour edge. Fig. 6a shows a grid of primitives forming the same circular band (i.e. ring) as shown in fig. 3a, wherein primitives 602 to 620 are identical to corresponding primitives 302 to 320 shown in fig. 3a, with appropriate shading indicating which edges are considered part of each primitive. Fig. 6a shows the result of using the tie breaking method based on the orientation of the primitives when clockwise orientation is preferred (i.e. when "specific orientation" is clockwise), in this case (where the "wrapping/orientation independence" scheme is used). It can be seen that the left contour edge is now shown as the intersection of primitive 602, rather than the intersection of primitive 620, and thus a non-arbitrary primitive selection has been made, thus addressing the double intersection on this left contour edge. Specifically, in this example, intersection selection logic 404 selects an intersection with primitive 602 on this shared edge (and does not select an intersection with primitive 620 on this shared edge) because, from the perspective of the ray, primitive 602 has a clockwise orientation (which in this case is a "particular orientation") and, from the perspective of the ray, primitive 620 has a counterclockwise orientation (which in this case is not a "particular orientation"). In the example shown in fig. 6a, all double intersections are resolved.
Fig. 6b shows a grid of primitives forming the same circular band (i.e. ring) as shown in fig. 3a, wherein primitives 602 to 620 are identical to corresponding primitives 302 to 320 shown in fig. 3a, with appropriate shading indicating which edges are considered part of each primitive. Fig. 6b shows the result of using the tie breaking method based on the orientation of the primitives when the counter-clockwise orientation is preferred (i.e. when the "specific orientation" is counter-clockwise), in this case (where the "wrapping/orientation independence" scheme is used). It can be seen that the left contour edge is now shown as the intersection of primitive 620, rather than the intersection of primitive 602, and thus a non-arbitrary primitive selection has been made, thus addressing the double intersection on this left contour edge. Specifically, in this example, intersection selection logic 404 selects an intersection with primitive 620 on this shared edge (and does not select an intersection with primitive 602 on this shared edge) because, from the perspective of the ray, primitive 620 has a counter-clockwise orientation (which in this case is a "particular orientation") and, from the perspective of the ray, primitive 602 has a clockwise orientation (which in this case is not a "particular orientation"). In the example shown in fig. 6b, all double intersections are resolved. Both of the examples shown in fig. 6a and 6b address double intersection on the left contour edge, but there may be a preference for the example shown in fig. 6a because this has prioritized the orientation corresponding to most forward facing primitives of the mesh, indicating how the annulus should be oriented.
As another example, as described above, fig. 3b shows the results of a non-redundant tight intersection test scheme using a wrapping/orientation dependency technique, and it can be seen that there is a double intersection on the edges shared by primitives 304 and 306 and on the edges shared by primitives 306 and 308. Fig. 6c shows a grid of primitives forming the same circular band (i.e. ring) as shown in fig. 3b, wherein primitives 602 to 620 are identical to corresponding primitives 302 to 320 shown in fig. 3b, with appropriate shading indicating which edges are considered part of each primitive. Fig. 6c shows the result of using the tie breaking method based on the orientation of the primitives when clockwise orientation is preferred (i.e. when the "specific orientation" is clockwise), in this case (where the "wrap/orientation dependency" scheme is used). It can be seen that the edges shared by primitives 604 and 606 are now shown as intersections of primitive 604, rather than intersection of primitive 606, and thus non-arbitrary primitive selections have been made, thus addressing the double intersection of this shared edge. Specifically, in this example, intersection selection logic 404 selects an intersection with primitive 604 on this shared edge (and does not select an intersection with primitive 606 on this shared edge) because, from the perspective of the ray, primitive 604 has a clockwise orientation (which in this case is a "particular orientation") and, from the perspective of the ray, primitive 606 has a counterclockwise orientation (which in this case is not a "particular orientation"). Similarly, it can be seen that the edges shared by primitives 606 and 608 are now shown as intersections of primitive 608, rather than intersection of primitive 606, and thus non-arbitrary primitive selections have been made, thus addressing the double intersection of this shared edge. Specifically, in this example, intersection selection logic 404 selects an intersection with primitive 608 on this shared edge (and does not select an intersection with primitive 606 on this shared edge) because, from the perspective of the ray, primitive 608 has a clockwise orientation (which in this case is a "particular orientation"), and, from the perspective of the ray, primitive 606 has a counterclockwise orientation (which in this case is not a "particular orientation"). In the example shown in fig. 6c, all double intersections are resolved.
Fig. 6d shows a grid of primitives forming the same circular band (i.e. ring) as shown in fig. 3b, wherein primitives 602 to 620 are identical to corresponding primitives 302 to 320 shown in fig. 3b, with appropriate shading indicating which edges are considered part of each primitive. Fig. 6d shows the result of using the tie breaking method based on the orientation of the primitives when the counter-clockwise orientation is preferred (i.e. when the "specific orientation" is counter-clockwise), in this case (where the "wrap/orientation dependency" scheme is used). It can be seen that the edges shared by primitives 604 and 606 are now shown as the intersection of primitive 606, rather than the intersection of primitive 604, and thus non-arbitrary primitive selections have been made, thus addressing the double intersection of this shared edge. Specifically, in this example, intersection selection logic 404 selects an intersection with primitive 606 on this shared edge (and does not select an intersection with primitive 604 on this shared edge) because, from the perspective of the ray, primitive 606 has a counter-clockwise orientation (which in this case is a "particular orientation") and, from the perspective of the ray, primitive 604 has a clockwise orientation (which in this case is not a "particular orientation"). Similarly, it can be seen that the edges shared by primitives 606 and 608 are now shown as intersections of primitive 606, rather than intersections of primitive 608, and thus non-arbitrary primitive selections have been made, thus addressing the double intersection of this shared edge. Specifically, in this example, intersection selection logic 404 selects an intersection with primitive 606 on this shared edge (and does not select an intersection with primitive 608 on this shared edge) because, from the perspective of the ray, primitive 606 has a counter-clockwise orientation (which in this case is a "particular orientation") and, from the perspective of the ray, primitive 608 has a clockwise orientation (which in this case is not a "particular orientation"). In the example shown in fig. 6d, all double intersections are resolved. Both of the examples shown in fig. 6c and 6d solve the double intersection of the edges shared by primitives 604 and 606 and the edges shared by primitives 606 and 608, but there may be a preference for the example shown in fig. 6c because this has prioritized the orientation corresponding to most forward facing primitives of the grid, indicating how the annulus should be oriented.
In the example described above with reference to the method shown in fig. 5, the orientation-based tie-breaking rule is only valid when the intersection distances of the two intersections are equal (as determined in step S512). Problems may occur due to errors in the distance calculation (e.g., due to rounding of floating point values) even when the determined intersection distances are not exactly equal. For example, two theoretically equal distances may be output differently by primitive intersection sub-stages due to lack of numerical precision in primitive intersection determination and its subsequent error in distance computation. Furthermore, for the same reason, two theoretically nearly equal distances may have their relative sizes reversed (or become equal). Thus, even if the error in the distance calculation is small, the primitive that should follow another primitive may actually be displayed in front of the other primitive. This problem is called "depth conflict" and it produces rendering artifacts in which primitives that should be occluded by another primitive are revealed (e.g., in part or in fragments). As mentioned above, enabling backface culling may avoid some of the problems caused by depth conflicts, especially around contour edges (which is where problems may often occur), but the user may not enable backface culling for the reasons outlined previously, thus another method for resolving depth conflicts is needed.
For example, when additional vertices of two primitives sharing the edge (where "additional vertices" are vertices that are not part of the shared edge) have coordinates with very different magnitudes, depth conflicts may occur for rays that intersect at or near the shared edge (e.g., at or near the contour boundary). The coordinate values may be represented in a floating point format. A primitive having another vertex with a high index value may cause a larger error in calculating the intersection distance than a primitive having another vertex with a low index value, because the error is typically associated with the largest input of the arithmetic operation.
To give an example of how the intersection distance of a ray with a primitive can be calculated, it should be noted again that ray r (t) can be represented as r (t) =o+dt, where O is a vector representing the origin of the ray and D is the direction vector of the ray. As described above, the center of gravity of the intersection is seatedThe labels (u, v, w) may be determined by the intersection determination logic 402. Intersection point r int Can be obtained by a method consisting of the barycentric coordinates (i.e. r int ＝uv 0 +vv 1 +wv 2 ) For three vertices (v) 0 ,v 1 ,v 2 ) Interpolation is performed to calculate. Given the origin O of the light, by r' int Given r int The position relative to the origin O of the light is r' int ＝r int -O. O and r int The euclidean distance between is the intersection distance and is defined by t' = |r int -O|＝|r′ int The I is given. If the intersection distance should be given as a (signed) multiple of the ray length (which is usually the preferred form), the final rescaled distance t int From the following componentsGiven that it is correct up to the sign. This is just one example of how the intersection distance of the intersections is calculated, and other methods may be used in other examples.
Fig. 7a and 7b show areas where depth conflicts are likely to be encountered in the example described above. In particular, fig. 7a shows that the same grid of primitives is formed as a circular band (i.e. ring) as shown in fig. 3a, wherein primitives 702 to 720 are identical to corresponding primitives 302 to 320 shown in fig. 3a in the winding/orientation independent example, with appropriate shading indicating which edges are considered part of each primitive. Similarly, fig. 7b shows that the same grid of primitives is formed as the circular band (i.e. ring) shown in fig. 3b, wherein primitives 702 to 720 are identical to corresponding primitives 302 to 320 shown in the winding/orientation dependent example in fig. 3b, with appropriate shading indicating which edges are considered part of each primitive. The areas that may encounter depth conflicts are indicated by shading and are represented as 722 and 724 in fig. 7a and 7 b. The positions of these regions depend only on the set of spaces defined by the geometry and not on their orientation, and are therefore the same for both the winding/orientation independent scheme and the winding/orientation dependent scheme, as shown in fig. 7a and 7b, respectively.
As mentioned above, intersections that are close to (or on) the contour boundary or shared edges between primitives that are at high acute angles to each other or very close to (or on) the contour boundary (e.g., contour edges or contour vertices) are likely candidates for depth collisions. It should be noted that regions 722 and 724 in fig. 7a and 7b include their respective shared edges.
Fig. 8 shows a flow chart of a second method of performing intersection testing in ray tracing system 100. The method shown in fig. 8 is performed on the light by the intersection test module 108, for example by the primitive intersection test unit 114.
Steps S802 to S810 are the same as steps S502 to S510 shown in fig. 5 and described above. Specifically, in step S802, intersection determination logic 402 determines whether the ray intersects the first primitive, for example using a non-redundant tight intersection test scheme, such as the winding/orientation independence scheme or the winding/orientation dependence scheme as described above. If it is determined in step S802 that the ray did intersect the first primitive, the method transitions from step S802 to step S804, and if it is determined in step S802 that the ray does not intersect the first primitive, the method transitions from step S802 to step S810.
In step S804, the intersection determination logic 402 (e.g., distance calculation logic 406) determines an intersection distance (t) at which the ray intersects the first primitive int,1 ). The intersection determination logic may also determine other intersection data regarding the intersection of the ray with the first primitive, such as barycentric coordinates indicating where on the first primitive the intersection occurred, and the orientation of the first primitive. The intersection distance (t) determined for the intersection of the ray with the first primitive in step S804 int,1 ) And other intersection data from intersection determination logic 402 to intersection selection logic 404.
In step S806, the intersection determination logic 402 determines whether the ray intersects the second primitive, for example using a non-redundant tight intersection test scheme, such as the wrapping/orientation independence scheme or the wrapping/orientation dependency scheme as described above. If it is determined in step S806 that the ray does intersect the second primitive, the method proceeds from step S806 to step S808, and if it is determined in step S806 that the ray does not intersect the second primitive, the method proceeds from step S806 to step S810. Step S806 may be performed immediately after step S804, or some other processing may be performed between steps S804 and S806.
In step S808, the intersection determination logic 402 (e.g., distance calculation logic 406) determines an intersection distance (t) at which the ray intersects the second primitive int,2 ). The intersection determination logic may also determine other intersection data about the intersection of the ray with the second primitive, such as barycentric coordinates indicating where on the second primitive the intersection occurred, and the orientation of the second primitive. The intersection distance (t) determined for the intersection of the ray with the second primitive in step S808 int,2 ) And other intersection data from intersection determination logic 402 to intersection selection logic 404. After step S808, the method proceeds to step S812.
In step S810, which is performed when the intersection determination logic 402 determines that the ray does not intersect a primitive, the intersection test module then continues with other processing, such as by testing the intersection of the ray with another primitive (e.g., by looping back to step S802 or step S806 for the next primitive), or by testing the intersection of a different ray with a primitive.
In step S812, the intersection selection logic 404 determines a first offset intersection distance (t off,1 ) The first offset intersection distance is equal to the intersection distance (t int,1 ) And a first offset (delta) dependent on the orientation of the first primitive 1 ) And (3) summing. For example, a first offset delta 1 May be non-zero, in which case step S812 may involve performing an addition (or subtraction) operation to add t int,1 And delta 1 Added together. First offset delta 1 May be positive or negative. First offset delta 1 Can be equal to t int,1 The relative offset of (a), i.e. the first offset, may be from the floating point value t int,1 Is proportional to the index of (c). For example, a first offset delta 1 May have an intersection distance t with which it is to be summed int,1 An index proportional to the index of (c). In some examples, the first offset δ 1 Can be zero, in which case t off,1 ＝t int,1 And step S812 will not involve execution ofAddition (or subtraction) operations. It should be noted that "subtracting a positive/negative first offset" is equivalent to "adding a negative/positive second offset", where the second offset is the negative of the first offset.
In step S814, the intersection selection logic 404 determines a second offset intersection distance (t off,2 ) The second offset intersection distance is equal to the intersection distance (t int,2 ) And a second offset (delta) dependent on the orientation of the second primitive 2 ) And (3) summing. For example, a second offset delta 2 May be non-zero, in which case step S814 may involve performing an addition (or subtraction) operation to add t int,2 And delta 2 Added together. Second offset delta 2 May be positive or negative. Second offset delta 2 Can be equal to t int,2 The relative offset of (a), i.e. the first offset, may be from the floating point value t int,2 Is proportional to the index of (c). For example, a second offset delta 2 May have an intersection distance t with which it is to be summed int,2 An index proportional to the index of (c). In some examples, the second offset δ 2 Can be zero, in which case t off,2 ＝t int,2 And step S814 will not involve performing an addition (or subtraction) operation. It should be noted that if the first offset (delta 1 ) Is non-zero, then use is made of the first offset (delta 1 ) Offsets with the same sign (and optionally the same mantissa) determine the offset intersection distance of any primitive having the same orientation as the first primitive. In addition, if the second offset (delta 2 ) Is non-zero, then a second offset (delta 2 ) Offsets with the same sign (and optionally the same mantissa) determine the offset intersection distance of any primitive having the same orientation as the second primitive. If the orientation of the first primitive is different from the orientation of the second primitive, a first offset (delta 1 ) Different from the second offset (delta) 2 ) For example, one offset may be zero and one offset may be non-zero.
If not a relative offset is used, but an absolute offset is used, the following may occur: (i) If the first offset (delta 1 ) Is non-zero, then use is made of the first offset (delta 1 ) Offsets with the same sign, mantissa and exponent to determineAn offset intersection distance of any primitive having the same orientation as the first primitive, and (ii) if the second offset (delta 2 ) Is non-zero, then an offset (delta) having the same sign, mantissa and exponent as the second offset is used 2 ) To determine an offset intersection distance for any primitive having the same orientation as the second primitive.
The intersection selection logic 404 then compares the determined first offset intersection distance with the determined second offset intersection distance (t off,1 And t off,2 ) To select an intersection of the ray with one of the first primitive and the second primitive. In this way, the intersection selection logic 404 identifies which of the determined first offset intersection distance and the determined second offset intersection distance is smaller and selects an intersection corresponding to the identified offset intersection distance.
Specifically, in step S816, the intersection selection logic 404 determines a second offset intersection distance (t off,2 ) Whether or not it is smaller than the first offset intersection distance (t off,1 ). If t off,2 <t off,1 The method goes from step S816 to step S818 and if t off,2 ≥t off,1 The method proceeds from step S816 to step S820.
In step S818 (if t off,2 <t off,1 Then this step is performed) the intersection selection logic 404 selects the intersection of the ray with the second primitive. Selected intersection data (i.e., intersection data for the selected intersection) is output from intersection selection logic 404. After step S818, the method goes to step S826.
In step S820 (if t off,2 ≥t off,1 Then this step is performed), the intersection selection logic 404 determines a first offset intersection distance (t off,1 ) Whether or not to be equal to the second offset intersection distance (t off,2 ). If t off,1 ≠t off,2 The method goes from step S820 to step S822 and if t off,1 ＝t off,2 The method proceeds from step S820 to step S824.
In step S822 (if t off,2 ＞t off,1 Then this step is performed), intersection selection logic 404 selects the ray and the first graphIntersection of the elements. Selected intersection data (i.e., intersection data for the selected intersection) is output from intersection selection logic 404. After step S822, the method goes to step S826.
In step S824 (if t off,2 ＝t off,1 Then this step is performed) the intersection selection logic 404 selects the intersection of the ray with one of the first primitive and the second primitive using a deterministic back tie breaking rule. For example, the intersection selection logic 404 may select an intersection of the ray with one of the first primitive and the second primitive based on a unique primitive ID associated with the first primitive and the second primitive. As described above, each of the primitives processed by the intersection test module 108 may have a unique primitive ID, or alternatively, the primitive IDs may be derived from the order in which the primitives were submitted to the system (which may not be the same order for ray test primitives due to the acceleration structure). In this way, the primitive ID is used as a second tie-breaking rule used as a fallback in the case where intersections cannot be distinguished by a non-redundant tight intersection test or by applying an orientation-dependent offset to the intersection distance. This second tie-breaking rule is also deterministic, i.e. it is independent of the processing order of the primitives. In other examples, a different fallback tie breaking technique may be used in step S824. As described above with respect to step S518, any exactly strict order on the primitives will suffice. Primitive selection is determined if the tie-breaking rule encodes a perfectly strict ordering of primitives. Selected intersection data (i.e., intersection data for the selected intersection) is output from intersection selection logic 404. After step S824, the method goes to step S826.
In step S826, an image of the 3D scene is rendered in the ray tracing system using the selected intersection. For example, step S826 may include determining whether there are more primitives to be tested for intersections with the ray, and if so, the method may loop back to step S806, which may then be performed for the next primitive (where the primitive involving the selected intersection of the ray is considered the "first primitive" and the next primitive is considered the "second primitive"). In this way, the intersection test module 108 can compare the data of the selected intersection of the ray with the subsequent intersection of the ray to determine which intersection is the most recent intersection of the ray. When the most recent intersection of the ray has been determined and step S826 determines that there are no more primitives to be tested for intersection with the ray, then the data of the most recent intersection of the ray may be passed to processing logic 110, which may execute a shader program to determine how to process the intersection. The final output of processing all of the rays in the ray tracing system may be a rendered image that may be used in any suitable manner, such as being displayed on a display, stored in memory, or transmitted to another device, to name a few examples.
In examples using absolute offsets, the same offset may be applied to all intersection distances of primitives having the same orientation. In examples using relative offsets, offsets having the same sign and mantissa but different exponents (e.g., exponents equal to the intersection distance to which they are to be applied) may be applied to all intersection distances of primitives having the same orientation. Different offsets are applied to the intersection distances of primitives with different orientations. If the first primitive has a particular orientation, then a first offset (delta 1 ) Less than if the first primitive had no particular orientation. Similarly, if the second primitive has a particular orientation, then a second offset (delta 2 ) Less than if the second primitive does not have a particular orientation. Offset delta 1 And delta 2 The difference between (when the first and second primitives have different orientations) represents a threshold, which may be represented as ε, where ε= |δ 1 -δ 2 | a. The invention relates to a method for producing a fibre-reinforced plastic composite. It should be noted that if we use a relative offset, the magnitude of the threshold epsilon will depend on the exponent values of both the first and second intersection distances, and thus epsilon is not necessarily a constant term. If the difference between the two intersection distances is less than the threshold value, and if the orientations of the primitives involved in the intersection are different, the selected intersection will be the intersection involving the primitive with the particular orientation (e.g., corresponding to the forward facing primitive). If the difference between the two intersection distances is less than the threshold and is non-zero, and if the orientations of the two primitives involved in the intersection are the same, then the selected intersection will be the one involved with the most significant The intersection of primitives with small intersection distances. If the difference between the two intersection distances is zero and if the orientations of the two primitives involved in the intersection are the same, the selected intersection will be the intersection involving the primitive selected by the back tie breaking technique. If the difference between the two intersection distances is equal to the threshold value and if the orientations of the two primitives involved in the intersection are different, the selected intersection will be the intersection involving the primitive with the smallest intersection distance, or the primitive selected by the back tie breaking technique, depending on whether the primitive with the closer or farther intersection distance has a particular orientation. If the difference between the two intersection distances is equal to the threshold value and if the orientations of the two primitives involved in the intersection are the same, the selected intersection will be the intersection involving the primitive with the smallest intersection distance. If the difference between the two intersection distances is greater than the threshold, then the selected intersection will be the intersection involving the primitive with the smallest intersection distance.
In the example shown in fig. 8, a first offset intersection distance (t off,1 ) Comprising determining an intersection distance (t int,1 ) And determines a second offset intersection distance (t off,2 ) Comprising determining an intersection distance (t int,2 ). Further, one or both of the following: (i) Determining a first offset intersection distance (t off,1 ) Comprising intersecting the ray with the first primitive at a determined intersection distance (t int,1 ) Offset by a first offset (delta) 1 ) And (ii) determining a second offset intersection distance (t off,2 ) Comprising intersecting the ray with the second primitive at a determined intersection distance (t int,2 ) Offset by a second offset (delta) 2 ). It should be noted that if the first offset (delta 1 ) Zero, the determined intersection distance (t int,1 ) Offset by a first offset (delta) 1 ) Equivalent to not performing the offset step. Similarly, if the second offset (delta 2 ) Zero, the determined intersection distance (t int,2 ) Offset by a second offset (delta) 2 ) Equivalent to not performing the offset step. In some examples, the offset of the primitives for one orientation is set to zero,so that some addition operations can be avoided. Specifically, in some examples where the first primitive and the second primitive have different orientations, (i) the first offset (δ 1 ) Is zero, and the second offset (delta 2 ) Is non-zero, or (ii) a second offset (delta) 2 ) Is zero and the first offset (delta 1 ) Is non-zero. In other examples where the first and second primitives have different orientations, (iii) the offset of the primitive with the particular orientation is zero and the offset of the primitive without the particular orientation is strictly positive, or (iv) the offset of the primitive without the particular orientation is zero and the offset of the primitive with the particular orientation is strictly negative.
It can be appreciated that in the method illustrated in fig. 8, based on the orientation of the intersecting primitives output from the intersection determination logic 402, the intersection selection logic 404 adds (smaller) absolute or (smaller) relative offsets (e.g., a smaller number of minimum precision Units (ULPs)) to the results of the intersection distance calculation. The offset may be added to one orientation or subtracted from the other, both methods having the same effect (i.e., primitive selection) in the relative order of the intersection distances. It should be noted that subtracting a positive offset is equivalent to adding a negative offset. In the case of a (smaller) relative offset, the offset may be added to the mantissa of the floating point value, which mantissa represents an intersection distance independent of the exponent of the floating point value. In this way, the magnitude of the offset depends on the exponent of the intersection distance.
By performing a shift in the direction of the ray using an offset, two adjacent but non-contiguous primitives can be pushed far enough to prevent depth conflicts. The minimum size of the offset (e.g., the minimum number of ULPs) may depend on the accuracy of the distance calculation performed by distance calculation logic 406 in intersection determination logic 402 (e.g., due to rounding) before any depth conflicts are resolved. Since the determination of hidden surface removal is reversed in the case of an unintentional event, if the magnitude of the relative offset (i.e., delta 1 And delta 2 Difference between them) is large, erroneous results may occur. Thus, the magnitude of the relative offset (i.e., δ 1 And delta 2 The difference between them) can be set to be conservatively small so that erroneous results rarely occur, but still a certain depth conflict is resolved.Alternatively, the magnitude of the relative offset (i.e., δ 1 And delta 2 The difference between) may be set to be conservatively large such that it resolves all depth conflicts at the cost of some erroneous results (e.g., at near-self-intersections). In particular, since it may not be feasible to evaluate the minimum relative offset (denoted as the optimal offset) sufficient to resolve all depth conflicts, a conservative large value may be employed, accepting that an excessive number of erroneous results may be elicited (e.g., at near-self-intersections).
Fig. 9a shows a grid of primitives forming the same circular band (i.e. ring) as shown in fig. 3a, wherein primitives 902 to 920 are identical to corresponding primitives 302 to 320 shown in fig. 3a, wherein a wrapping/orientation independence scheme is used for intersection testing, indicating which edges are considered part of each primitive by appropriate shading. Fig. 9a shows the (exaggerated) result of applying an offset to the intersection distance, wherein the offset of a primitive with a clockwise orientation is smaller than the offset of a primitive with a counter-clockwise orientation. In this way, clockwise orientation is prioritized, and it has the effect of shifting the counter-clockwise oriented primitives (relative to the clockwise oriented primitives) farther from the ray origin. Although intersection determination logic 402 finds the left contour edge (i.e., the edge shared by primitives 902 and 920) as a double intersection, intersection selection logic 404 may select the intersection with primitive 902 on the left contour edge (and not select the intersection with primitive 920) by comparing the offset intersection distances of the two primitives on the shared edge. As can be seen in fig. 9a, on the shared edge of the two primitives, the offset intersection distance of primitive 902 is less than the offset intersection distance of primitive 920.
Fig. 9b shows the same grid of primitives forming a circular band (i.e. ring) as shown in fig. 3b, wherein primitives 902 to 920 are identical to corresponding primitives 302 to 320 shown in fig. 3b, wherein a wrapping/orientation dependency scheme is used for intersection testing, indicating which edges are considered part of each primitive by appropriate shading. Fig. 9b shows the (exaggerated) result of applying an offset to the intersection distance, wherein the offset of a primitive with a clockwise orientation is smaller than the offset of a primitive with a counter-clockwise orientation. In this way, clockwise orientation is prioritized, and it has the effect of shifting the counter-clockwise oriented primitives (relative to the clockwise oriented primitives) farther from the ray origin. Note that the right contour edge is shown as an excluded edge (represented by the light gray dashed line of primitive 910) offset before the included edge (represented by the middle gray solid line of primitive 912). In fig. 9b, the two lines are visually combined at the overlap, but it should be appreciated that since the occluding edge of the primitive 910 is excluded, the ray passes through it to the containing edge of the following primitive 912. Although intersection determination logic 402 finds that the edges shared by primitives 904 and 906 and the edges shared by primitives 906 and 908 are double-intersecting, intersection selection logic 404 may select intersections with primitives 904 and 908 on these respective edges (and not select intersections with primitive 906) by comparing the offset intersection distances of the primitives on the shared edges. As can be seen in fig. 9b, the offset intersection distance of primitive 904 is less than the offset intersection distance of primitive 906 on the shared edge of the two primitives, and the offset intersection distance of primitive 908 is less than the offset intersection distance of primitive 906 on the shared edge of the two primitives.
In fig. 9a and 9b, the observer's angle is slightly above the ray origin. This means that the shift in the direction of the light due to the offset is visible in the figure, but from the light point of view the gaps seen between adjacent primitives of the grid are not visible, i.e. tightness is still ensured. Furthermore, fig. 9a and 9b only show cases where clockwise orientation is prioritized (i.e. the offset of a clockwise primitive is smaller than the offset of a counter-clockwise primitive). This is because prioritizing the counter-clockwise orientation would be an incorrect behavior for the example grid shown in the figure, as given by the orientation of most forward-facing primitives of the annulus, which indicates how the surface should be oriented. For example, consider the priority of a counterclockwise primitive by shifting all clockwise primitives away from the ray origin or shifting all counterclockwise primitives toward the ray origin would increase the depth conflict problem. In this case, the particular orientation is incorrect and the artifacts can be resolved by reversing the particular orientation (i.e., clockwise to counter-clockwise or counter-clockwise to clockwise). For surfaces, it is recommended that for light rays originating from outside the surface (e.g. camera light rays, reflected light rays, shadow light rays, ambient light blocking light rays, etc.), a specific orientation is set to the orientation observed by any light rays having an external origin (assuming this is well defined), and for light rays originating from inside the surface (e.g. refracted light rays, subsurface scattered light rays, etc.), a specific orientation is set to the orientation observed by any light rays having an internal origin (assuming this is well defined).
The intersection distance shifts are for the purpose of these offsets only for intersection selection performed by intersection selection logic 404. When the intersection distance is output from the primitive intersection test unit 114 (e.g., as part of the selected intersection data), then the non-shifted intersection distance is output for use by other portions of the ray tracing system, such as shader programs executed by the processing logic 110.
Shifting all primitives for a given orientation (e.g., clockwise) toward the ray origin, or shifting all primitives for the opposite orientation (e.g., counter-clockwise) away from the ray origin, and assuming that the selection of the particular orientation is correct, will not introduce unintended hidden surface removal unless there are primitives for both orientations that intersect as nearest (and back culling off), such as applying a map with counter-clockwise orientation to a surface with clockwise orientation (as observed by the same ray), which is the case can be avoided by ensuring that the surfaces in the scene have a matching winding order.
As an alternative to applying an offset to the intersection distance, the intersection selection logic 404 may instead determine whether the difference between the two intersection distances is less than or equal to a threshold (or, in some examples, less than a threshold), and if so, prioritize the intersection with a particular orientation (e.g., an orientation corresponding to a forward facing primitive). Specifically, FIG. 10 illustrates a flow chart of a third method of performing intersection testing in ray tracing system 100. The method shown in fig. 10 is performed on the light by the intersection test module 108, for example by the primitive intersection test unit 114.
Steps S1002 to S1010 are the same as steps S502 to S510 shown in fig. 5 and steps S802 to S810 as described above. Specifically, in step S1002, the intersection determination logic 402 determines whether the ray intersects the first primitive, for example using a non-redundant tight intersection test scheme, such as the wrapping/orientation independence scheme or the wrapping/orientation dependence scheme described above. If it is determined in step S1002 that the ray does intersect the first primitive, the method proceeds from step S1002 to step S1004, and if it is determined in step S1002 that the ray does not intersect the first primitive, the method proceeds from step S1002 to step S1010.
In step S1004, the intersection determination logic 402 (e.g., distance calculation logic 406) determines an intersection distance (t) at which the ray intersects the first primitive int,1 ). The intersection determination logic may also determine other intersection data regarding the intersection of the ray with the first primitive, such as barycentric coordinates indicating where on the first primitive the intersection occurred, and the orientation of the first primitive. The intersection distance (t) determined for the intersection of the ray with the first primitive in step S1004 int,1 ) And other intersection data from intersection determination logic 402 to intersection selection logic 404.
In step S1006, intersection determination logic 402 determines whether the ray intersects a second primitive, for example using a non-redundant tight intersection test scheme, such as the winding/orientation independence scheme or the winding/orientation dependency scheme described above. If it is determined in step S1006 that the ray did intersect the second primitive, the method transitions from step S1006 to step S1008, and if it is determined in step S1006 that the ray does not intersect the second primitive, the method transitions from step S1006 to step S1010. Step S1006 may be performed immediately after step S1004, or some other processing may be performed between steps S1004 and S1006.
In step S1008, the intersection determination logic 402 (e.g., distance calculation logic 406) determines an intersection distance (t) at which the ray intersects the second primitive int,2 ). The intersection determination logic may also determine other intersection data about the intersection of the ray with the second primitive, such as barycentric coordinates indicating where on the second primitive the intersection occurred, and the orientation of the second primitive. The intersection distance (t) determined for the intersection of the ray with the second primitive in step S1008 int,2 ) And other intersection data from intersection determination logic 402 to intersection selection logic 404. In step S1008 After that, the method proceeds to step S1012.
In step S1010, which is performed when the intersection determination logic 402 determines that the ray does not intersect a primitive, the intersection test module then continues with other processing, such as by testing the intersection of the ray with another primitive (e.g., by looping back to step S1002 or step S1006 for the next primitive), or by testing the intersection of a different ray with a primitive.
In step S1012, the intersection selection logic 404 determines an intersection distance (t int,1 ) And an intersection distance (t int,2 ) Whether the difference between them is less than or equal to a threshold epsilon. In other words, intersection selection logic 404 determines whether |t int,1 -t int,2 The I is less than or equal to epsilon. If |t int,1 -t int,2 From step S1012, the method goes to step S1014, and if |t int,1 -t int,2 I > epsilon, the method goes from step S1012 to step S1022. In this first case (using 'less than or equal to' comparison), the threshold epsilon is greater than or equal to zero. In some examples, step S1012 may involve intersection selection logic 404 determining an intersection distance (t int,1 ) And an intersection distance (t int,2 ) Whether the difference between them is smaller than a threshold epsilon. In other words, the intersection selection logic 404 may determine whether |t int,1 -t int,2 |<Epsilon. If |t int,1 -t int,2 |<ε, the method goes from step S1012 to step S1014, and if ε int,1 -t int,2 I ε, the method goes from step S1012 to step S1022. In this second case (using a 'less than' comparison), the threshold epsilon is greater than zero. Conceptually, the two methods of step S1012 (i.e. using a 'less than or equal to' comparison, and using a 'less than' comparison) are very similar, and for a fixed mantissa floating point format, a 'less than' comparison can be implemented as a 'less than or equal to' comparison by using a threshold epsilon 'that is reduced by one ulp (i.e. one minimum precision unit) relative to the threshold epsilon mentioned above, i.e. epsilon' =epsilon-ulp. Similarly, for a fixed mantissa floating point format, 'less than or equal to' ratioThe comparison may be implemented as ' less than ' by using a threshold epsilon ' that is increased by one ulp (i.e. one minimum accuracy unit) relative to the threshold epsilon mentioned above, i.e. epsilon "= epsilon + ulp.
In step S1014, the intersection selection logic 404 determines whether the orientations of the first primitive and the second primitive are the same. If it is determined in step S1014 that the orientation of the first primitive and the second primitive are different, the method transitions from step S1014 to step S1016. If it is determined in step S1014 that the orientation of the first primitive and the second primitive are the same, the method proceeds from step S1014 to step S1018.
Thus, if |t is determined int,1 -t int,2 ε (or alternatively, t) int,1 -t int,2 |<Epsilon) and the orientation of the first and second primitives are different, the method will perform step S1016. In step S1016, the intersection selection logic 404 selects an intersection of the ray with one of the first primitive and the second primitive based on the one of the first primitive and the second primitive having the particular orientation. For example, a "particular orientation" may be an orientation (clockwise or counterclockwise) corresponding to a forward facing primitive. In other examples, the particular orientation may be an orientation corresponding to a backward facing primitive. As mentioned above, the user may set an indication (e.g., a flag) to indicate whether the face forward corresponds to clockwise or counterclockwise (and, accordingly, whether the face backward corresponds to counterclockwise or clockwise). In some systems, the correspondence between forward/backward facing primitives and clockwise/counterclockwise orientations may be predetermined without requiring the user to set an indication (e.g., a flag). The "particular orientation" generally corresponds to the orientation of the primitive as observed by the ray tested for the primitive. In a first sense, the "forward facing orientation" flag may be set to the orientation of the primitive as observed by the light ray tested for the primitive. In a first sense, a "particular orientation" is generally equal to a "forward-facing orientation". In a second sense, the "forward facing orientation" can be set to the orientation of the primitive as observed by light rays originating outside the surface (when this is well defined) regardless of the actual light rays tested for the primitive. In the second sense, for The "specific orientation" is generally set to a "forward facing orientation" for light rays originating from outside the surface, and a "specific orientation" is generally set to a "rearward facing orientation" for light rays originating from inside the surface. Selected intersection data (i.e., intersection data for the selected intersection) is output from intersection selection logic 404. After step S1016, the method goes to step S1024.
If it is determined that |t int,1 -t int,2 ε (or alternatively, t) int,1 -t int,2 |<Epsilon) and the orientation of the first primitive and the second primitive are the same, the method will perform step S1018. In step S1018, the intersection selection logic 404 determines the intersection distance (t int,1 ) Whether or not the intersection distance (t int,2 ). If it is determined that t in step S1018 int,1 ＝t int,2 The method proceeds from step S1018 to step S1020. If it is determined that t in step S1018 int,1 ≠t int,2 The method proceeds from step S1018 to step S1022.
If t int,1 ＝t int,2 And the orientation of the first and second primitives is the same, the method will perform step S1020. In step S1020, the intersection selection logic 404 selects an intersection of the ray with one of the first primitive and the second primitive using a deterministic back tie breaking rule. For example, the intersection selection logic 404 may select an intersection of the ray with one of the first primitive and the second primitive based on a unique primitive ID associated with the first primitive and the second primitive. Each of the primitives processed by intersection test module 108 can have a unique primitive ID, or alternatively, primitive IDs can be derived from the order in which the primitives are submitted to the system (which may not be the same order for ray test primitives due to acceleration structure). In this way, the primitive ID is used as a second tie-breaking rule used as a fallback in the case where intersections cannot be distinguished by a non-redundant tight intersection test or by selecting an intersection based on the orientation of the intersecting primitive. This second tie-breaking rule is also deterministic, i.e. it is independent of the processing order of the primitives. In other examples In step S1020, a different back tie breaking technique may be used. As described above with respect to steps S518 and S824, any exact order on the primitives will suffice. Primitive selection is determined if the tie-breaking rule encodes a perfectly strict ordering of primitives. Selected intersection data (i.e., intersection data for the selected intersection) is output from intersection selection logic 404. After step S1020, the method goes to step S1024.
If it is determined that |t int,1 -t int,2 | > ε (or alternatively, |t) int,1 -t int,2 I ε) or if it is determined that the orientation of the first primitive and the second primitive are the same and t int,1 ≠t int,2 The method will perform step S1022. In step S1022, the intersection selection logic 404 selects an intersection of the ray with the one of the first primitive and the second primitive having the smaller intersection distance. Thus, if t int,1 <t int,2 In step S1022, intersection selection logic 404 selects an intersection with the first primitive if t int,2 <t int,1 Then in step S1022, the intersection selection logic 404 selects an intersection with the second primitive. Selected intersection data (i.e., intersection data for the selected intersection) is output from intersection selection logic 404. After step S1022, the method proceeds to step S1024.
In step S1024, an image of the 3D scene is rendered in the ray tracing system using the selected intersection. For example, step S1024 may include determining whether there are more primitives to be tested for intersections with the ray, and if so, the method may loop back to step S1006, which may then be performed for the next primitive (where the primitive involving the selected intersection of the ray is considered the "first primitive" and the next primitive is considered the "second primitive"). In this way, the intersection test module 108 can compare the data of the selected intersection of the ray with the subsequent intersection of the ray to determine which intersection is the most recent intersection of the ray. When the most recent intersection of the ray has been determined and step S1024 determines that there are no more primitives to be tested for intersection with the ray, then the data of the most recent intersection of the ray may be passed to processing logic 110, which may execute a shader program to determine how to process the intersection. The final output of processing all of the rays in the ray tracing system may be a rendered image that may be used in any suitable manner, such as being displayed on a display, stored in memory, or transmitted to another device, to name a few examples.
In all three of the examples detailed above (refer to the flowcharts in fig. 5, 8, and 10, respectively), if the difference between the intersection distance at which a ray intersects a first primitive and the intersection distance at which the ray intersects a second primitive satisfies a comparison condition with respect to a threshold value, and if the orientations of the first primitive and the second primitive are different, the intersection of the ray with one of the first primitive and the second primitive having a specific orientation is selected. That is, if the primitive orientations of the first primitive and the second primitive are different, an intersection of the ray with one of the first primitive and the second primitive having a particular primitive orientation is selected. In other words, if the orientation of the first primitive as a whole is different from the orientation of the second primitive as a whole, then the intersection of the ray with one of the first primitive and the second primitive having the particular orientation as a whole is selected. As mentioned above, the orientation of a primitive is a view-dependent property that depends on both the primitive and the ray. Thus, for different primitive orientations of the first primitive and the second primitive, when the same ray intersects each primitive, each primitive is intersected by the same ray traveling in that direction, one of the two primitives has a clockwise orientation and the other of the two primitives has a counter-clockwise orientation. For example, a first primitive may have a clockwise orientation and a second primitive may have a counter-clockwise orientation. The wrapping of the first graphical element may not coincide with the wrapping of the second graphical element. The first primitive may be a forward facing primitive and the second primitive may be a backward facing primitive. The comparison condition may be a 'less than' condition such that if a difference between an intersection distance at which the ray intersects the first primitive and an intersection distance at which the ray intersects the second primitive is less than a threshold value, and if the orientations of the first primitive and the second primitive are different, then the ray is selected to have in the first primitive and the second primitive Intersection of one of the specific orientations. The comparison condition may be a 'less than or equal to' condition such that if a difference between an intersection distance at which the ray intersects the first primitive and an intersection distance at which the ray intersects the second primitive is less than or equal to a threshold value, and if the orientations of the first primitive and the second primitive are different, an intersection of the ray with one of the first primitive and the second primitive having a particular orientation is selected. This concept is used in all three examples to resolve double intersections and reduce the impact of depth conflicts. In a first example (described with reference to fig. 5), the threshold is zero and the threshold comparison is implemented as a "less than or equal to" comparison, while in a second and third example (described with reference to fig. 8 and 10), the threshold is non-zero (e.g., strictly positive). In a second example (described with reference to fig. 8), the threshold comparison is implemented as a "less than" comparison with respect to ε, where ε= |δ in this example 1 -δ 2 | a. The invention relates to a method for producing a fibre-reinforced plastic composite. In a third example (described with reference to fig. 10), the threshold comparison is implemented as a "less than or equal to" or "less than" comparison, depending on the first or second version of the method used as described above. A "particular orientation" may be an orientation corresponding to the orientation of the forward facing primitive. In other words, in some examples, the primitives with the particular orientation are forward-facing primitives and the primitives with an orientation different from the particular orientation are backward-facing primitives. Further, in all three of the examples described in detail above (refer to flowcharts in fig. 5, 8, and 10, respectively), if the difference between the intersection distance at which the ray intersects the first primitive and the intersection distance at which the ray intersects the second primitive is greater than a threshold value, the intersection of the ray with the one of the first primitive and the second primitive having the smaller intersection distance is selected. Furthermore, in all three of the examples detailed above (referring to the flowcharts in fig. 5, 8, and 10, respectively), if the intersection distance of the ray with the first primitive is equal to the intersection distance of the ray with the second primitive, and if the orientations of the first primitive and the second primitive are the same, a back tie breaking rule is used, such as selecting one of the ray and the first primitive and the second primitive based on a unique primitive ID associated with the first primitive and the second primitive And (5) intersecting. That is, if the primitive orientations of the first primitive and the second primitive are the same, the primitive orientations of the first primitive and the second primitive are not used to select the intersection of the ray with one of the first primitive and the second primitive. Instead of selecting an intersection for one of the first and second primitives that has a particular primitive orientation, a back tie breaking rule is used. This means that for each of the three examples described above, the method includes determining whether the first primitive and the second primitive have the same primitive orientation, and (i) if the primitive orientations of the first primitive and the second primitive are different, selecting an intersection of the ray with one of the first primitive and the second primitive having the particular primitive orientation, and (ii) if the primitive orientations of the first primitive and the second primitive are the same, not selecting an intersection of the ray with one of the first primitive and the second primitive having the particular primitive orientation, but instead executing the fall-back tie breaking rule. In other words, if the primitive orientations of the first primitive and the second primitive are the same, the method involves selecting an intersection of the ray with one of the first primitive and the second primitive using a deterministic back tie-breaking rule, rather than selecting an intersection of the ray with one of the first primitive and the second primitive having a particular primitive orientation. Similarly, if the primitive orientations of the first primitive and the second primitive are different, the method involves selecting an intersection of the ray with one of the first primitive and the second primitive without applying a deterministic back tie breaking rule, instead selecting an intersection of the ray with one of the first primitive and the second primitive having a particular primitive orientation.
If the difference between the intersection distance of the ray with the first primitive and the intersection distance of the ray with the second primitive is equal to the threshold, then either (i) the intersection of the ray with the one of the first primitive and the second primitive having the particular orientation, (ii) the intersection of the ray with the one of the first primitive and the second primitive selected with respect to the tie-breaking rule (e.g., based on the unique primitive ID), or (iii) the intersection with the smaller intersection distance is selected. In a first example (described above with reference to FIG. 5, where the threshold is zero), if the ray intersects the first primitive and the second primitive at equal intersection distances (i.e., with a difference equal to zero), then unless the two orientationsThe same, otherwise, a primitive with a particular orientation is selected, in which case the tie-breaking rule is applied. In a second example (described above with reference to fig. 8, where the threshold ε= |δ 1 -δ 2 I), if the difference between the intersection distance of the ray with the first primitive and the intersection distance of the ray with the second primitive is equal to a threshold, and if the orientations are not the same and the primitive with the greater intersection distance has a particular orientation, then apply the tie-breaking rule, otherwise select the primitive with the smaller intersection distance. In the first version of the third example (when "less than or equal to" comparison is used as described above with reference to fig. 10), if the difference between the intersection distance at which the ray intersects the first primitive and the intersection distance at which the ray intersects the second primitive is equal to the threshold value, then the primitive having the particular orientation is selected unless the two orientations are the same, in which case the smaller intersection distance is selected. In a second version of the third example (when a "less than" comparison is used, as described above with reference to fig. 10), if the difference between the intersection distance of the ray intersecting the first primitive and the intersection distance of the ray intersecting the second primitive is equal to a threshold value, then the primitive with the smaller intersection distance is selected.
The first method (shown in fig. 5) and the third method (shown in fig. 10) involve: (a) determining that a difference between an intersection distance of the ray intersecting the first primitive and an intersection distance of the ray intersecting the second primitive meets a comparison condition with respect to a threshold (e.g., in step S512 or S1012), (b) determining that the orientations of the first primitive and the second primitive are different (e.g., in step S514 or S1014), and (c) selecting an intersection of the ray with one of the first primitive and the second primitive having a particular orientation (in step S516 or S1016) in response to determining that: (i) The difference between the intersection distance of the ray intersecting the first primitive and the intersection distance of the ray intersecting the second primitive satisfies a comparison condition with respect to a threshold, and (ii) the first primitive and the second primitive are oriented differently. In the first approach (shown in fig. 5), the threshold is zero, while in the third approach (shown in fig. 10), the threshold may be non-zero (e.g., strictly positive).
FIG. 11 illustrates a computer system in which a ray tracing system described herein may be implemented. The computer system includes a CPU 1102, a GPU 1104, memory 1106, and other devices 1114, such as a display 1116, speakers 1118, and a camera 1122. Ray traced unit 1110 (corresponding to ray traced unit 102) is implemented on GPU 1104 and Neural Network Accelerator (NNA) 1111. In other examples, ray tracing unit 1110 may be implemented on CPU 1102 or within NNA 1111, or as a separate processing unit in a computer system. The components of the computer system may communicate with each other via a communication bus 1120. Storage 1112 (corresponding to memory 104) is implemented as part of memory 1106.
The ray tracing system of fig. 1 is shown as comprising several functional blocks. This is merely illustrative and is not intended to limit the strict division between the different logic elements of such entities. Each of the functional blocks may be provided in any suitable manner. It should be understood that intermediate values described herein as being formed by the ray tracing system need not be physically generated by the ray tracing system at any point in time, and may represent only logical values that facilitate description of the processing performed by the ray tracing system between its inputs and outputs.
The ray tracing units, and in particular the intersection test modules described herein, may be embodied in hardware on an integrated circuit. The intersection test module described herein can be configured to perform any of the methods described herein. In general, any of the functions, methods, techniques, or components described above may be implemented in software, firmware, hardware (e.g., fixed logic circuitry) or any combination thereof. The terms "module," "functionality," "component," "element," "unit," "block," and "logic" may be used herein to generally represent software, firmware, hardware, or any combination thereof. In the case of a software implementation, the module, functionality, component, element, unit, block or logic represents program code that performs specified tasks when executed on a processor. The algorithms and methods described herein may be executed by one or more processors executing code that causes the processors to perform the algorithms/methods. Examples of a computer-readable storage medium include Random Access Memory (RAM), read-only memory (ROM), optical disks, flash memory, hard disk memory, and other memory devices that can store instructions or other data using magnetic, optical, and other techniques and that can be accessed by a machine.
The terms computer program code and computer readable instructions as used herein refer to any kind of executable code for a processor, including code expressed in a machine language, an interpreted language, or a scripting language. Executable code includes binary code, machine code, byte code, code defining an integrated circuit (such as a hardware description language or netlist), and code expressed in programming language code such as C, java or OpenCL. The executable code may be, for example, any kind of software, firmware, script, module, or library that, when properly executed, handled, interpreted, compiled, run in a virtual machine or other software environment, causes the processor of the computer system supporting the executable code to perform the tasks specified by the code.
The processor, computer, or computer system may be any kind of device, machine, or special purpose circuit, or a collection or portion thereof, that has processing capabilities such that instructions can be executed. The processor may be or include any kind of general purpose or special purpose processor, such as CPU, GPU, NNA, a system on a chip, a state machine, a media processor, an Application Specific Integrated Circuit (ASIC), a programmable logic array, a Field Programmable Gate Array (FPGA), or the like. The computer or computer system may include one or more processors.
The present invention is also intended to cover software defining a configuration of hardware as described herein, such as Hardware Description Language (HDL) software, for designing integrated circuits or for configuring programmable chips to perform desired functions. That is, a computer readable storage medium may be provided having encoded thereon computer readable program code in the form of an integrated circuit definition data set that, when processed (i.e., run) in an integrated circuit manufacturing system, configures the system to manufacture an intersection test module configured to perform any of the methods described herein, or to manufacture an intersection test module comprising any of the apparatus described herein. The integrated circuit definition data set may be, for example, an integrated circuit description.
Accordingly, a method of manufacturing an intersection test module as described herein at an integrated circuit manufacturing system may be provided. Furthermore, an integrated circuit definition data set may be provided that, when processed in an integrated circuit manufacturing system, enables a method of manufacturing an intersection test module to be performed.
The integrated circuit definition data set may be in the form of computer code, for example, as a netlist, code for configuring a programmable chip, as a hardware description language defining a device suitable for fabrication at any level in an integrated circuit, including as Register Transfer Level (RTL) code, as a high-level circuit representation (such as Verilog or VHDL), and as a low-level circuit representation (such as OASIS (RTM) and GDSII). A higher-level representation, such as RTL, logically defining hardware suitable for fabrication in an integrated circuit may be processed at a computer system configured to generate a fabrication definition of the integrated circuit in the context of a software environment that includes definitions of circuit elements and rules for combining these elements to generate a fabrication definition of the integrated circuit so defined by the representation. As is typically the case when software is executed at a computer system to define a machine, one or more intermediate user steps (e.g., providing commands, variables, etc.) may be required to configure the computer system to generate a manufacturing definition for an integrated circuit to execute code that defines the integrated circuit to generate the manufacturing definition for the integrated circuit.
An example of processing an integrated circuit definition data set at an integrated circuit manufacturing system to configure the system to manufacture intersection test modules will now be described with respect to fig. 12.
Fig. 12 illustrates an example of an Integrated Circuit (IC) manufacturing system 1202 configured to manufacture intersection test modules as described in any of the examples herein. Specifically, IC fabrication system 1202 includes layout processing system 1204 and integrated circuit generation system 1206.IC fabrication system 1202 is configured to receive an IC definition data set (e.g., defining an intersection test module as described in any of the examples herein), process the IC definition data set, and generate an IC from the IC definition data set (e.g., embodying the intersection test module as described in any of the examples herein). The processing of the IC definition data set configures the IC fabrication system 1202 to fabricate an integrated circuit embodying the intersection test module as described in any of the examples herein.
Layout processing system 1204 is configured to receive and process the IC definition data set to determine a circuit layout. Methods of determining a circuit layout from an IC definition dataset are known in the art and may involve, for example, synthesizing RTL codes to determine a gate level representation of a circuit to be generated, for example in terms of logic components (e.g., NAND, NOR, AND, OR, MUX and FLIP-FLOP components). By determining the location information of the logic components, the circuit layout may be determined from the gate level representation of the circuit. This may be done automatically or with the participation of a user in order to optimize the circuit layout. When the layout processing system 1204 has determined a circuit layout, the layout processing system may output the circuit layout definition to the IC generation system 1206. The circuit layout definition may be, for example, a circuit layout description.
As is known in the art, an IC generation system 1206 generates ICs from circuit layout definitions. For example, the IC generation system 1206 may implement a semiconductor device fabrication process that generates ICs, which may involve a multi-step sequence of photolithography and chemical processing steps during which electronic circuits are built up on wafers made of semiconductor material. The circuit layout definition may be in the form of a mask that may be used in a lithographic process for generating an IC from the circuit definition. Alternatively, the circuit layout definitions provided to the IC generation system 1206 may be in the form of computer readable code that the IC generation system 1206 may use to form a suitable mask for generating the IC.
The different processes performed by IC fabrication system 1202 may all be implemented in one location, e.g., by a party. Alternatively, IC fabrication system 1202 may be a distributed system, such that some processes may be performed at different locations and by different parties. For example, some of the following phases may be performed at different locations and/or by different parties: (i) Synthesizing an RTL code representing the IC definition dataset to form a gate level representation of the circuit to be generated; (ii) generating a circuit layout based on the gate level representation; (iii) forming a mask according to the circuit layout; and (iv) using the mask to fabricate the integrated circuit.
In other examples, processing the integrated circuit definition data set at the integrated circuit manufacturing system may configure the system to manufacture intersection test modules without processing the IC definition data set to determine a circuit layout. For example, an integrated circuit definition dataset may define a configuration of a reconfigurable processor, such as an FPGA, and processing of the dataset may configure the IC manufacturing system to generate (e.g., by loading configuration data into the FPGA) the reconfigurable processor having the defined configuration.
In some embodiments, the integrated circuit manufacturing definition data set, when processed in the integrated circuit manufacturing system, may cause the integrated circuit manufacturing system to generate an apparatus as described herein. For example, an apparatus as described herein may be manufactured by configuring an integrated circuit manufacturing system in the manner described above with reference to fig. 12 through an integrated circuit manufacturing definition dataset.
In some examples, the integrated circuit definition dataset may contain software running on or in combination with hardware defined at the dataset. In the example shown in fig. 12, the IC generation system may be further configured by the integrated circuit definition data set to load firmware onto the integrated circuit in accordance with the program code defined at the integrated circuit definition data set at the time of manufacturing the integrated circuit or to otherwise provide the integrated circuit with the program code for use with the integrated circuit.
Specific implementations of the concepts set forth in the present disclosure in devices, apparatus, modules, and/or systems (and in methods implemented herein) may provide improved performance over known specific implementations. Performance improvements may include one or more of increased computational performance, reduced latency, increased throughput, and/or reduced power consumption. During the manufacture of such devices, apparatuses, modules and systems (e.g., in integrated circuits), a tradeoff may be made between performance improvements and physical implementation, thereby improving the manufacturing method. For example, a tradeoff may be made between performance improvement and layout area, matching the performance of known embodiments, but using less silicon. This may be accomplished, for example, by reusing the functional blocks in a serial fashion or sharing the functional blocks among elements of a device, apparatus, module, and/or system. Rather, the concepts described herein that lead to improvements in the physical implementation of devices, apparatus, modules and systems, such as reduced silicon area, can be weighed against performance improvements. This may be accomplished, for example, by fabricating multiple instances of the module within a predefined area budget.
The applicant hereby discloses in isolation each individual feature described herein and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the present specification as a whole in light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the application.

Claims (19)

1. A computer-implemented method of performing intersection testing in a ray tracing system, the method comprising:
determining that a difference between an intersection distance at which a ray intersects a first primitive and an intersection distance at which the ray intersects a second primitive meets a comparison condition with respect to a threshold;
determining that the first primitive and the second primitive are oriented differently; and
an intersection of the ray with one of the first primitive and the second primitive is selected based on the one of the first primitive and the second primitive having a particular orientation.
2. The method of claim 1, wherein the comparison condition is satisfied with respect to the threshold if the difference between the intersection distance of the ray with the first primitive and the intersection distance of the ray with the second primitive is less than the threshold.
3. The method of claim 1, wherein the comparison condition is satisfied relative to the threshold if the difference between the intersection distance of the ray with the first primitive and the intersection distance of the ray with the second primitive is less than or equal to the threshold.
4. The method of any preceding claim, wherein the determining that the difference between the intersection distance of a ray intersecting a first primitive and the intersection distance of the ray intersecting a second primitive satisfies the comparison condition relative to the threshold comprises:
determining the intersection distance of the ray and the first primitive;
determining the intersection distance at which the ray intersects the second primitive; and
the determined intersection distances are compared.
5. A method as claimed in any preceding claim, wherein the threshold is non-zero.
6. A method as claimed in any preceding claim, wherein the primitives with the particular orientation are forward facing primitives, and wherein the primitives with an orientation different to the particular orientation are backward facing primitives.
7. A method as claimed in any preceding claim, further comprising determining that the ray intersects the first and second primitives.
8. The method of any preceding claim, further comprising:
the intersection of the ray with the one of the first primitive and the second primitive having the smaller intersection distance is selected if the difference between the intersection distance of the ray with the first primitive and the intersection distance of the ray with the second primitive does not satisfy the comparison condition relative to the threshold.
9. The method of any preceding claim, further comprising:
if the intersection distance of the ray with the first primitive is equal to the intersection distance of the ray with the second primitive, and if the orientations of the first primitive and the second primitive are the same, the intersection of the ray with one of the first primitive and the second primitive is selected based on a unique primitive ID associated with the first primitive and the second primitive.
10. The method of any preceding claim, further comprising rendering an image in the ray tracing system using the selected intersection.
11. An intersection test module for use in a ray tracing system, the intersection test module comprising:
intersection selection logic configured to:
determining that a difference between an intersection distance at which a ray intersects a first primitive and an intersection distance at which the ray intersects a second primitive meets a comparison condition with respect to a threshold;
determining that the first primitive and the second primitive are oriented differently; and
an intersection of the ray with one of the first primitive and the second primitive is selected based on the one of the first primitive and the second primitive having a particular orientation.
12. The intersection testing module of claim 11, wherein the comparison condition is satisfied with respect to the threshold if the difference between the intersection distance of the ray intersecting the first primitive and the intersection distance of the ray intersecting the second primitive is less than the threshold.
13. The intersection testing module of claim 11, wherein the comparison condition is satisfied with respect to the threshold if the difference between the intersection distance of the ray intersecting the first primitive and the intersection distance of the ray intersecting the second primitive is less than or equal to the threshold.
14. The intersection testing module of any of claims 11 to 13, further comprising intersection determination logic configured to:
determining that the ray intersects the first primitive and determining the intersection distance at which the ray intersects the first primitive; and
determining that the ray intersects the second primitive, and determining the intersection distance at which the ray intersects the second primitive.
15. An intersection testing module configured to perform the method of any of claims 1 to 10.
16. The intersection test module of any of claims 11 to 15, wherein the intersection test module body is present in hardware on an integrated circuit.
17. A method of manufacturing the intersection test module of any one of claims 11 to 16 using an integrated circuit manufacturing system.
18. A computer readable storage medium having stored thereon computer readable code configured to cause the method of any of claims 1 to 10 to be performed when the code is run.
19. A computer readable storage medium having stored thereon an integrated circuit definition data set that, when processed in an integrated circuit manufacturing system, configures the integrated circuit manufacturing system to manufacture the intersection test module of any of claims 11 to 16.
CN202310160870.4A 2022-02-25 2023-02-23 Intersection testing in ray tracing systems Pending CN116664747A (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
GB2202658.7 2022-02-25
GB2202659.5 2022-02-25
GB2202657.9 2022-02-25
GB2202659.5A GB2616053B (en) 2022-02-25 2022-02-25 Intersection testing in a ray tracing system

Publications (1)

Publication Number Publication Date
CN116664747A true CN116664747A (en) 2023-08-29

Family

ID=81075730

Family Applications (3)

Application Number Title Priority Date Filing Date
CN202310176941.XA Pending CN116664749A (en) 2022-02-25 2023-02-23 Intersection testing in ray tracing systems
CN202310160964.1A Pending CN116664748A (en) 2022-02-25 2023-02-23 Intersection testing in ray tracing systems
CN202310160870.4A Pending CN116664747A (en) 2022-02-25 2023-02-23 Intersection testing in ray tracing systems

Family Applications Before (2)

Application Number Title Priority Date Filing Date
CN202310176941.XA Pending CN116664749A (en) 2022-02-25 2023-02-23 Intersection testing in ray tracing systems
CN202310160964.1A Pending CN116664748A (en) 2022-02-25 2023-02-23 Intersection testing in ray tracing systems

Country Status (2)

Country Link
CN (3) CN116664749A (en)
GB (1) GB2616053B (en)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8059122B1 (en) * 2008-03-25 2011-11-15 The United States Of America As Represented By The Secretary Of The Air Force Cartesian mesh generation technique
US8988433B2 (en) * 2010-04-29 2015-03-24 Imagination Technologies, Limited Systems and methods for primitive intersection in ray tracing
US10692271B1 (en) * 2018-12-13 2020-06-23 Advanced Micro Devices, Inc. Robust ray-triangle intersection

Also Published As

Publication number Publication date
GB2616053B (en) 2024-02-21
CN116664748A (en) 2023-08-29
CN116664749A (en) 2023-08-29
GB2616053A (en) 2023-08-30
GB202202659D0 (en) 2022-04-13
GB2616053A9 (en) 2023-09-27

Similar Documents

Publication Publication Date Title
US11810239B2 (en) Methods and graphics processing units for determining differential data for rays of a ray bundle
US10970914B1 (en) Multiple precision level intersection testing in a ray tracing system
GB2537972A (en) Systems and methods for soft shadowing in 3-D rendering
US10861229B2 (en) Assembling primitive data into multi-view primitive blocks in a graphics processing system
CN115115757A (en) Intersection testing in ray tracing systems
US20220350606A1 (en) Performing comparison operations using vector floating point values
CN116664747A (en) Intersection testing in ray tracing systems
US11354835B2 (en) Rasterising aliased lines
EP4235587A1 (en) Intersection testing in a ray tracing system
CN115115760A (en) Intersection testing in ray tracing systems
GB2616051A (en) Intersection testing in a ray tracing system
GB2616052A (en) Intersection testing in a ray tracing system
CN115115759B (en) Intersection test method, intersection test module and medium in ray tracing system
US20220350566A1 (en) Performing comparison operations using extended exponent range floating point values
US20230031189A1 (en) Transformation of data in a ray tracing system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication