Apparatus, systems and methods for real-time, multi-resolution 3D collision detection using cube maps are disclosed. For example, a method is disclosed including receiving a first polygon, receiving a second polygon and then using a texture map stored in memory to detect collisions between the first and second polygons. Other implementations are also disclosed.
|
6. An apparatus comprising:
memory to store a cube map, the cube map comprising pixels storing distance values;
texture sampling logic to determine a first distance from an origin of a first polygon to a vertex of a second polygon along a direction vector, determine, along the direction vector, a second distance from the origin of the first polygon to a face of the first polygon using a third distance to a first point above the intersection of said direction vector with a cube map for said first polygon and a fourth distance to a second point below said intersection of said distance vector with said cube map and interpolating said third and fourth distances to obtain said second distance, compare the first and second distances, and detect a collision between the first and second polygons if the second distance is greater than or equal to the first distance, said cube map having six faces stored as six square textures and generated by rendering a scene six times from a viewpoint, with the views defined by an orthogonal ninety degree view frustrum representing each cube face.
1. An article comprising a non-transitory machine-accessible medium having stored thereon instructions that, when executed by a machine, cause the machine to:
determine a first distance from an origin of a first polygon to a vertex of a second polygon along a direction vector;
determine, along the direction vector, a second distance from the origin of the first polygon to a face of the first polygon using a third distance to a first point above the intersection of said direction vector with a cube map for said first polygon and a fourth distance to a second point below said intersection of said distance vector with said cube map and interpolating said third and fourth distances to obtain said second distance, said cube map having six faces stored as six square textures and generated by rendering a scene six times from a viewpoint, with the views defined by an orthogonal ninety degree view frustrum representing each cube face;
compare the first and second distances; and
detect a collision between the first and second polygons if the second distance is greater than or equal to the first distance.
2. The article of
3. The article of
4. The article of
determine the first distance corresponding to a distance from the origin to a vertex of the second polygon, the origin of the first polygon and the vertex of the second polygon defining a direction vector;
determine, along the direction vector the second distance corresponding to a distance from the origin of the first polygon to a face of the first polygon by employing a lookup to a texture address of the cube map; and
compare the first distance to the second distance.
5. The article of
generate the cube map by:
determining a centroid of the first polygon;
determining a plurality of distances from the centroid to all faces of the first polygon, wherein each distance of the plurality of distances is determined along a respective vector of a plurality of vectors, each vector of the plurality of vectors originating at the centroid and passing through a respective element of the texture map; and
store each distance of the plurality of distances as a value of the respective element of the texture map.
7. The apparatus of
8. The apparatus of
9. The apparatus of
10. The apparatus of
11. The apparatus of
|
Collision detection in three-dimensional (3D) graphics is the process of determining whether two objects, typically rigid bodies comprising linked polygons such as triangles, are in contact with each other. Usually this is done by having a processor implement an algorithm to calculate whether a triangle of one object conflicts spatially with a triangle of another object. Although there are a variety of approaches to this problem all standard solutions use the processor to execute calculations including testing for object-to-object collisions using a spatial data structure such as an octree and then undertaking a series of geometric calculations to assess polygon-to-polygon collisions for those objects whose bounding volumes are shown to be intersection candidates.
When implemented in a processor such as a central processing unit (CPU) these traditional approaches to collision detection can occupy significant computing resources that, particularly in a 3D gaming context, may be better spent in undertaking CPU-specific tasks such as physics calculations or implementing artificial intelligence routines. Moreover, by implementing collision detection in the CPU rather than a dedicated graphics processor such as a graphical processing unit (GPU) the traditional approaches fail to take advantage of the hardware primitives supported by modern graphics texture sampling hardware.
The accompanying drawings, incorporated in and constituting a part of this specification, illustrate one or more implementations consistent with the principles of the invention and, together with the description of the invention, explain such implementations. The drawings are not necessarily to scale, the emphasis instead being placed upon illustrating the principles of the invention. In the drawings,
The following description refers to the accompanying drawings. Among the various drawings the same reference numbers may be used to identify the same or similar elements. While the following description provides a thorough understanding of the various aspects of the claimed invention by setting forth specific details such as particular structures, architectures, interfaces, techniques, etc., such details are provided for purposes of explanation and should not be viewed as limiting. Moreover, those of skill in the art will, in light of the present disclosure, appreciate that various aspects of the invention claimed may be practiced in other examples or implementations that depart from these specific details. At certain junctures in the following disclosure descriptions of well known devices, circuits, and methods have been omitted to avoid clouding the description of the present invention with unnecessary detail.
Collision detection algorithm 102 may comprise a detection routine including any combination of software, and/or firmware that may be used to detect collisions between objects. Towards that end, algorithm 102 may provide texture sampler 104 with one or more lookup indices. Alternatively, algorithm 102 may provide shader 108 with one or more lookup indices and shader 108 may convey those indices to texture sampler 104. Sampler 104 may then use those indices to access distance data stored at corresponding texture addresses of a texture map held or stored in texture memory 106 as will be explained in greater detail below. Those skilled in the art will recognize that algorithm 102 may comprise a collision detection kernel spawned by a 3D graphics application (not shown) executing on a computing system that supports engine 100. Alternatively, algorithm 102 may comprise a collision detection kernel spawned by pixel shader 108. Those skilled in the art will further recognize that the terms objects, geometries, polygons, bodies and polyhedrons may be used interchangeably.
Texture sampler 104 may be any texture sampling logic comprising any combination of hardware, software, and/or firmware that is capable of accessing texture data in memory 106 in response to one or more lookup indices provided by algorithm 102. In accordance with implementations of the invention, the texture data stored in memory 106 and accessed by sampler 104 may include a texture map, such as a cube map, comprising an array of pixels (or “texels”) storing distance values as will be explained in greater detail below. Sampler 104 may then use the indices provided by algorithm 102 to determine associated texture addresses to be used to access the corresponding distance values stored and/or held in memory 106. Sampler 104 may then use those distance values to generate interpolated distance values and may provide those interpolated distance values to algorithm 102 as will be described in greater detail below. Alternatively, sampler 104 may provide those distance values to shader 108 and shader 108 may generate interpolated distance values and provide those interpolated distance values to algorithm 102.
Texture memory 106 may comprise any memory device or mechanism suitable for storing and/or holding one or more texture maps, such as one or more cube maps, specifying texel data such as distance values. While memory 106 may comprise any volatile or non-volatile memory technology such as Random Access Memory (RAM) memory or Flash memory, the invention is in no way limited by the type of memory employed for use as memory 106.
Process 200 may begin with the receipt of a first polygon [act 202] and the receipt of a second polygon [act 204]. In accordance with some implementations, acts 202 and 204 may, for example, involve collision detection algorithm 102 receiving the vertex coordinates of first and second triangles where those coordinates are defined, for example, with respect to a model coordinate system that may be implemented by a 3D graphics application (now shown). Such a 3D graphics application may spawn algorithm 102 and may supply algorithm 102 with geometric primitives, such as triangles.
Those skilled in the art may recognize that, as part of an overall collision detection process, algorithm 102 may have, prior to acts 202 and 204, already subjected 3D graphical objects to a trivial reject phase using a spatial data structure such as an octree or a kd-tree. In doing so, algorithm 102 may have determined that two objects, one including the first polygon of act 202 and another including the second polygon of act 204, have passed this trivial reject phase and thus are candidates for further collision detection testing. Details about the various methods of undertaking the trivial reject phase of a collision detection process are beyond the scope of the claimed invention and are well known in the art.
Process 200 may also include the generation of a texture map storing distance values [act 206]. In accordance with some implementations of the invention act 206 may be undertaken by application software in a preprocessing phase occurring prior to any other steps in process 200. In other implementations of the invention act 206 may be undertaken by application software in run time concurrent with other acts of process 200. Regardless, the invention is not limited by when act 206 is undertaken.
As those skilled in the art will recognize, coordinates for each pixel of 2D maps 404-409 may be indexed by a 3D direction vector 410 originating at an origin 412 of cube map 402. In some implementations of the invention origin 412 may correspond to the centroid of an object such as a polygon as will be explained in further detail below. The invention is not, however, limited to how origin 412 is defined and thus, for example, origin 412 may comprise the circumcenter of an object. Those skilled in the art will further recognize that a set of unique direction vectors may be defined such that each vector of the set of vectors passes through a corresponding pixel of one of 2D maps 404-409. For example, vector 410 passes through a pixel 414 of map 408, where map 408 corresponds to a +X face of cube map 402 and where pixel 414 may correspond to a specific (u,v) texture coordinate pair of map 402. Thus, vector 410 may be defined by origin 412 and the texture coordinate pair corresponding to pixel 414.
In accordance with some implementations of the invention, origin 412 may be the centroid of an object or the circumcenter of an object. However, the invention is not limited in this regard and, thus, origin 412 may comprise any point lying inside an object. Moreover, while the texture primitive employed in processes 200 and 300 may comprise a cube map primitive the invention is not limited in this regard and, thus, for example, processes 200 and 300 may be undertaken using other 3D texture primitives such as texture primitives employing more than six 2D faces or, for example, paraboloid or spherical texture primitives.
Process 300 may begin with the determination of an origin of the first polygon [act 302] where that polygon is the same polygon as that received in act 202 of process 200. Those skilled in the art will recognize the well known technique of determining a bounding sphere of a polygon as one way to determine an origin of a polygon in accordance with act 302. For the sake of discussion,
Those skilled in the art will recognize that bounding sphere 502 represents a hypothetical sphere that encompasses polygon 504 such that the scalar radius 505 of sphere 502 defines a maximum distance from the center 506 of the sphere to any point of polygon 504. When so defined, the center 506 of sphere 502 represents the centroid of polygon 504. Thus, as a result of act 302 an origin such as a centroid of the first polygon may be determined. As noted above, however, the invention is not limited to how the origin of an object is determined or defined. Thus, in accordance with the invention, any arbitrary means could be used to determine the origin of a 3D object to be processed by process 300.
Process 300 may continue with the receipt of a cube map primitive [act 304] where that primitive comprises six 2D arrays of texture pixels. As discussed above, cube maps are a well known type of 3D graphics primitive. Process 300 may then continue with the determination of distance values from the origin of the first polygon to intersection points with faces of the first polygon along directions originating at the origin and passing through pixels of the cube map [act 306].
While
Process 300 may continue with the storing of the distance values as pixel values of the cube map [act 308]. In accordance with some implementations of the invention, act 308 may involve storing each distance value determined in act 306 as the pixel value of the pixel lying along the direction associated with that distance value. For example, if act 306 includes determining distance value 620 associated with direction 616, then act 308 may involve storing distance value 620 as the pixel value of pixel P7 lying along direction 616. In some implementations of the invention those distance values determined in act 306 and stored in act 308 may comprise floating point values although the invention is not limited to the distance values having a particular data format.
Moreover, while the detailed description provided herein refers to convex polygons, such as polygon 504 or polygon 602, the invention is not limited in this regard and concave polygons may be employed in processes 200/300. Those skilled in the art will recognize that a convex polygon may be defined as an object wherein any whole straight line segment joining any two points of the object is contained wholly within the object while a concave polygon may be defined as an object wherein a whole straight line segment joining two points of the object may be found in which that line segment is not completely contained in the object.
To employ concave polygons in processes 200/300 a bounding volume corresponding to a convex hull of a concave polygon may be determined where that convex hull bounding volume has a scalar radius corresponding to the greatest distance value between an origin of the object and any point of the object. Such a convex hull bounding volume may then be employed in act 302. Alternatively, convex decomposition techniques may be used to subdivide a concave geometry into smaller convex geometries. The processes 200/300 may then be employed to detect collisions between those convex sub-geometries. Both convex hull bounding volume and convex decomposition techniques are well known in the art and will not be discussed in greater detail herein.
Referring again to process 200, in some implementations of the invention an application, such as a 3D graphics application, may undertake all acts of process 300 in a preprocessing stage (i.e., before process 200 is undertaken) and supply the resulting texture map to algorithm 102 in act 206. Alternatively, in other implementations of the invention, algorithm 102 may undertake process 300 in a dynamic manner in response to each collision detection event occurring during 3D rendering implemented by engine 100. Further, for each polygon received in act 202 an associated cube map storing distance values for that polygon may have been created in process 300 (i.e., generated in act 206) and used in further acts of process 300 as will be explained in greater detail below. In accordance with some implementations of the invention, process 300 may result in a cube map being held or stored in memory 106 where that cube map stores distance values for a particular polygon.
Process 200 may continue with determining a first distance value from an origin of the first polygon to a vertex of the second polygon [act 208] where the first distance lies along a direction vector extending from the origin of the first polygon to a vertex of the second polygon.
Process 200 may then continue with the determination, along a direction vector, of a second distance from the origin of the first polygon to a face of the first polygon by performing one or more lookups to a texture map [act 210]. In some implementations of the invention, referring again to
Similarly, for example, act 210 may involve determining a second distance 724 from origin 706 to face 722 of polygon 702 along direction vector 715. Then, in this example, determining second distance 724 may involve looking up the distance values that are stored at pixels 727 and 728 of the texture map generated in act 206 and then linearly interpolating between those distance values to obtain second distance 724 in act 210. In some implementations of the invention, act 210 may involve algorithm 102 providing texture sampler 104 with lookup indices associated with the pixels (e.g., pixels 725 and 726 or pixels 727 and 728). Sampler 104 may then use those indices to generate corresponding memory addresses for accessing the distance values for the corresponding pixels of the cube map stored in memory 106. Sampler 104 may then linearly interpolate between those distance values and provide a resulting interpolated distance value to algorithm 102. Alternatively, Sampler 104 may provide the distance values to algorithm 102 and algorithm 102 may linearly interpolate between those values to determine the second distance in act 210.
While each of direction vectors 710 and 715 are shown in
In other implementations of the invention, act 210 may involve algorithm 102 providing pixel shader 108 with lookup indices associated with the pixels (e.g., pixels 725 and 726 or pixels 727 and 728) and shader 108 may convey those indices to texture sampler 104. Sampler 104 may then use those indices to generate corresponding memory addresses for accessing the distance values for the corresponding pixels of the cube map stored in memory 106 and provide those distance values to shader 108. Shader 108 may then linearly interpolate between those distance values and provide a resulting interpolated distance value to algorithm 102. Alternatively, Shader 108 may provide the distance values to algorithm 102 and algorithm 102 may linearly interpolate between those values to determine the second distance in act 210.
Process 200 may then continue with comparing the first distance value to the second distance value [act 212] and, if the second distance is greater than or equal to the first distance, detecting a collision [act 216] between the first and second polygons. Referring again to
While acts 208 and 210 as described above refer, respectively, to determining first and second distances, and while act 212 refers to comparing these two distances to each other, in other implementations of the invention process 200 may include the acts of determining the square of those distances and then comparing those squared distance values to each other in act 212. Thus, in these implementations, act 214 may comprise determining if the square of the second distance is greater than or equal to the square of the first distance. The invention is, however, not limited to comparing the distances or the square of the distances in act 212. Thus for example, process 200 may include the acts of determining the square root of those distances and then comparing those square root distance values to each other in act 212.
The acts shown in
In some implementations of the invention, algorithm 102 as employed in processes 200 and/or 300 may comprise the following pseudo code:
Collision_Detection_Using_Cubemaps(...)
bool Collision = false;
Foreach vertex V2J of polygon P2 {
DirectionVector = V2J − C1;
d1 = texCube (DirectionVector);
d2 = distance (C1, V2J);
if (d1 >= d2) {
Collision = true;
break; // Collision
}
}
If (Collision) {
// Model the response of collision
} else {
// No collision, move on to evaluate the collision
detection for next pair of geometries
}
In other implementations of the invention, algorithm 102 as employed in processes 200 and/or 300 may be spawned by or be associated with pixel shader 108 of engine 100 and may comprise the following high level shading language (HLSL) pixel shader code:
PS_OUTPUT CollisionDetectionPS( VS_OUTPUT In,
uniform bool bTexture )
{
PS_OUTPUT Output;
int Index = 0;
float sum = 0.0;
float fActualDist,fCubeMapDist;
float4 temp = (0,0,0,1);
float4 WorldPos,WorldCentroid,dir;
bool collision = false;
float2 tex;
//bool results[115];
int trouble = 0;
Output.RGBColor.r = Output.RGBColor.g = Output.RGBColor.b =
Output.RGBColor.a = 0.0;
// These are texture (u,v) coordinates used to index at
center of pixels, and access // the position data of
objects.
float disp = 0.5/g_iNumVertices[1];
tex.y = 0.5
// World position of Centroid of object 0
WorldCentroid = mul(g_vCentroids[0],g_mWorldMat0);
// Shoot rays thru' all the vertices of Object 1
for( Index = 0; Index < g_iNumVertices[1]; Index++ ) {
tex.x = Index/g_iNumVertices[1] + disp;
// Get the position of vertex of object 1 that is
stored in a texture.
WorldPos = tex2D(g_samPositions1,tex);
// Tranform to world space.
WorldPos = mul(WorldPos,g_mWorldMat1);
dir = WorldPos − WorldCentroid;
fActualDist = sqrt(dir.x*dir.x + dir.y*dir.y +
dir.z*dir.z);
// Transform the direction back to the space where
cube-map was generated by
// multiplying by inverse of world matrix for object 0.
dir = mul(dir,g_mWorldMat0Inv);
dir = normalize(dir);
temp = texCUBE(g_samCubeMapDistance0,dir);
fCubeMapDist = temp.x;
if (fCubeMapDist > fActualDist) {
collision = true;
}
}
// Do the same calculations as above but switching the
objects. So now cycle thru' object 0's vertices.
disp = 0.5/g_iNumVertices[0];
WorldCentroid = mul(g_vCentroids[1],g_mWorldMat1);
for( Index = 0; Index < g_iNumVertices[0]; Index++ ) {
tex.x = Index/14.0 + disp;
WorldPos = tex2D(g_samPositions0,tex);
WorldPos = mul(WorldPos,g_mWorldMat0);
dir = WorldPos − WorldCentroid;
fActualDist = sqrt(dir.x*dir.x + dir.y*dir.y +
dir.z*dir.z);
dir = mul(dir,g_mWorldMat1Inv);
dir = normalize(dir);
temp = texCUBE(g_samCubeMapDistance1,dir);
fCubeMapDist = temp.x;
if (fCubeMapDist > fActualDist) {
collision = true;
}
}
if (collision == true) {
Output.RGBColor.r = Output.RGBColor.g =
Output.RGBColor.b = 1.0;
Output.RGBColor.a = 1.0;
}
return Output;
}
System 800 may assume a variety of physical implementations. For example, system 800 may be implemented in a personal computer (PC), a networked PC, a server computing system, a handheld computing platform (e.g., a personal digital assistant (PDA)), a gaming system (portable or otherwise), a 3D capable cellular telephone handset, etc. Moreover, while all components of system 800 may be implemented within a single device, such as a system-on-a-chip (SOC) integrated circuit (IC), components of system 800 may also be distributed across multiple ICs or devices. For example, host processor 802 along with components 806 and 814 may be implemented as multiple ICs contained within a single PC while graphics processor 804 and components 808 and 816 may be implemented in a separate device such as a television or other display coupled to host processor 802 and components 806 and 814 through communications pathway 810.
Host processor 802 may comprise a special purpose or a general purpose processor including any control and/or processing logic, hardware, software and/or firmware, capable of providing graphics processor 504 with 3D graphics data and/or instructions. Processor 802 may perform a variety of 3D graphics calculations such as 3D coordinate transformations, etc. the results of which may be provided to graphics processor 804 over bus 810 and/or that may be stored in memories 806 and/or 808 for eventual use by processor 804. In some implementations of the invention host processor 802 may be a Central Processing Unit (CPU).
In one implementation, host processor 802 may be capable of performing any of a number of tasks that support or enable real-time, multi-resolution 3D collision detection using cube maps. Support tasks may include, for example, although the invention is not limited in this regard, providing 3D graphics data to graphics processor 804, placing one or more texture maps, such as cube maps, in memory 808, downloading microcode (via antenna 815 and interfaces 814) to processor 804, initializing and/or configuring registers within processor 804, interrupt servicing, and providing a bus interface for uploading and/or downloading 3D graphics data. In alternate implementations, some or all of these functions may be performed by graphics processor 804. While
In accordance with some implementations of the invention, each of cores 803 may perform, in parallel, processes 200/300 for separate pairs of polygons using separate implementations of collision detection algorithm 102. Alternatively, such parallel processing schemes may be implemented by graphics processor 804.
Graphics processor 804 may comprise any processing logic, hardware, software, and/or firmware, capable of processing graphics data. In one implementation, graphics processor 804 may implement a 3D graphics architecture capable of processing graphics data in accordance with one or more standardized rendering application programming interfaces (APIs) such as OpenGL 2.0™ (“The OpenGL Graphics System: A Specification” (Version 2.0; Oct. 22, 2004)) and DirectX 9.0™ (Version 9.0c; Aug. 8, 2004) to name a few examples, although the invention is not limited in this regard. Graphics processor 804 may process 3D graphics data provided by host processor 802, held or stored in memories 806 and/or 808, and/or provided by sources external to system 800 and obtained over bus 810 from interfaces 814.
Graphics processor 804 may receive 3D graphics data in the form of 3D scene data and process that data to provide image data in a format suitable for conversion by display processor 816 into display-specific data. In addition, graphics processor 804 may implement a variety of 3D graphics processing components and/or stages (not shown) such as a rasterizer stage in addition to one or more texture samplers similar to texture sampler 104. Texture samplers implemented by graphics processor 804 may fetch or access texture data stored or held in the form of cube maps in either or both of memories 806 and 808. Further, in accordance with some implementations of the invention, graphics processor 804 may implement two or more texture samplers capable of using distance values stored in one or more cube maps to undertake collision detection for multiple pairs of polygons in a parallel fashion.
Bus or communications pathway(s) 810 may comprise any mechanism for conveying information (e.g., graphics data, instructions, etc.) between or amongst any of the elements of system 800. For example, although the invention is not limited in this regard, communications pathway(s) 810 may comprise a multipurpose bus capable of conveying, for example, instructions (e.g., macrocode) between processor 802 and processor 804. Alternatively, pathway(s) 810 may comprise a wireless communications pathway.
Display processor 816 may comprise any processing logic, hardware, software, and/or firmware, capable of converting rasterized image data supplied by graphics processor 804 into a format suitable for driving a display (i.e., display-specific data). For example, while the invention is not limited in this regard, processor 804 may provide image data to processor 816 in a specific color data format, for example in a compressed red-green-blue (RGB) format, and processor 816 may process such RGB data by generating, for example, corresponding LCD drive data levels etc. Although
Thus, by taking advantage of hardware primitives such as cube maps a collision detection algorithm in accordance with the invention may execute entirely on a graphics processor such as processor 804 with, possibly, the exception of the preprocessing of process 300 which may be implemented once for each polygon and done ahead of process 200. Further, a collision detection algorithm in accordance with the invention can leverage a high level octree structure to minimize object-object detections and may rely on cube maps for those object-object interactions that are identified as candidates by the octree data structure. Thus, by moving the collision detection algorithm to a graphics processor (e.g., processor 804) the CPU (e.g., host processor 802) may be freed up to undertake other tasks. Although a collision detection algorithm in accordance with the invention may execute on a CPU as well. Moreover, using hardware primitives such as cube maps to detect collisions may result in a significant reduction of the arithmetic operations per collision (possibly as much as a three-fold reduction) and is amenable to a many processing core implementation (e.g., using cores 803) due to the capability of performing completely independent collision detection tests.
While the foregoing description of one or more instantiations consistent with the claimed invention provides illustration and description of the invention it is not intended to be exhaustive or to limit the scope of the invention to the particular implementations disclosed. Clearly, modifications and variations are possible in light of the above teachings or may be acquired from practice of various implementations of the invention. For example, while
No device, element, act, data type, instruction etc. set forth in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Moreover, when terms or phrases such as “coupled” or “responsive” or “in communication with” are used herein or in the claims that follow, these terms are meant to be interpreted broadly. For example, the phrase “coupled to” may refer to being communicatively, electrically and/or operatively coupled as appropriate for the context in which the phrase is used. Variations and modifications may be made to the above-described implementation(s) of the claimed invention without departing substantially from the spirit and principles of the invention. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims.
Lake, Adam T., Sathe, Rahul P.
Patent | Priority | Assignee | Title |
8824776, | Apr 21 2011 | Seiko Epson Corporation | Collision detection system, robotic system, collision detection method and program |
9317749, | Apr 21 2011 | Seiko Epson Corporation | Collision detection system, robotic system, collision detection method and program |
Patent | Priority | Assignee | Title |
6396492, | Aug 06 1999 | Mitsubishi Electric Research Laboratories, Inc | Detail-directed hierarchical distance fields |
6498607, | Jan 29 1999 | Mitsubishi Electric Research Laboratories, Inc | Method for generating graphical object represented as surface elements |
6559853, | Feb 16 2000 | DIGIMEDIA TECH, LLC | Environment map creation using texture projections with polygonal curved surfaces |
6798415, | Jun 21 2001 | Intel Corporation | Rendering collisions of three-dimensional models |
7065242, | Mar 28 2000 | SIZMEK TECHNOLOGIES, INC | System and method of three-dimensional image capture and modeling |
20020060685, | |||
20040108999, | |||
20060066505, | |||
20070052724, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Jul 25 2006 | SATHE, RAHUL P | Intel Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 019992 | /0159 | |
Jul 28 2006 | Intel Corporation | (assignment on the face of the patent) | / | |||
Aug 18 2006 | LAKE, ADAM T | Intel Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 019992 | /0159 |
Date | Maintenance Fee Events |
Nov 13 2012 | ASPN: Payor Number Assigned. |
Nov 13 2012 | RMPN: Payer Number De-assigned. |
Sep 25 2014 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Oct 04 2018 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Dec 05 2022 | REM: Maintenance Fee Reminder Mailed. |
May 22 2023 | EXP: Patent Expired for Failure to Pay Maintenance Fees. |
Date | Maintenance Schedule |
Apr 19 2014 | 4 years fee payment window open |
Oct 19 2014 | 6 months grace period start (w surcharge) |
Apr 19 2015 | patent expiry (for year 4) |
Apr 19 2017 | 2 years to revive unintentionally abandoned end. (for year 4) |
Apr 19 2018 | 8 years fee payment window open |
Oct 19 2018 | 6 months grace period start (w surcharge) |
Apr 19 2019 | patent expiry (for year 8) |
Apr 19 2021 | 2 years to revive unintentionally abandoned end. (for year 8) |
Apr 19 2022 | 12 years fee payment window open |
Oct 19 2022 | 6 months grace period start (w surcharge) |
Apr 19 2023 | patent expiry (for year 12) |
Apr 19 2025 | 2 years to revive unintentionally abandoned end. (for year 12) |