DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Specification
The disclosure is objected to because of the following informalities: Paragraph 4 of the Specification states “ray tracking” which appears to be a typographical error and should be ray tracing.
Appropriate correction is required.
Allowable Subject Matter
Claim 2 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 6 and 9-10 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 6, the claim recites “determining that the rendering mode corresponding to the object model is normal rendering” in lines 2-3. The intended meaning of “normal rendering” is unclear. Does limitation intend to include rendering using normal values of the resulting triangle faces of a 3D object, or is the use of “normal” categorizing the rendering as normal as opposed to a specialized rendering? If merely used a categorization, it is further unclear what is conserved normal as opposed to not normal. There is nothing in the specification or otherwise that clarifies the meaning of what applicant intends to be considered “normal”, other than for example paragraph 149 of applicant’s specification filed 8/15/2024 which provides an example of “normal rendering” as rasterization, but otherwise is unclear. Therefore the scope of the claim is rendered indefinite. Furthermore, claim 6 depends from claim 5, which already states that the method determines that the rendering mode “is ray tracing rendering” in line 4 of the claim. By depending from claim 5, claim 6 now states the determination of the rendering mode as “normal rendering”, which implies that ray tracing rendering is also normal rendering, but the claim can also be interpreted as the determining results in a different determined mode then previously determined, i.e. the mode is determined as ray tracing rendering, but then the mode is determined as normal rendering. As result, the claim states the mode is in two separate determined states at the same time. Therefore, the claim is rendered indefinite as to whether the claim intends that ray tracing is “normal”, or the mode is determined as two different states (which would potentially also result in an enablement issue without further clarification). As such, the claim is indefinite.
Regarding claim 9, the claim recites wherein a weight of the distance is set to range from 0.1 to 0.5 and a weight of the ratio ranges from 0.5 to 0.9”. The limitation, however, does not refer to any use of any kind of weighting in any formular or otherwise. This claim appears to be more properly dependent on claim 2, but instead depends from claim 8 which does not recite any kind of use of weightings and further does not specify any kind of relationship to which weightings would be appropriately applied, as there is nothing other than a recitation of a “relationship” of data. Therefore, it is unclear what the “weighting” is related to (i.e. is it a weighted calculation? Or is it merely just a value of data that is not otherwise used? Etc.), including what the weighting is against and/or in relation to for determining the meaning of weighting the values. Accordingly, merely reciting the weighting of the distance and the ratio without specifying in relationship to what the weighting applies to, the claim is rendered indefinite.
Regarding claim 10, the claim recites and additional specification of the weighted values, without further clarifying what is the metes and bounds of the weightings, substantially similar to claim 9. Accordingly, by reciting the weight of the distance is set to 0.3 and the weight of the ratio is 0.7, the claim is rendered indefinite for substantially the same reasons as claim 9 set forth above.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 4, 8, 11-13, 17 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over:
Rogers (US 2017/0091992 A1) in view of
Bernick (Tom BERNICK, "LOD Selection - OpenGL - Khronos Forums," XP093267644, Retrieved from the Internet, URL: https://community.khronos.org/t/lod-selection/49560/2, 4 pages (March 1, 2004) – Applicant provided reference, see IDS filed 4/25/2025)
Regarding claim 17, Rogers discloses:
An electronic device, comprising: (Rogers, Fig. 1 and ¶40)
One or more memories storing one or more programs (Rogers, Fig. 1 and ¶40: storage media and memory coupled to processor with software residing on tangible storage medium); and
A processor configured to execute the one or more programs to cause the electronic device to perform operations comprising: (Rogers, Fig. 1 and ¶40: software executed by processor)
Determining first polygonal mesh data corresponding to an object model in a scene, wherein the first polygonal mesh data is for describing the object model; (Rogers, ¶11 and ¶12: the raw 3D mesh is constructed by tessellating the 3D model to form a plurality of polygons defined by 3D coordinate points connected by edges, using hierarchical continuous level of detail tree data structure with different levels of nodes having different levels of details of mesh representation, e.g. each child node corresponding to sub-mesh from parent mesh; ¶34: In three-dimensional computer graphics environments, objects in a scene are typically modeled as three-dimensional meshes made up of primitives (e.g., triangles or other polygons into coordinate points connected by edges); also ¶37: H-CLOD tree for object mesh; Fig. 2 and ¶43: 3D mesh model)
Creating a bounding [shape] corresponding to the object model based on the first polygonal mesh data; (Rogers, ¶77: generate bounding sphere around the mesh)
Determining a pixel range covered when the bounding[shape] is projected onto a screen of the electronic device, obtaining a relationship between a quantity of pixels covered by the bounding [shape] [Examiner notes that applicant uses “an observation angle” as synonymous to camera, as opposed to an actual angle measurement – see Spec. ¶56 and ¶65, filed 8/15/2024] (Rogers, Figs. 15A/B and ¶76 discusses screen space 1540, where screen space is the planar 2D space rendered for display to the viewer; ¶77:
[0077] As illustrated in FIG. 15A, the error container 1530 can then be projected into screen space 1540 to produce a screen space projection 1535. A screen space error can be measured from the screen space projection 1535 in accordance with dimensions (e.g., 2D) of the error container 1530 as projected in screen space 1540. For example, the screen space error can be measured as a number of pixels occupied by the screen space projection 1535, a height and width (or area) of the screen space projection 1535, etc. Some embodiments seek to ensure that the screen space error is determined in a conservative manner. For example, some embodiments compute a bounding sphere 1520 around the mesh (e.g., centered on the center point of the mesh) and locate the error container 1530 (e.g., a center of the container, an origin point of the line segments bound by the container, etc.) at a point on the bounding sphere 1520 that is closest to the virtual camera 210 (or to the screen space 1540). Alternatively, embodiments can determine a point on the mesh 1510 closest to the virtual camera 210 or screen space 1540 for locating the error container 1530.
In other words, Rodgers discloses using a bounding sphere of a mesh centered on a point of the sphere closes to the virtual camera to find screen space error based on the quantity of pixels of the screen occupied by the screen space projection onto the screen space 1540 providing a relationship of pixels of the bounding box to screen space that are rendered – examiner notes that the claim does not provide any particular details as to what the claimed “relationship” refers to, and therefore the projection to find corresponding pixels of the bounding sphere to the screen space plane is read on by the limitation; also note that a distance to the bounding sphere is itself “a distance” between the observation angle/camera and object model as it is located between the two, but also ¶77 discloses using point on mesh closes to virtual camera 210 for locating error container)
Determining a level of detail (LOD) level corresponding to the object model based on the distance and the relationship, and updating the first polygonal mesh data to second polygonal mesh data based on the LOD level; and (Rogers, ¶10: determining, for each of at least a subset of the nodes in the active front, according to the updated virtual camera position, whether to increase a level of detail associated with the node or to decrease the level of detail associated with the node; Fig. 10 and ¶64 discloses the formed H-CLOD tree for mesh data, with mesh having simplified parent nodes; also see ¶67: the H-CLOD mesh data 145 represents an object's mesh as a hierarchical tree data structure having a finest level of detail at its leaf nodes and a coarsest level of detail at its top-most node; ¶77 discloses that the screen space error is measured from the screen space projection as measured as a number of pixels occupied by the screen space projection 1535, can determine a point on the mesh 1510 closest to the virtual camera 210 for locating the error container 1530; ¶79: determining level of detail based on screen space error for camera space, using thresholding, which results in either higher or lower level of detail – i.e. tessellation – for rendering)
Rendering the object model based on the second polygonal mesh data (Rogers, ¶68: rendering uses meshes from H-CLOD tree, where object mesh closer to virtual camera position is rendered with finer level of detail than mesh that is further from the virtual camera)
The only limitation not explicitly taught by Rogers is the particular shape of the bounding element as a bounding box (i.e. Rogers uses a different bounding container as a sphere). Replacing the bounding sphere with a box for performing the LOD analysis, however, was known as of the effective filing date of the applicant’s invention.
Bernick discloses:
Creating a bounding box corresponding to the object model based on the first polygonal mesh data; and determining a level of detail (LOD) level corresponding to the object model based on the distance and the relationship of bounding box (Bernick, p. 1 lines 1-4 discloses the known manner of selecting level of detail including distance from the object to point of view in world space and size in pixel of object in screen space; p. 1, lines 15-16 disclosing use of bounding box of object and calculating screen area; p. 2, Lars comment, discloses “take into account the size of the object. You dont need to be exact (transforming the bounding box to screen space). […] Choose the LOD Level on distance, size and FOV”)
Both Rogers and Bernick are directed to rendering objects based on LOD selection using distance and screen size of an object. It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention and with a reasonable expectation of success, to modify the system and technique for rendering 3D mesh objects by selecting a level of detail of the mesh for rendering based on screen space and distance as provided by Rogers, by using a bounding box for determining screen space for determining a LOD for rendering based on screen size and distance as provided by Bernick, using known electronic interfacing and programming techniques. The modification merely substitutes one known bounding shape for determining screen space projections for another in use of an LOD selection, yielding predictable results of using a known bounding box as opposed to sphere in the determination of object characteristics for selecting a level of detail for rendering. The modification also provides an improved LOD selection by allowing for different bounding shapes that may more accurately represent the angles or shape of an object for more accurate determination of screen space while still maintaining an approximation of data for faster and more efficient processing.
Regarding claim 1, the device of claim 17 performs the method of claim 1 and as such claim 1 is rejected based on the same rationale as claim 17 set forth above.
Regarding claim 18, Rogers discloses:
A non-transitory computer-readable storage medium a computer program that, when executed by a processor, causes an electronic device to perform operations. (Rogers, Fig. 1 and ¶40: storage media and memory coupled to processor with software residing on tangible storage medium and software executed by processor)
Further regarding claim 18, the operations perform the method of claim 1 and therefore claim 18 is further rejected based on claim 1 set forth above.
Regarding claim 4, Rogers further disclose:
Wherein the updating the first polygonal mesh data to the second polygonal mesh data based on the LOD level comprises: Removing, based on the LOD level, a part of polygonal mesh data from the first polygonal mesh data by using a polygonal mesh tile reduction algorithm to obtain the second polygonal mesh data (Examiner notes that applicant defines “mesh tile” as “a plane formed by a smallest plane formation nuit, namely a polygon, in two-dimensional or three-dimensional space” – see ¶57 of applicant’s Spec. filed 8/15/2024; Rogers, ¶34 discusses reducing complexity of mesh using various techniques related to coordinate points and edges of mesh, and the faces formed therefrom, the meshes made up of primitives such as triangles or other polygons; ¶58 discloses mesh simplification including removing a portion of faces and collapsing vertices to reduce face count by some threshold – see Fig. 7 and ¶59)
Regarding claim 8, Rogers further discloses:
Wherein the relationship between the quantity of pixels covered by the bounding box and the quantity of pixels of the screen is a ratio of the quantity of pixels covered by the bounding box to the quantity of pixels of the screen (Rogers, Figs. 15A/B and ¶76 discusses screen space 1540, where screen space is the planar 2D space rendered for display to the viewer; ¶77:
[0077] As illustrated in FIG. 15A, the error container 1530 can then be projected into screen space 1540 to produce a screen space projection 1535. A screen space error can be measured from the screen space projection 1535 in accordance with dimensions (e.g., 2D) of the error container 1530 as projected in screen space 1540. For example, the screen space error can be measured as a number of pixels occupied by the screen space projection 1535, a height and width (or area) of the screen space projection 1535, etc. Some embodiments seek to ensure that the screen space error is determined in a conservative manner. For example, some embodiments compute a bounding sphere 1520 around the mesh (e.g., centered on the center point of the mesh) and locate the error container 1530 (e.g., a center of the container, an origin point of the line segments bound by the container, etc.) at a point on the bounding sphere 1520 that is closest to the virtual camera 210 (or to the screen space 1540). Alternatively, embodiments can determine a point on the mesh 1510 closest to the virtual camera 210 or screen space 1540 for locating the error container 1530.
In other words, Rogers teaches the use of a bounding sphere to determine the number of pixels of screen space, which is also determined as plane 1540, and the area of the screen projection 1535 used by the bounding box in pixels, which requires the determination of the pixels of the screen space itself to identify the pixel quantities of data. Furthermore, ¶3 discloses the changing of complexity of rendered objects based on whether larger or smaller in the rendered scenes, which is a relationship of pixels of object to screen pixels)
Regarding claim 11, Rogers further discloses:
Wherein the first polygonal mesh data comprises a first quantity of polygons corresponding to the object model (Rogers, ¶3 discloses that more complexity tends to include increasing number of primitives; ¶10: determining, for each of at least a subset of the nodes in the active front, according to the updated virtual camera position, whether to increase a level of detail associated with the node or to decrease the level of detail associated with the node; ¶55: child nodes sharing same parent can be combined to form mesh of parent node; Fig. 10 and ¶64 discloses the formed H-CLOD tree for mesh data, with mesh having simplified parent nodes; also see ¶67: the H-CLOD mesh data 145 represents an object's mesh as a hierarchical tree data structure having a finest level of detail at its leaf nodes and a coarsest level of detail at its top-most node; Figs. 11A-11F and ¶67 discloses the use of the H-CLOD to render a mesh based on LOD traversal of the nodes, where rendering only root node is coarsest level of detail – Fig. 11A – where as Fig. 11F results in rendering the highest level of detail; ¶75: traversing H-CLOD tree to determine which nodes to use for rendering)
Regarding claim 12, Rogers further discloses:
Wherein the second polygonal mesh data comprises a second quantity of polygons corresponding to the object model, wherein the second quantity is less than the first quantity (Rogers, ¶3 discloses that more complexity tends to include increasing number of primitives; ¶10: determining, for each of at least a subset of the nodes in the active front, according to the updated virtual camera position, whether to increase a level of detail associated with the node or to decrease the level of detail associated with the node; ¶55: child nodes sharing same parent can be combined to form mesh of parent node; Fig. 10 and ¶64 discloses the formed H-CLOD tree for mesh data, with mesh having simplified parent nodes; also see ¶67: the H-CLOD mesh data 145 represents an object's mesh as a hierarchical tree data structure having a finest level of detail at its leaf nodes and a coarsest level of detail at its top-most node; Figs. 11A-11F and ¶67 discloses the use of the H-CLOD to render a mesh based on LOD traversal of the nodes, where rendering only root node is coarsest level of detail – Fig. 11A – where as Fig. 11F results in rendering the highest level of detail; ¶75: traversing H-CLOD tree to determine which nodes to use for rendering)
Regarding claim 13, Rogers further discloses:
Wherein polygons of the first polygonal mesh data are triangles (Rogers, ¶34 discusses reducing complexity of mesh using various techniques related to coordinate points and edges of mesh, and the faces formed therefrom, the meshes made up of primitives such as triangles or other polygons; ¶58 discloses mesh simplification including removing a portion of faces and collapsing vertices to reduce face count by some threshold – see Fig. 7 and ¶59)
Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over:
Rogers (US 2017/0091992 A1) in view of
Bernick (Tom BERNICK, "LOD Selection - OpenGL - Khronos Forums," XP093267644, Retrieved from the Internet, URL: https://community.khronos.org/t/lod-selection/49560/2, 4 pages (March 1, 2004) – Applicant provided reference, see IDS filed 4/25/2025) and in further view of
Mao et al. (US 6,765,574 B1).
Regarding claim 3, the limitations included from claim 1 are rejected based on the same rationale as claim 1 set forth above and incorporated herein. Further regarding claim 3, Rogers further discloses:
Wherein the determining the distance between the observation angle in the scene and the object model comprises: obtaining first world coordinates of the observation angle in world space and second world coordinates of the object model (Rogers, ¶34 discloses the 3D meshes made up of primitives made from connected coordinate points; ¶77: determine a point on the mesh 1510 closest to the virtual camera 210 for locating the error container 1530 – this requires the determination of coordinates for determining the distance in 3D)
Rogers does not explicitly teach the use of world coordinates.
Mao discloses:
Wherein the determining the distance between the observation angle in the scene and the object model comprises: obtaining first world coordinates of the observation angle in world space and second world coordinates of the object model in the world space; and determining the distance between the observation angle and the object model based on the first world coordinates and the second world coordinates (Mao, Abstract discloses 3D scene and objects, and determining level of detail polygon reduction ratio for a mesh; also [2:62-65] discloses purpose of invention as simplifying a hierarchical static scene having multiple 3D objects and of budgeting for the number of polygons used in rendering the 3D objects; [11:3-15]: virtual camera at point O and distance determined from mesh in world coordinates to the camera; also [11:20-21] discloses use of R as distance from mesh in world coordinates to camera)
Rogers, Bernick and Mao are directed to rendering objects based on LOD selection using distance and screen size of an object. It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention and with a reasonable expectation of success, to modify the system and technique for rendering 3D mesh objects by selecting a level of detail of the mesh for rendering based on screen space and distance as provided by Rogers, using a bounding box for determining screen space for determining a LOD for rendering based on screen size and distance as provided by Bernick, by further using the coordinate space for calculating distance between camera and mesh as provided by Mao, using known electronic interfacing and programming techniques. The modification merely substitutes one known coordinate space for determining elements of a 3D scene for another, yielding predictable results of using a known world coordinates for calculating distances in 3D space. The modification also provides an improved 3D rendering system by utilizing common coordinate space for easier implementation and uniformity of data.
Claim(s) 5-6 is/are rejected under 35 U.S.C. 103 as being unpatentable over:
Rogers (US 2017/0091992 A1) in view of
Bernick (Tom BERNICK, "LOD Selection - OpenGL - Khronos Forums," XP093267644, Retrieved from the Internet, URL: https://community.khronos.org/t/lod-selection/49560/2, 4 pages (March 1, 2004) – Applicant provided reference, see IDS filed 4/25/2025) and in further view of
Muthler et al. (US 2021/0390757 A1) and
Ahn et al. (US 2010/0315423 A1).
Regarding claim 5, the limitations included from claim 1 are rejected based on the same rationale as claim 1 set forth above and incorporated herein. Further regarding claim 5, Muthler discloses:
Obtaining the second polygonal mesh data; and calculating an intersection of a ray and the object model in the scene by using a ray tracing shader based on the second polygonal mesh data, and shading the object model based on the intersection (Muthler, ¶20: Ray tracing can be used to determine if anything is visible along a ray (for example, testing for occluders between a shaded point on a geometric primitive and a point on a light source) and can also be used to evaluate reflections (which may for example involve performing a traversal to determine the nearest visible surface along a line of sight so that software running on a streaming processor can evaluate a material shading function corresponding to what was hit—which in turn can launch one or more additional rays into the scene according to the material properties of the object that was intersected) to determine the light returning along the ray back toward the eye; ¶26: A basic task for most ray tracers is to test a ray against all primitives (commonly triangles in one embodiment) in the scene and report either the closest hit (according to distance measured along the ray) or simply the first (not necessarily closest) hit encountered, depending upon use case; ¶¶28-29: to determine whether ray intersects geometry in mesh, each primitive/triangle could be directly tested against ray, where bounding volumes can be used to accelerate testing before testing primitives inside bounding volume; Also ¶126: ray primitive test provides information about primitives that a ray intersects to determine material properties of surface for shading and visualization)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention and with a reasonable expectation of success, to modify the system and technique for rendering 3D mesh objects by selecting a level of detail of the mesh for rendering based on screen space and distance as provided by Rogers, using a bounding box for determining screen space for determining a LOD for rendering based on screen size and distance as provided by Bernick, by using the ray tracing of mesh data as provided by Muthler, using known electronic interfacing and programming techniques. The modification merely substitutes one known type of rendering technique for mesh data for another yielding predictable results of using well-known ray tracing technique for 3D computer graphic rendering in a system that selects a tessellated mesh object for rendering. The modification results in an improved rendering system for a 3D mesh by better accounting for lighting effects such as reflection for more pleasing visual results.
Ahn discloses:
Where the rendering the object model based on the second polygonal mesh data comprises: determining that a rendering mode corresponding to the object model is ray tracing rendering; (Ahn, ¶¶7-8: determining unit selects rendering scheme performing a 3D rendering, where rendering scheme is selected based on material properties of target object and distance between target object and camera position, including at least 3 rendering schemes; ¶21: rendering scheme may be ray-tracing; ¶22: selecting rendering scheme from the three schemes; ¶41: when the target object requires the reflection, the refraction, and the like, the determining unit 110 may determine to perform a ray-tracing rendering)
Obtaining the second data; and calculating an intersection of a ray and the object model in the scene by using a ray tracing shader based on the second data, and shading the object model based on the intersection. (Ahn, ¶53: 3D rendering using reflective light, by tracing a rout of a ray reflected from a surface of an object – see Fig. 4; Fig. 6 and ¶66-67: ray-tracing rendering, including transmitting ray in direction of screen to determine when ray meets an object, determine shadow and illumination of reflections)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention and with a reasonable expectation of success, to modify the system and technique for rendering 3D mesh objects by selecting a level of detail of the mesh for rendering based on screen space and distance as provided by Rogers, using a bounding box for determining screen space for determining a LOD for rendering based on screen size and distance as provided by Bernick, using the ray tracing of mesh data as provided by Muthler, by further utilizing the selection of a rendering mode as provided by Ahn, using known electronic interfacing and programming techniques. The modification results in an improved rendering system by better utilizing limited computational resources for faster processing while maintaining visual effects by better accommodating the underlying image data and selecting the proper rendering scheme based on the data.
Regarding claim 6, Ahn further discloses:
Determining that the rendering mode corresponding to the object model is normal rendering; (Ahn, ¶¶7-8: determining unit selects rendering scheme performing a 3D rendering, where rendering scheme is selected based on material properties of target object and distance between target object and camera position, including at least 3 rendering schemes; ¶51: first rendering scheme may be a rasterization rendering)
Obtaining the first polygonal mesh data corresponding to the object model in the scene; and shading the object model using a rasterized shader (Ahn, ¶58: each pixel value to be outputted on a screen may be stored in a frame buffer by performing the rasterization rendering by using color information of the extracted patch or sample point, a camera, and material information of the object; Fig. 5 and ¶¶64-65: rasterization rendering including set of 3D triangles are converted into pixels for frame buffer)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention and with a reasonable expectation of success, to modify the system and technique for rendering 3D mesh objects by selecting a level of detail of the mesh for rendering based on screen space and distance as provided by Rogers, using a bounding box for determining screen space for determining a LOD for rendering based on screen size and distance as provided by Bernick, using the ray tracing of mesh data as provided by Muthler, by further utilizing the selection of a rendering mode as provided by Ahn, using known electronic interfacing and programming techniques. The modification results in an improved rendering system by better utilizing limited computational resources for faster processing while maintaining visual effects by better accommodating the underlying image data and selecting the proper rendering scheme based on the data.
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over:
Rogers (US 2017/0091992 A1) in view of
Bernick (Tom BERNICK, "LOD Selection - OpenGL - Khronos Forums," XP093267644, Retrieved from the Internet, URL: https://community.khronos.org/t/lod-selection/49560/2, 4 pages (March 1, 2004) – Applicant provided reference, see IDS filed 4/25/2025) and in further view of
Ferguson et al. (US 2006/0158450 A1)
Regarding claim 7, the limitations included from claim 1 are rejected based on the same rationale as claim 1 set forth above and incorporated herein. Examiner first notes that one of ordinary skill in the art would have understood that finding a bounding box of an object in 3D space of an object requires determining the minimum and maximum coordinates of an object in all three axes, as this is the very purpose of the bounding box. However, Ferguson also discloses that such technique is known within the field of computer graphics 3D rendering:
Wherein the creating the bounding shape corresponding to the object model based on the first polygonal mesh data comprises: determining, based on the first polygonal mesh data, maximum values and minimum values of the object model in an X direction, a Y direction, and a Z direction in coordinates of the object model; and determining the bounding box based on the maximum values and minimum values (Ferguson, ¶44: computing bounding box includes min and max X,Y,Z for the mesh)
Rogers, Bernick and Ferguson are directed to rendering objects based on LOD selection using distance and screen size of an object. It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention and with a reasonable expectation of success, to modify the system and technique for rendering 3D mesh objects by selecting a level of detail of the mesh for rendering based on screen space and distance as provided by Rogers, using a bounding box for determining screen space for determining a LOD for rendering based on screen size and distance as provided by Bernick, by using the min and max coordinate values of a mesh for computing a bounding box of an object for rendering as provided by Ferguson, using known electronic interfacing and programming techniques. The modification merely substitutes one known type of bounding box for another, yielding predictable results of using a well-known technique for obtaining a bounding box of a mesh used within an LOD rendering system. Furthermore, the modification results in an improved LOD system based on bounding boxes by using a simple technique for computing the bounding box resulting in easier implementation, while also ensuring all vertices of the object are bounded and accounted for in the approximation.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kristiansen (US 2006/0061584 A1) discloses related techniques for determining level of detail for rendering using a relationship between screen coverage and distance to viewing points, correlating the two with an importance factor that is used for selecting LOD for rendering, similar to applicant’s claimed invention (see Kristiansen, ¶19: level of details used in texture reflects the importance of an object displayed on a computer display; ¶21: screen coverage factor and distance of object to observation point discussed as important factors for object data, where screen coverage factor designated as “C”; ¶26: distance of viewing point to object designated as “A”; ¶33-34: calculate important factor for texture as P = C / A)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WILLIAM A BEUTEL whose telephone number is (571)272-3132. The examiner can normally be reached Monday-Friday 9:00 AM - 5:00 PM (EST).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, DANIEL HAJNIK can be reached at 571-272-7642. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/WILLIAM A BEUTEL/Primary Examiner, Art Unit 2616
Prosecution Insights