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 .
DETAILED ACTION
Election/Restrictions
Due to discovered art, the Examiner has withdrawn the restriction/election requirement mailed on 10/14/2025.
Claim Objections
Claims 1-2, 10-11, 19 are objected to because of the following informalities:
Claim 1 recites the limitation "the triangle primitives" in line 7. Claim 2 recites the limitation "the triangle primitives" in line 5. Claim 10 recites the limitation "the triangle primitives" in line 8. Claim 11 recites the limitation "the triangle primitives" in line 5. Claim 19 recites the limitation "the triangle primitives" in line 8.
They should be “the plurality of triangle primitives” Appropriate correction is required.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
1. Claims 1, 8-10, 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Hutchins, U.S Patent No. 8432394 (Hutchins”) in view of Genova et al,. WO2022046113A1, (“Genova”) further in view of Hickman et al., U.S Patent No.825846 (“Hickman”) further in view of BAO et al, IDS, CN109961498A (English translated) (“BAO”)
Regarding independent claim 1, Hutchins teaches a three-dimensional model rendering method performed by a computer device (Fig. 1, col. 1, lines 36-51 “The rendering of three-dimensional (3D) graphical images is of interest in a variety of electronic games and other applications. Rendering is the general term that describes the overall multi-step process of transitioning from a database representation of a 3D object to a two-dimensional projection of the object onto a viewing surface. The rendering process involves a number of steps, such as, for example, setting up a polygon model that contains the information which is subsequently required by shading/texturing processes, applying linear transformations to the polygon mesh model, culling back facing polygons, clipping the polygons against a view volume, scan converting/rasterizing the polygons to a pixel coordinate set, and shading/lighting the individual pixels using interpolated or incremental shading techniques.”) and the method comprising:
acquiring material information of a plurality of triangle primitives in a three- dimensional model ; at least two triangle primitives in the plurality of triangle primitives having different material information; (col. 6, lines 17-33 “A setup stage 405 receives instructions and graphics primitives from a host, such as a software application running on the CPU 201. In one embodiment, setup stage 405 performs the functions of geometrical transformation of coordinates (X-form), clipping, and setup. The setup unit takes vertex information (e.g., x, y, z, color and/or texture attributes, etc.) from primitives and applies a user defined view transform to calculate screen space coordinates for each geometric primitive (often referred to as triangles because primitives are typically implemented as triangles), which is then sent to the raster stage 410 to draw the given triangle. A vertex buffer 408 may be included to provide a buffer for vertex data used by setup stage 405. In one embodiment, setup stage 405 sets up barycentric coordinate transforms. In one implementation, setup stage 405 is a floating point Very Large Instruction Word (VLIW) machine that supports 32-bit IEEE fl, S15.16 fixed point and packed 0.8 formats.” where vertex information(e.g., x, y, z, color and/or texture attributes, etc.) which is considered including material as user’s desired );
generating model parameters of the three-dimensional model based on the material information of the triangle primitives, the model parameters comprising rendering parameters of rasters in the three-dimensional model (see at least col.6, lines 34-51 “ “Raster stage 410 receives data from setup stage 405 regarding triangles that are to be rendered (e.g., converted into pixels). Raster stage 410 processes parameters for each pixel of a given triangle by interpolation and determines shader attributes that need to be interpolated for a pixel as part of rendering, such as calculating color, texture, and fog blend factors. In one embodiment, raster stage 410 calculates barycentric coordinates for pixel packets. In a barycentric coordinate system, distances in a triangle are measured with respect to its vertices. The use of barycentric coordinates reduces the required dynamic range, which permits using fixed point calculations that require less power than floating point calculations. Raster stage 410 generates at least one pixel packet for each pixel of a triangle that is to be processed. Each pixel packet includes fields for a payload of pixel attributes required for processing (e.g., color, texture, depth, fog, (x,y) location) along with sideband information, and an instruction sequence of operations to be performed on the pixel packet. An instruction area in raster stage 410 (not shown) assigns instruction sequence numbers to pixel packets. The sideband information may also include a valid field, and a kill field. The pixel packet may include one or more rows of pixel information.”; col.9,lines 1-35 “As described above, the raster stage 410 receives data from setup stage 405 regarding triangles that are to be rendered (e.g., converted into pixels). For each received triangle, the raster stage 410 rasterizes the triangle into each of its constituent pixels with a number parameters interpolated for each pixel. The rasterizer computes rendering parameters for each of the pixels of the triangle by systematically evaluating each of the pixels in a deterministic, sequential manner (e.g., "walking" the triangle). The parameters are computed through an interpolation process from the data associated with the triangle's vertices. The raster stage 410 advantageously utilizes an array of programmable interpolators 501-508 to compute the parameters in parallel. As the raster stage 410 walks each pixel, the parameters for that pixel are iterated, and the resulting data is passed down to subsequent stages of the pipeline (e.g., as a pixel packet). The interpolated results can be placed in programmably selectable positions in the pixel packet. As is generally known, complex 3D scenes can typically have a large number of polygons, and additionally, a large number of rendering parameters for each polygon. Such parameters include, for example, color, texture coordinates, transparency, depth, level of detail (LOD), and the like. A real-time 3D rendering pipeline needs to perform many millions of calculations per second to maintain the pixel throughput (e.g., fill rate) required to draw a realistic 60-70 frames per second. The raster stage 410 utilizes the parallel array of interpolators 501-508 to maintain the required pixel fill rate while conserving power consumption and silicon area.”);
and rendering a two-dimensional image of the three-dimensional model based on the rendering parameters of the rasters (see at least col.9,lines 1-35 "As described above, the raster stage 410 receives data from setup stage 405 regarding triangles (e.g., polygons) that are to be rendered (e.g., converted into pixels). This is illustrated in FIG. 6 as the triangle 630 propagating down to the raster stage 410 from the set up stage 405. The triangle 630 comprises a geometric primitive having associated therewith instructions (e.g., instructions 631) indicating the manner in which the triangle is to be rasterized and rendered, and primitive data (e.g., parameter data such as color, texture coordinates, transparency, xy, depth, etc.) The raster stage 410 advantageously utilizes an array of programmable interpolators 501-508 to compute the parameters in parallel. As the raster stage 410 walks each pixel, the parameters for that pixel are iterated, and the resulting data is passed down to subsequent stages of the pipeline (e.g., as a pixel packet). The interpolated results can be placed in programmably selectable positions in the pixel packet. As is generally known, complex 3D scenes can typically have a large number of polygons, and additionally, a large number of rendering parameters for each polygon. Such parameters include, for example, color, texture coordinates, transparency, depth, level of detail (LOD), and the like. A real-time 3D rendering pipeline needs to perform many millions of calculations per second to maintain the pixel throughput (e.g., fill rate) required to draw a realistic 60-70 frames per second. The raster stage 410 utilizes the parallel array of interpolators 501-508 to maintain the required pixel fill rate while conserving power consumption and silicon area.” ; col. 14, lines 21-54 “Thus, for example, even though a z stepper of the raster stage 410 may begin at -2.0 z value, by the time the raster stage 410 steps into the view volume (e.g., z values between 0.0 and 1.0) the fractional portion will behave correctly and consistently. Similarly, in a case where the z stepping process begins at positive 6.0 z value, the fractional portion of z will consistently and deterministically roll over as the integer value steps from 6.0 to 0.0. It is possible to take advantage of this behavior because other separately iterated parameters (the barycentric coefficients) determine which pixels are within the two-dimensional x, y projection of the primitive. Rasterizing correct z values is only important within this two-dimensional projection of the primitive in the x,y plane; outside of this region the z stepper need only act as an error term such that the correct z values are generated once the rasterizer steps into the triangle”) Hutchins is understood to be silent on the remaining limitations of claim 1.
In the same field of endeavor, Ganova teaches acquiring material information of a plurality of triangle primitives in a three- dimensional model, at least two triangle primitives in the plurality of triangle primitives having different material information (see at least [0020] More particularly, a computing system can obtain a three-dimensional mesh. The three-dimensional mesh can be or otherwise include a plurality of polygons and associated texture data and/or associated shading data. As an example, the three-dimensional mesh can be a mesh representation of an object, and the associated shading and/or texture data can indicate a one or more colors for the polygons of the three-dimensional mesh (e.g., a texture data for a character model mesh in a video game, etc.); [0025] The computing system can determine an initial color value for each pixel of the subset of pixels. The initial color value can be based on the coordinates of the pixel and the associated shading data and/or the associated texture data. As an example, the polygon coordinates for a first pixel can indicate that the first pixel is located in a first polygon. Based on the shading and/or texture data, the polygon can be determined to have an orange color where the pixel is located (e.g., with respect to the polygon’s vertices, etc.). The first pixel can be colored orange based on the pixel coordinates and the shading and/or texture data.” where shading data, for polygons are considered material information and polygons is considered as triangle)
the model parameters comprising rendering parameters of rasters in the three-dimensional model (see at least [0022] The computing system can rasterize the three-dimensional mesh to obtain a two- dimensional raster of the three-dimensional mesh. The two-dimensional raster can be or otherwise include a plurality of pixels and a plurality of coordinates respectively associated with a subset of the plurality of pixels (e.g., by sampling the surface of the three-dimensional mesh, etc.). These coordinates can describe the locations of pixels relative to the vertices of the polygons in which the pixels are located. As an example, a first coordinate can describe a location of a first pixel relative to the vertices of a first polygon in which the first pixel is located. A second coordinate can describe a location of a second pixel relative to the vertices of a second polygon in which the second pixel is located. In some implementations, each of the plurality of coordinates can be or otherwise include barycentric coordinates.”; [0025] The computing system can determine an initial color value for each pixel of the subset of pixels. The initial color value can be based on the coordinates of the pixel and the associated shading data and/or the associated texture data. As an example, the polygon coordinates for a first pixel can indicate that the first pixel is located in a first polygon. Based on the shading and/or texture data, the polygon can be determined to have an orange color where the pixel is located (e.g., with respect to the polygon’s vertices, etc.). The first pixel can be colored orange based on the pixel coordinates and the shading and/or texture data. [0026] More particularly, in some implementations, the polygon identifier and coordinates for each pixel can allow for perspective-correct interpolation of vertex attributes (e.g., of the polygons of the three-dimensional mesh, etc.) to determine a color for the pixel. In some implementations, the determination of the color for each pixel can include application of the shading data and/or the texture data to the two-dimensional raster using a shading and/or texturing scheme. For either application, any sort of application scheme can be used. As an example, a deferred-shading, image-space application scheme can be used to apply the shading data and/or the texture data to determine a color for each of the subset of pixels.” where color values are considered as rendering parameters”);
rendering a two-dimensional image of the three-dimensional model based on the rendering parameters of the rasters (see at least [0022] [0027] The computing system can construct a splat for each pixel of the subset of pixels at the coordinates of each of the respective pixels. More particularly, each rasterized surface point of the two-dimensional raster can be converted into a splat, centered at the coordinates of the respective pixel, and colored by the corresponding shaded color C that was determined for the pixel. In some implementations, a splat can be constructed as a small area of color with a smooth falloff of color that spreads out from the origin of the splat. As an example, the color of a splat with a bright red center location may smoothly fall off as the distance from the center of the splat grows further (e.g., a gradient from the edge of the splat to the center of the splat, etc.). [0029] The computing system can determine an updated color value for each of the subset of pixels to generate a two-dimensional differentiable rendering of the three- dimensional mesh. The updated color value can be based on a weighting of a subset of the constructed splats. The weighting of the respective splats in the subset of splats for a pixel can be based at least in part on the coordinates of the respective pixel and the coordinates of the respective splat. As an example, a first pixel can have a determined color of yellow. Coordinates of a second pixel can be located a certain distance away from the first pixel, and a third pixel can be located an even further distance from the first pixel. The application of the first pixel splat (e.g., constructed at the coordinates of the first pixel, etc.) to the second pixel can be weighted more heavily than the application of the first pixel splat to the third pixel, as the second pixel is located closer to the first pixel than the third pixel is. As such, the weighting of the subset of splats in the determination of an updated color value for a pixel can be based on the proximity of each of the splats to the pixel. By determining the updated color values for each of the subset of splats, a differentiable two-dimensional rendering of the three-dimensional mesh can be generated. As such, the differentiable two-dimensional rendering (e.g., generated through application of the splats, etc.) can be utilized to find smooth derivatives at occlusion boundaries of the rendering.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the method computing rendering parameters for each of the pixels of the triangle by systematically evaluating each of the pixels of Hutchins with generating a two-dimensional differentiable rendering of the three- dimensional mesh of Genova because this modification would find smooth derivatives at occlusion boundaries of the rendering ([0029] of Genova) Both Hutchins and Genova are understood to be silent on the remaining limitations of claim 1.
In the same field of endeavor, Hickman teaches acquiring material information of a plurality of triangle primitives in a three- dimensional model (col.8, lines 43-58 “The 3D object data model may include material properties that are associated with geometry of the 3D object data model. In one example, the 3D object data model may include a list of geometry coordinates of vertices of a polygonal mesh having pointers to material attributes associated with the geometry coordinates. The material properties may identify appearance attributes or material shaders for the geometry coordinates. For example, the appearance attributes may be lighting values, texture coordinates, and/or colors that are provided as inputs for a material shader. The material shader may be configured to determine a pixel color or other rendering effect based on the appearance attributes. In another instance, the material properties may be texture maps, such as diffuse maps, bump maps, opacity maps, glow maps, or specular maps.”); generating model parameters of the three-dimensional model based on the material information of the triangle primitives (col. 7, lines 21-46 “In some examples, components of the client device 124 may be configured to refine material properties associated with a 3D object data model based on a comparison between a rendered view of a portion of the 3D object data model and a two-dimensional image of a product that is represented by the 3D object data model. For instance, the object data model render/viewer 126 may, in some examples, include a rendering component that is configured to render a view of a portion of a 3D object data model of an object. The view of the portion of the 3D object data model may be rendered by the rendering component based on material properties that are associated with geometry (e.g., coordinates of vertices of a polygonal mesh) of the 3D object data model. Additionally, a refinement component of the client device 124 may be configure to determine an appearance metric between an appearance of the portion in a rendered view and an appearance of the portion in a 2D image. Based on the appearance metric, the refinement component may also be configured to determine a modification to the material properties associated with the object, and provide the modified material properties to the rendering component. Also, a material component of the client device 124 may be configured to store the 3D object data model of the object having modified material properties for the portion. The modified material properties may be material properties which yield the minimum appearance metric of one or more determined appearance metrics, for example.” ; col.9,lines 43-56 “At block 306, the method 300 includes based on the first appearance metric, determining a modification to one or more of the material properties. In one example, the material properties may include a given shader that is configured to determine the pixel color of the portion in the rendered view. A different shader for the portion may be selected from a database, for example. The database may include multiple shaders for different types of materials, such as leather, wood, metal, plastic, rubber, etc. In some instances, a given type of material may include multiple shaders, and a different shader may be selected from within the shaders for the type of material. For example, a different shader may provide a different type of shading or may include bump mapping or translucency effects. ..”; col.10, lines 4-11 “ At block 308, the method 300 includes rendering another view of the portion of the 3D object data model based on the modification to the material properties. For instance after modified appearance attributes or a new shader has been selected, another view of the portion of the 3D object data model may be rendered. In some instances, the portion is rendered having the same orientation and viewpoint as the first rendered view.”);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the method computing rendering parameters for each of the pixels of the triangle by systematically evaluating each of the pixels of Hutchins and Genova with rendering component based on material properties that are associated with geometry of the 3D object model as seen in Hickman because this modification would render the view of the portion of the 3D object data model (col.8, lines 43-58 of Hickman) Hitchins, Genova and Hickman are understood to be silent on the remaining limitations of claim 1.
In the same field of endeavor, BAO teaches acquiring material information of a plurality of triangle primitives in a three- dimensional model, at least two triangle primitives in the plurality of triangle primitives having different material information ([0005] In a scene where a building is being rendered, the building can first be modeled to obtain a 3D model of the building, which has multiple faces. To make different faces of a building present different visual effects, different materials can be set for different faces. By applying different textures to different materials, faces with different textures can present different visual effects.”; [0022] By generating a single material identifier for the initial 3D model of the target image according to the material merging instruction, multiple material identifiers of the initial 3D model are merged into a single material identifier. Multiple vertices of the initial 3D model are then shading to obtain a first 3D model. The colors of these multiple vertices can then be used to identify multiple rendering parts of the initial 3D model. Texture offsetting of these vertex colors results in a second 3D model with multiple texture maps. These texture maps provide multiple display textures for the multiple rendering parts. Based on this material identifier, the drawing interface is called to render the second 3D model, obtaining the target image. This transforms the process from distinguishing different rendering parts by different material identifiers to distinguishing them by multiple vertex colors. Since the entire second 3D model uses a single material identifier, the drawing interface can be called only once for rendering, still resulting in a target image with rich visual effects. This reduces the number of times the drawing interface is called, avoids CPU overload, improves CPU processing efficiency, and ensures the normal operation of the terminal “; [0047] In step 201 above, the terminal can model the target image based on 3D modeling software. During the modeling process, a material identifier (material ID) is assigned to each of the multiple rendering parts of the initial 3D model, so that different rendering parts can be distinguished by different material identifiers. [0057] In the above process, for each of the original multiple material identifiers, the terminal can determine the multiple vertices included in the rendering part based on the rendering part corresponding to that material identifier. The multiple vertices can be points used to define the contour in the rendering part. For example, when a rendering part is a triangle, the rendering part includes 3 vertices, which are the 3 endpoints of the triangle.”)
generating model parameters of the three-dimensional model based on the material information of the triangle primitives ,the model parameters comprising rendering parameters of rasters in the three-dimensional model ([0022] By generating a single material identifier for the initial 3D model of the target image according to the material merging instruction, multiple material identifiers of the initial 3D model are merged into a single material identifier. Multiple vertices of the initial 3D model are then shading to obtain a first 3D model. The colors of these multiple vertices can then be used to identify multiple rendering parts of the initial 3D model. Texture offsetting of these vertex colors results in a second 3D model with multiple texture maps. These texture maps provide multiple display textures for the multiple rendering parts. Based on this material identifier, the drawing interface is called to render the second 3D model, obtaining the target image. This transforms the process from distinguishing different rendering parts by different material identifiers to distinguishing them by multiple vertex colors. Since the entire second 3D model uses a single material identifier, the drawing interface can be called only once for rendering, still resulting in a target image with rich visual effects. This reduces the number of times the drawing interface is called, avoids CPU overload, improves CPU processing efficiency, and ensures the normal operation of the terminal “; [0047] In step 201 above, the terminal can model the target image based on 3D modeling software. During the modeling process, a material identifier (material ID) is assigned to each of the multiple rendering parts of the initial 3D model, so that different rendering parts can be distinguished by different material identifiers. [0057] In the above process, for each of the original multiple material identifiers, the terminal can determine the multiple vertices included in the rendering part based on the rendering part corresponding to that material identifier. The multiple vertices can be points used to define the contour in the rendering part. For example, when a rendering part is a triangle, the rendering part includes 3 vertices, which are the 3 endpoints of the triangle.”; [0049] Figure 3 is a schematic diagram of an interface for setting multiple material identifiers provided in an embodiment of the present invention. Referring to Figure 3, the model of a three-story building in 3ds Max is used as an example for illustration. The model of the building can be divided into three rendering parts: the first floor exterior wall, the second floor exterior wall, and the third floor exterior wall. After selecting "first floor exterior wall" in the model, the user can set the material identifier for the first floor exterior wall through the "Set ID" option shown in Figure 3. For example, the material identifier can be selected as "Material ID (1)" [0058] For example, in the initial 3D model of a building, if the material identifier of the first-floor exterior wall is ID1, then the N1 vertices included in the first-floor exterior wall corresponding to ID1 can be determined; if the material identifier of the second-floor exterior wall is ID2, then the N2 vertices included in the second-floor exterior wall corresponding to ID2 can be determined; if the material identifier of the third-floor exterior wall is ID3, then the N3 vertices included in the third-floor exterior wall corresponding to ID3 can be determined, and so on for other rendering parts. Wherein, N1, N2 and N3 are all positive integers greater than or equal to 1. N1, N2 and N3 can be the same or different. This embodiment of the invention does not specifically limit the range of values for the number of vertices.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to computing rendering parameters for each of the pixels of the triangle by systematically evaluating each of the pixels of Hutchins, Genova, Hickman with including different materials as seen in BAO because modification would present different visual effects ([0005] of BAO).
Thus, the combination of Hutchins, Genova, Hickman and BAO teaches three-dimensional model rendering method performed by a computer device and the method comprising: acquiring material information of a plurality of triangle primitives in a three- dimensional model, at least two triangle primitives in the plurality of triangle primitives having different material information; generating model parameters of the three-dimensional model based on the material information of the triangle primitives, the model parameters comprising rendering parameters of rasters in the three-dimensional model; and rendering a two-dimensional image of the three-dimensional model based on the rendering parameters of the rasters.
Regarding claim 8, Hutchins, Genova, and BAO teach the method according to claim 1, wherein the rendering a two- dimensional image of the three-dimensional model based on the rendering parameters of the rasters comprises:
rendering an initial image of the three-dimensional model based on the rendering parameters of the rasters (see at least Genova: [0020] More particularly, a computing system can obtain a three-dimensional mesh. The three-dimensional mesh can be or otherwise include a plurality of polygons and associated texture data and/or associated shading data. As an example, the three-dimensional mesh can be a mesh representation of an object, and the associated shading and/or texture data can indicate a one or more colors for the polygons of the three-dimensional mesh (e.g., a texture data for a character model mesh in a video game, etc.). In some implementations, the three- dimensional mesh can be generated using one or more machine-learning techniques”; [0021] “As another example, the three-dimensional mesh can represent pose and/or orientation adjustments to a first three-dimensional mesh. For example, a machine-learned model can process a first three-dimensional mesh at a first pose and/or orientation and obtain a second three-dimensional mesh at a second pose and/or orientation different from the first. Thus, the three-dimensional mesh and the associated texture/ shading data can, in some implementations, be an output of a machine-learned model, and as such, the capacity to generate smooth derivatives for a rendering of the three-dimensional mesh (e.g., at occlusion boundaries, etc.) can be necessary to optimize the machine-learned model used to generate the three-dimensional mesh.”; Hickman: at least col.3, lines 26-42 “This disclosure may disclose, inter alia, methods and systems for shader and material layers for rendering three-dimensional (3D) object data models. In some examples, a client device may receive a 3D object data model from a server and render a representation of the 3D object data model by executing a shader layer and a materials layer for various components of the 3D object data model. For instance, the 3D object data model may include components made of different types of materials, and the components may be separated based on type of material. Additionally, individual types of materials may be assigned a given shader to facilitate rendering the material. When a client device receives a 3D object data model, the client device may also receive shader and material information for the various components of the 3D object data model, and render the various components of the 3D object data model using the respective shaders for each type of material.”; col.10, lines 4-11 “ At block 308, the method 300 includes rendering another view of the portion of the 3D object data model based on the modification to the material properties. For instance after modified appearance attributes or a new shader has been selected, another view of the portion of the 3D object data model may be rendered. In some instances, the portion is rendered having the same orientation and viewpoint as the first rendered view.” see BAO: at least [0112] The apparatus provided in this invention generates a single material identifier for an initial 3D model of a target image according to a material merging instruction, thereby merging multiple material identifiers of the initial 3D model into a single material identifier. It then performs coloring processing on multiple vertices of the initial 3D model to obtain a first 3D model. This allows the multiple rendering parts of the initial 3D model to be identified by the colors of its multiple vertices. Finally, it performs texture offset on the colors of these multiple vertices of the first 3D model to obtain a second 3D model with multiple texture maps. These texture maps provide multiple display textures for the multiple rendering parts. Based on the material identifier, it calls a drawing interface to render the second 3D model, obtaining the target image. This transforms the process from distinguishing different rendering parts by different material identifiers to distinguishing them by multiple vertex colors. Since the entire second 3D model uses a single material identifier, rendering can be performed by calling the drawing interface only once, still obtaining a target image with rich visual effects. This reduces the number of times the drawing interface is called, avoids CPU overload, improves CPU processing efficiency, and ensures the normal operation of the terminal.”); and
updating the initial image of the three-dimensional model to obtain the two- dimensional image of the three-dimensional model (see at least col.9,lines 1-35, col. 14, lines 21-54 of Hutchins, see Genova [0022] The computing system can rasterize the three-dimensional mesh to obtain a two- dimensional raster of the three-dimensional mesh. The two-dimensional raster can be or otherwise include a plurality of pixels and a plurality of coordinates respectively associated with a subset of the plurality of pixels (e.g., by sampling the surface of the three-dimensional mesh, etc.). These coordinates can describe the locations of pixels relative to the vertices of the polygons in which the pixels are located. As an example, a first coordinate can describe a location of a first pixel relative to the vertices of a first polygon in which the first pixel is located. A second coordinate can describe a location of a second pixel relative to the vertices of a second polygon in which the second pixel is located. In some implementations, each of the plurality of coordinates can be or otherwise include barycentric coordinates.”; [0029] The computing system can determine an updated color value for each of the subset of pixels to generate a two-dimensional differentiable rendering of the three- dimensional mesh. The updated color value can be based on a weighting of a subset of the constructed splats. The weighting of the respective splats in the subset of splats for a pixel can be based at least in part on the coordinates of the respective pixel and the coordinates of the respective splat. As an example, a first pixel can have a determined color of yellow. Coordinates of a second pixel can be located a certain distance away from the first pixel, and a third pixel can be located an even further distance from the first pixel. The application of the first pixel splat (e.g., constructed at the coordinates of the first pixel, etc.) to the second pixel can be weighted more heavily than the application of the first pixel splat to the third pixel, as the second pixel is located closer to the first pixel than the third pixel is. As such, the weighting of the subset of splats in the determination of an updated color value for a pixel can be based on the proximity of each of the splats to the pixel. By determining the updated color values for each of the subset of splats, a differentiable two-dimensional rendering of the three-dimensional mesh can be generated. As such, the differentiable two-dimensional rendering (e.g., generated through application of the splats, etc.) can be utilized to find smooth derivatives at occlusion boundaries of the rendering.”;) In addition, the same motivation is used in the rejection for claim 1.
Regarding claim 9, Hutchins, Genova, and BAO teach the method according to claim 8, wherein the rendering an initial image of the three-dimensional model based on the rendering parameters of the rasters comprises:
performing material rendering on a raster based on a material parameter in rendering parameters of the raster (see at least Hutchins,col.9, lines 1-10 “As described above, the raster stage 410 receives data from setup stage 405 regarding triangles (e.g., polygons) that are to be rendered (e.g., converted into pixels). This is illustrated in FIG. 6 as the triangle 630 propagating down to the raster stage 410 from the set up stage 405. The triangle 630 comprises a geometric primitive having associated therewith instructions (e.g., instructions 631) indicating the manner in which the triangle is to be rasterized and rendered, and primitive data (e.g., parameter data such as color, texture coordinates, transparency, xy, depth, etc.).Genova: see at least [0020] More particularly, a computing system can obtain a three-dimensional mesh. The three-dimensional mesh can be or otherwise include a plurality of polygons and associated texture data and/or associated shading data. As an example, the three-dimensional mesh can be a mesh representation of an object, and the associated shading and/or texture data can indicate a one or more colors for the polygons of the three-dimensional mesh (e.g., a texture data for a character model mesh in a video game, etc.). In some implementations, the three- dimensional mesh can be generated using one or more machine-learning techniques”; [0021] “As another example, the three-dimensional mesh can represent pose and/or orientation adjustments to a first three-dimensional mesh. For example, a machine-learned model can process a first three-dimensional mesh at a first pose and/or orientation and obtain a second three-dimensional mesh at a second pose and/or orientation different from the first. Thus, the three-dimensional mesh and the associated texture/ shading data can, in some implementations, be an output of a machine-learned model, and as such, the capacity to generate smooth derivatives for a rendering of the three-dimensional mesh (e.g., at occlusion boundaries, etc.) can be necessary to optimize the machine-learned model used to generate the three-dimensional mesh.” Hickman: at least col.3, lines 26-42 “This disclosure may disclose, inter alia, methods and systems for shader and material layers for rendering three-dimensional (3D) object data models. In some examples, a client device may receive a 3D object data model from a server and render a representation of the 3D object data model by executing a shader layer and a materials layer for various components of the 3D object data model. For instance, the 3D object data model may include components made of different types of materials, and the components may be separated based on type of material. Additionally, individual types of materials may be assigned a given shader to facilitate rendering the material. When a client device receives a 3D object data model, the client device may also receive shader and material information for the various components of the 3D object data model, and render the various components of the 3D object data model using the respective shaders for each type of material.”; col.10, lines 4-11 “ At block 308, the method 300 includes rendering another view of the portion of the 3D object data model based on the modification to the material properties. For instance after modified appearance attributes or a new shader has been selected, another view of the portion of the 3D object data model may be rendered. In some instances, the portion is rendered having the same orientation and viewpoint as the first rendered view.”;see BAO: at least [0058] For example, in the initial 3D model of a building, if the material identifier of the first-floor exterior wall is ID1, then the N1 vertices included in the first-floor exterior wall corresponding to ID1 can be determined; if the material identifier of the second-floor exterior wall is ID2, then the N2 vertices included in the second-floor exterior wall corresponding to ID2 can be determined; if the material identifier of the third-floor exterior wall is ID3, then the N3 vertices included in the third-floor exterior wall corresponding to ID3 can be determined, and so on for other rendering parts. Wherein, N1, N2 and N3 are all positive integers greater than or equal to 1. N1, N2 and N3 can be the same or different. This embodiment of the invention does not specifically limit the range of values for the number of vertices. [0059] 204. The terminal sets the same vertex color for the multiple vertices of the rendering part, and the vertex color is used to uniquely identify the rendering part.”;
performing color rendering on the raster based on a color parameter in the rendering parameters of the raster (see at least Hutchins col.7, lines 14-19 “ The output of ALU pipeline 440 goes to data write stage 455. The data write stage 455 converts pixel packets into pixel data and stores the result (e.g., color, z depths, etc.) in a write buffer 452 or directly to a frame buffer in memory. Examples of functions that data write stage 455 may perform include color and depth write back, and format conversion.”; col.7, lines 56-67-col.1, lines 1-9 “The outputs of the interpolators 501-508 are used to construct a plurality of pixel packet rows (e.g., a data structure in a memory array). In the present embodiment, a programmable packing logic module 510 (e.g., including a crossbar switch) functions by arranging the outputs of the interpolators 501-508 into a pixel packet row and formatting the fields of the row for the pixel parameters required for subsequent processing (e.g., color, texture, depth, fog, etc.). The placement of the outputs (e.g., of the interpolators 501-508) into the rows is programmable. In addition to these parameters, the packing logic module 510 arranges processing instructions (e.g., for the subsequent operations to be performed on the pixel packet) into the pixel packet row. For example, as a pixel is iterated, the computed parameters produced by the interpolators 501-508 enable subsequent stages of the graphics pipeline to fetch the required surface attributes (e.g., color, texture, etc.) needed to complete the pixel's rendering. For a simple 3D scene, a given pixel can be described using a single row (e.g., a one row pixel packet). In comparison, for a more complex 3D scene, a given pixel description may require a plurality of rows (e.g., a four row pixel packet)”; col.9, lines 1-10 “As described above, the raster stage 410 receives data from setup stage 405 regarding triangles (e.g., polygons) that are to be rendered (e.g., converted into pixels). This is illustrated in FIG. 6 as the triangle 630 propagating down to the raster stage 410 from the set up stage 405. The triangle 630 comprises a geometric primitive having associated therewith instructions (e.g., instructions 631) indicating the manner in which the triangle is to be rasterized and rendered, and primitive data (e.g., parameter data such as color, texture coordinates, transparency, xy, depth, etc.).; Genova: see at least [0020] More particularly, a computing system can obtain a three-dimensional mesh. The three-dimensional mesh can be or otherwise include a plurality of polygons and associated texture data and/or associated shading data. As an example, the three-dimensional mesh can be a mesh representation of an object, and the associated shading and/or texture data can indicate a one or more colors for the polygons of the three-dimensional mesh (e.g., a texture data for a character model mesh in a video game, etc.). In some implementations, the three- dimensional mesh can be generated using one or more machine-learning techniques”; [0021] “As another example, the three-dimensional mesh can represent pose and/or orientation adjustments to a first three-dimensional mesh. For example, a machine-learned model can process a first three-dimensional mesh at a first pose and/or orientation and obtain a second three-dimensional mesh at a second pose and/or orientation different from the first. Thus, the three-dimensional mesh and the associated texture/ shading data can, in some implementations, be an output of a machine-learned model, and as such, the capacity to generate smooth derivatives for a rendering of the three-dimensional mesh (e.g., at occlusion boundaries, etc.) can be necessary to optimize the machine-learned model used to generate the three-dimensional mesh.” ; Hickman: see at least col.9, lines 63-67-col.1, lines 1-11 “…In another example, appearance attributes associated with the portion of the 3D object data model may be modified. For example, the portion of the 3D object data model may include a base color, texture coordinates, and lighting information, among other parameters, which are used by a shader to determine a final pixel color that is rendered or displayed on a screen. Any of the appearance attributes may be modified based on the appearance metric…”; BAO: see at least [0059] 204. The terminal sets the same vertex color for the multiple vertices of the rendering part, and the vertex color is used to uniquely identify the rendering part. [0060] The vertex color can be any color. This embodiment of the invention does not specifically limit the vertex color of each rendering part. It should be noted that for the same rendering part, the vertices of the rendering part have the same vertex color. However, since the vertex color is used to uniquely identify a rendering part, the vertices of different rendering parts have different vertex…[0064] Based on the above example, assuming RGB three-channel recording of vertex colors, in 3ds Max, vertex colors can be set using the built-in Max Script language: For the N1 vertices included in the first-floor outer wall, the R, G, and B channels in the vertex properties of these N1 vertices can all be set to 0 (R: 0, G: 0, B: 0), thus setting the vertex color of these N1 vertices to black; For the N2 vertices included in the second-floor outer wall, the R and G channels in the vertex properties of these N2 vertices can all be set to 0, and the B channel can be set to 1 (R: 0, G: 0, B: 1), thus setting the vertex color of these N2 vertices to blue; For the N3 vertices included in the third-floor outer wall, the R and B channels in the vertex properties of these N3 vertices can all be set to 0, and the G channel can all be set to 1 (R: 0, G: 1, B: 0), thus setting the vertex color of these N3 vertices to green.”)
performing depth rendering on the raster based on a depth parameter in the rendering parameters of the raster (Hutchins col.7, lines 14-19 “ The output of ALU pipeline 440 goes to data write stage 455. The data write stage 455 converts pixel packets into pixel data and stores the result (e.g., color, z depths, etc.) in a write buffer 452 or directly to a frame buffer in memory. Examples of functions that data write stage 455 may perform include color and depth write back, and format conversion.”; col.7, lines 56-67-col.1, lines 1-9 “The outputs of the interpolators 501-508 are used to construct a plurality of pixel packet rows (e.g., a data structure in a memory array). In the present embodiment, a programmable packing logic module 510 (e.g., including a crossbar switch) functions by arranging the outputs of the interpolators 501-508 into a pixel packet row and formatting the fields of the row for the pixel parameters required for subsequent processing (e.g., color, texture, depth, fog, etc.). The placement of the outputs (e.g., of the interpolators 501-508) into the rows is programmable. In addition to these parameters, the packing logic module 510 arranges processing instructions (e.g., for the subsequent operations to be performed on the pixel packet) into the pixel packet row. For example, as a pixel is iterated, the computed parameters produced by the interpolators 501-508 enable subsequent stages of the graphics pipeline to fetch the required surface attributes (e.g., color, texture, etc.) needed to complete the pixel's rendering. For a simple 3D scene, a given pixel can be described using a single row (e.g., a one row pixel packet). In comparison, for a more complex 3D scene, a given pixel description may require a plurality of rows (e.g., a four row pixel packet).”; ol.9, lines 1-10 “As described above, the raster stage 410 receives data from setup stage 405 regarding triangles (e.g., polygons) that are to be rendered (e.g., converted into pixels). This is illustrated in FIG. 6 as the triangle 630 propagating down to the raster stage 410 from the set up stage 405. The triangle 630 comprises a geometric primitive having associated therewith instructions (e.g., instructions 631) indicating the manner in which the triangle is to be rasterized and rendered, and primitive data (e.g., parameter data such as color, texture coordinates, transparency, xy, depth, etc.); col.14,lines 27-42 of Hutchins “In one embodiment, the raster stage 410 accesses the primitives comprising the polygon 1401 (e.g., triangle) and rasterizes the triangle into its constituent pixels. The bounding box 1411 is used by the rasterizer module (e.g., rasterizer) of the raster stage 410 in the rasterization process of the triangle 1401. Associated parameters for each pixel are then interpolated from the vertices 1411-1413. These parameters include a depth parameter, z. During rasterization of the triangle 1401, respective z values are interpolated by the raster stage 410 for each pixel of the triangle 1401. Each z value is represented within a predefined numerical range (e.g., an integer portion of zero and a fractional portion ranging from zero to one) which substantially corresponds to a depth range between a near clipping plane 1408 and a far clipping plane 1407, as related to a view volume. Z values outside the clipping planes are not screen displayable positions.” ;Genova: see at least [0020] More particularly, a computing system can obtain a three-dimensional mesh. The three-dimensional mesh can be or otherwise include a plurality of polygons and associated texture data and/or associated shading data. As an example, the three-dimensional mesh can be a mesh representation of an object, and the associated shading and/or texture data can indicate a one or more colors for the polygons of the three-dimensional mesh (e.g., a texture data for a character model mesh in a video game, etc.). In some implementations, the three- dimensional mesh can be generated using one or more machine-learning techniques”; [0021] “As another example, the three-dimensional mesh can represent pose and/or orientation adjustments to a first three-dimensional mesh. For example, a machine-learned model can process a first three-dimensional mesh at a first pose and/or orientation and obtain a second three-dimensional mesh at a second pose and/or orientation different from the first. Thus, the three-dimensional mesh and the associated texture/ shading data can, in some implementations, be an output of a machine-learned model, and as such, the capacity to generate smooth derivatives for a rendering of the three-dimensional mesh (e.g., at occlusion boundaries, etc.) can be necessary to optimize the machine-learned model used to generate the three-dimensional mesh.”; BAO: [0016] The shading module is used to shading multiple vertices of the initial 3D model to obtain a first 3D model. The colors of multiple vertices of the first 3D model are used to identify multiple rendering parts of the initial 3D model. [0017] The offset module is used to perform texture offset on the colors of the multiple vertices of the first 3D model to obtain a second 3D model with multiple texture maps, which are used to provide multiple display textures for the multiple rendering parts;”); and
performing texture rendering on the raster based on a texture parameter in the rendering parameters of the raster (see at least Hutchins; col.7, lines 56-67-col.1, lines 1-9 “The outputs of the interpolators 501-508 are used to construct a plurality of pixel packet rows (e.g., a data structure in a memory array). In the present embodiment, a programmable packing logic module 510 (e.g., including a crossbar switch) functions by arranging the outputs of the interpolators 501-508 into a pixel packet row and formatting the fields of the row for the pixel parameters required for subsequent processing (e.g., color, texture, depth, fog, etc.). The placement of the outputs (e.g., of the interpolators 501-508) into the rows is programmable. In addition to these parameters, the packing logic module 510 arranges processing instructions (e.g., for the subsequent operations to be performed on the pixel packet) into the pixel packet row. For example, as a pixel is iterated, the computed parameters produced by the interpolators 501-508 enable subsequent stages of the graphics pipeline to fetch the required surface attributes (e.g., color, texture, etc.) needed to complete the pixel's rendering. For a simple 3D scene, a given pixel can be described using a single row (e.g., a one row pixel packet). In comparison, for a more complex 3D scene, a given pixel description may require a plurality of rows (e.g., a four row pixel packet)”; col.9, lines 1-10 “As described above, the raster stage 410 receives data from setup stage 405 regarding triangles (e.g., polygons) that are to be rendered (e.g., converted into pixels). This is illustrated in FIG. 6 as the triangle 630 propagating down to the raster stage 410 from the set up stage 405. The triangle 630 comprises a geometric primitive having associated therewith instructions (e.g., instructions 631) indicating the manner in which the triangle is to be rasterized and rendered, and primitive data (e.g., parameter data such as color, texture coordinates, transparency, xy, depth, etc.). “; Genova: see at least [0020] More particularly, a computing system can obtain a three-dimensional mesh. The three-dimensional mesh can be or otherwise include a plurality of polygons and associated texture data and/or associated shading data. As an example, the three-dimensional mesh can be a mesh representation of an object, and the associated shading and/or texture data can indicate a one or more colors for the polygons of the three-dimensional mesh (e.g., a texture data for a character model mesh in a video game, etc.). In some implementations, the three- dimensional mesh can be generated using one or more machine-learning techniques”; [0021] “As another example, the three-dimensional mesh can represent pose and/or orientation adjustments to a first three-dimensional mesh. For example, a machine-learned model can process a first three-dimensional mesh at a first pose and/or orientation and obtain a second three-dimensional mesh at a second pose and/or orientation different from the first. Thus, the three-dimensional mesh and the associated texture/ shading data can, in some implementations, be an output of a machine-learned model, and as such, the capacity to generate smooth derivatives for a rendering of the three-dimensional mesh (e.g., at occlusion boundaries, etc.) can be necessary to optimize the machine-learned model used to generate the three-dimensional mesh.”; Hickman: see at least col.9, lines 63-67-col.1, lines 1-11 “…In another example, appearance attributes associated with the portion of the 3D object data model may be modified. For example, the portion of the 3D object data model may include a base color, texture coordinates, and lighting information, among other parameters, which are used by a shader to determine a final pixel color that is rendered or displayed on a screen. Any of the appearance attributes may be modified based on the appearance metric…”; see BAO: at least [0087] Taking an example with 8 rendering parts, Figure 6 is a schematic diagram of an interface for setting multiple texture identifiers provided by an embodiment of the present invention. Referring to Figure 6, the 8 vertex colors corresponding to the 8 rendering parts are represented by vectors v1 (x1, y1, z1, w1) and v2 (x2, y2, z2, w2). The texture coordinate x1 of vector v1 corresponds to the vertex color (black) of the first floor exterior wall, the texture coordinate y1 of vector v1 corresponds to the vertex color (blue) of the second floor exterior wall, the texture coordinate z1 of vector v1 corresponds to the vertex color (green) of the third floor exterior wall, and so on. Each texture coordinate of vector v1 and vector v2 corresponds to the vertex color of a rendering part. [0088] In the above example, by assigning x1=16 to x1, the texture map with texture identifier 16 in the target map set can be associated with the black area in the first 3D model. By assigning y1=17 to y1, the texture map with texture identifier 17 in the target map set can be associated with the blue area in the first 3D model. By assigning z1=18 to z1, the texture map with texture identifier 18 in the target map set can be associated with the green area in the first 3D model, and so on. This will not be elaborated further. Of course, the coordinate values of the texture coordinates can be assigned any values according to the actual needs of the target image. This embodiment of the invention does not specifically limit the values of the texture coordinates.”) In addition, the same motivation is used as the rejection for claim 1
Regarding independent claim 10, Hutchins teaches a computer device, comprising a processor and a memory, the memory storing at least one instruction that, when loaded and executed by the processor, causes the computer device to implement a three-dimensional model rendering (col.5, lines 8-34“. ..As depicted in FIG. 2, the computer system 200 includes a CPU 201 coupled to a graphics processor 205 via a host interface 202. The host interface 202 translates data and commands passing between the CPU 201 and the graphics processor 205 into their respective formats. Both the CPU 201 and the graphics processor 205 are coupled to a memory 221 via a memory controller 220…As described above, certain processes and steps of the present invention are realized, in one embodiment, as a series of instructions (e.g., software program) that reside within computer readable memory (e.g., memory 221) of a computer system (e.g., system 200) and are executed by the CPU 201 and graphics processor 205 of system 200. When executed, the instructions cause the computer system 200 to implement the functionality of the present invention as described below.”; Fig. 1, col. 1, lines 36-51) method including: Remaining limitations of claim 10 is similar scope to claim 1 and therefore rejected under the same rational.
Regarding claim 17, Hutchins, Genova and BAO teach the computer device according to claim 10, Remaining limitations of claim 17 is similar scope to claim 8 and therefore rejected under the same rational.
Regarding claim 18, Hutchins, Genova and BAO teach the computer device according to claim 17, Remaining limitations of claim 18 is similar scope to claim 9 and therefore rejected under the same rational.
Regarding claim 19, Hutchins teaches a non-transitory computer-readable storage medium, storing at least one instruction that, when loaded and executed by a processor of a computer device, causes the computer device to implement a three-dimensional model rendering (col.5, lines 55-67 “Computer system 300 is substantially similar to computer system 200 of FIG. 2. Computer system 300, however, utilizes the processor 201 having a dedicated system memory 321, and the graphics processor 205 having a dedicated graphics memory 322. In the system 300 embodiment, the system memory 321 stores instructions and data for processes/threads executing on the CPU 201 and the graphics memory 322 stores instructions and data for those processes/threads executing on the graphics processor 205. The graphics memory 322 stores data the video frame buffer which drives the display 225”; Fig. 1, col. 1, lines 36-51) method including: Remaining limitations of claim 19 is similar scope to claim 1 and therefore rejected under the same rational.
Regarding claim 20, Hutchins, Genova and BAO teach the non-transitory computer-readable storage medium according to claim 19, Remaining limitations of claim 20 is similar scope to claim 8 and therefore rejected under the same rational.
2. Claims 2-4, 11-13 are rejected under 35 U.S.C. 103 as being unpatentable over Hutchins, U.S Patent No. 8432394 (Hutchins”) in view of Genova et al,. WO2022046113A1, (“Genova”) further in view of Hickman et al., U.S Patent No.825846 (“Hickman”) further in view of BAO et al, IDS, CN109961498A (English translated) (“BAO”) further in view of Crassin et al., U.S Patent Application Publication No. 20150317827 (“Crassin”)
Regarding claim 2, Hutchins, Genova, Hickman and BAO teach the method according to claim 1, wherein the rendering parameters of a raster comprise a material parameter of the raster and another rendering parameter of the raster (see at least col.6, lines 34-51 of Hutchins “ “Raster stage 410 receives data from setup stage 405 regarding triangles that are to be rendered (e.g., converted into pixels). Raster stage 410 processes parameters for each pixel of a given triangle by interpolation and determines shader attributes that need to be interpolated for a pixel as part of rendering, such as calculating color, texture, and fog blend factors. In one embodiment, raster stage 410 calculates barycentric coordinates for pixel packets. In a barycentric coordinate system, distances in a triangle are measured with respect to its vertices. The use of barycentric coordinates reduces the required dynamic range, which permits using fixed point calculations that require less power than floating point calculations. Raster stage 410 generates at least one pixel packet for each pixel of a triangle that is to be processed. Each pixel packet includes fields for a payload of pixel attributes required for processing (e.g., color, texture, depth, fog, (x,y) location) along with sideband information, and an instruction sequence of operations to be performed on the pixel packet. An instruction area in raster stage 410 (not shown) assigns instruction sequence numbers to pixel packets. The sideband information may also include a valid field, and a kill field. The pixel packet may include one or more rows of pixel information.”; see at least [0022] of Genova “The computing system can rasterize the three-dimensional mesh to obtain a two- dimensional raster of the three-dimensional mesh. The two-dimensional raster can be or otherwise include a plurality of pixels and a plurality of coordinates respectively associated with a subset of the plurality of pixels (e.g., by sampling the surface of the three-dimensional mesh, etc.). These coordinates can describe the locations of pixels relative to the vertices of the polygons in which the pixels are located. As an example, a first coordinate can describe a location of a first pixel relative to the vertices of a first polygon in which the first pixel is located. A second coordinate can describe a location of a second pixel relative to the vertices of a second polygon in which the second pixel is located. In some implementations, each of the plurality of coordinates can be or otherwise include barycentric coordinates.”; [0025] The computing system can determine an initial color value for each pixel of the subset of pixels. The initial color value can be based on the coordinates of the pixel and the associated shading data and/or the associated texture data. As an example, the polygon coordinates for a first pixel can indicate that the first pixel is located in a first polygon. Based on the shading and/or texture data, the polygon can be determined to have an orange color where the pixel is located (e.g., with respect to the polygon’s vertices, etc.). The first pixel can be colored orange based on the pixel coordinates and the shading and/or texture data. [0026] More particularly, in some implementations, the polygon identifier and coordinates for each pixel can allow for perspective-correct interpolation of vertex attributes (e.g., of the polygons of the three-dimensional mesh, etc.) to determine a color for the pixel. In some implementations, the determination of the color for each pixel can include application of the shading data and/or the texture data to the two-dimensional raster using a shading and/or texturing scheme. For either application, any sort of application scheme can be used. As an example, a deferred-shading, image-space application scheme can be used to apply the shading data and/or the texture data to determine a color for each of the subset of pixels.”; see at least col.8,lines 44-58 of Hickman “The 3D object data model may include material properties that are associated with geometry of the 3D object data model. In one example, the 3D object data model may include a list of geometry coordinates of vertices of a polygonal mesh having pointers to material attributes associated with the geometry coordinates. The material properties may identify appearance attributes or material shaders for the geometry coordinates. For example, the appearance attributes may be lighting values, texture coordinates, and/or colors that are provided as inputs for a material shader. The material shader may be configured to determine a pixel color or other rendering effect based on the appearance attributes. In another instance, the material properties may be texture maps, such as diffuse maps, bump maps, opacity maps, glow maps, or specular maps.”; see at least [0022] of BAO By generating a single material identifier for the initial 3D model of the target image according to the material merging instruction, multiple material identifiers of the initial 3D model are merged into a single material identifier. Multiple vertices of the initial 3D model are then shading to obtain a first 3D model. The colors of these multiple vertices can then be used to identify multiple rendering parts of the initial 3D model. Texture offsetting of these vertex colors results in a second 3D model with multiple texture maps. These texture maps provide multiple display textures for the multiple rendering parts. Based on this material identifier, the drawing interface is called to render the second 3D model, obtaining the target image. This transforms the process from distinguishing different rendering parts by different material identifiers to distinguishing them by multiple vertex colors. Since the entire second 3D model uses a single material identifier, the drawing interface can be called only once for rendering, still resulting in a target image with rich visual effects. This reduces the number of times the drawing interface is called, avoids CPU overload, improves CPU processing efficiency, and ensures the normal operation of the terminal “), the rasters in the three-dimensional model comprise vertex rasters and non-vertex rasters (see at least col.6, lines 34-51 of Hutchins “ “Raster stage 410 receives data from setup stage 405 regarding triangles that are to be rendered (e.g., converted into pixels). Raster stage 410 processes parameters for each pixel of a given triangle by interpolation and determines shader attributes that need to be interpolated for a pixel as part of rendering, such as calculating color, texture, and fog blend factors. In one embodiment, raster stage 410 calculates barycentric coordinates for pixel packets. In a barycentric coordinate system, distances in a triangle are measured with respect to its vertices. The use of barycentric coordinates reduces the required dynamic range, which permits using fixed point calculations that require less power than floating point calculations. Raster stage 410 generates at least one pixel packet for each pixel of a triangle that is to be processed. Each pixel packet includes fields for a payload of pixel attributes required for processing (e.g., color, texture, depth, fog, (x,y) location) along with sideband information, and an instruction sequence of operations to be performed on the pixel packet. An instruction area in raster stage 410 (not shown) assigns instruction sequence numbers to pixel packets. The sideband information may also include a valid field, and a kill field. The pixel packet may include one or more rows of pixel information.”; [0023] of Genova “In some implementations, the two-dimensional raster can also include a plurality of polygon identifiers for each of the subset of pixels. The polygon identifiers can be configured to identify, for each pixel, one or more polygons that a respective pixel is located within. As an example, a pixel can be located within two or more overlapping polygons of the plurality of polygons (e.g., as the polygons of the three-dimensional mesh are represented in two dimensions, etc.). The polygon identifier for the pixel would identify that the pixel is located within both polygons. Additionally, in some implementations, the polygon identifier can identify a front-facing polygon when a pixel is located within two or more overlapping polygons. As an example, the three-dimensional mesh can represent a cube. A pixel of the two-dimensional raster of the three-dimensional mesh can be located inside a polygon of a first side of the cube and anon-visible (e.g., from two dimensions) polygon on an opposite side of the cube. The polygon identifier can indicate that the polygon on the first side of the cube is the front-facing polygon. In such fashion, the polygon identifier can be utilized to ensure that a color applied to the pixel is associated with the polygon facing the viewpoint of the two-dimensional raster. ;); and
the generating model parameters of the three-dimensional model based on the material information of the triangle primitives comprises:
performing rasterization on the three-dimensional model to obtain at least one raster in the three-dimensional model and a barycentric coordinate system of a triangle primitive in the three-dimensional model (see at least: Hutchins, col.6,lines 29-46 “Raster stage 410 receives data from setup stage 405 regarding triangles that are to be rendered (e.g., converted into pixels). Raster stage 410 processes parameters for each pixel of a given triangle by interpolation and determines shader attributes that need to be interpolated for a pixel as part of rendering, such as calculating color, texture, and fog blend factors. In one embodiment, raster stage 410 calculates barycentric coordinates for pixel packets. In a barycentric coordinate system, distances in a triangle are measured with respect to its vertices. The use of barycentric coordinates reduces the required dynamic range, which permits using fixed point calculations that require less power than floating point calculations.”; [0022] of Genova “The computing system can rasterize the three-dimensional mesh to obtain a two- dimensional raster of the three-dimensional mesh. The two-dimensional raster can be or otherwise include a plurality of pixels and a plurality of coordinates respectively associated with a subset of the plurality of pixels (e.g., by sampling the surface of the three-dimensional mesh, etc.). These coordinates can describe the locations of pixels relative to the vertices of the polygons in which the pixels are located. As an example, a first coordinate can describe a location of a first pixel relative to the vertices of a first polygon in which the first pixel is located. A second coordinate can describe a location of a second pixel relative to the vertices of a second polygon in which the second pixel is located. In some implementations, each of the plurality of coordinates can be or otherwise include barycentric coordinates.),
inserting, based on a position of the raster and a position of the triangle primitive, material information into the raster to generate a material parameter of the raster (see at least: Hutchins, col.7, lines 38-49 “The raster stage 410 advantageously utilizes an array of programmable interpolators 501-508 to compute the parameters in parallel. As the raster stage 410 walks each pixel, the parameters for that pixel are iterated, and the resulting data is passed down to subsequent stages of the pipeline (e.g., as a pixel packet). The interpolated results can be placed in programmably selectable positions in the pixel packet. As is generally known, complex 3D scenes can typically have a large number of polygons, and additionally, a large number of rendering parameters for each polygon. Such parameters include, for example, color, texture coordinates, transparency, depth, level of detail (LOD), and the like. A real-time 3D rendering pipeline needs to perform many millions of calculations per second to maintain the pixel throughput (e.g., fill rate) required to draw a realistic 60-70 frames per second. The raster stage 410 utilizes the parallel array of interpolators 501-508 to maintain the required pixel fill rate while conserving power consumption and silicon area.”; Genova [0079] More particularly, in some implementations, the polygon identifiers 306B and coordinates for each pixel 306A can allow for perspective-correct interpolation of vertex attributes by the color determinator 308 (e.g., of the polygons 302A of the three-dimensional mesh 302, etc.) to determine a color for the pixel. In some implementations, the determination of the color for each pixel by the color determinator 308 can include application of the shading data and/or the texture data 302B to the two-dimensional raster 306 using a shading and/or texturing scheme. For either application, any sort of application scheme can be used by the color determinator 308. As an example, a deferred-shading, image-space application scheme can be used by the color determinator 308to apply the shading data and/or the texture data 302B and therefore to determine the initial color values 310 for the pixels 306 A.”; col.6,lines 5-28 of Hickman “The shader application 118 may be configured to apply a shader to portions of the 3D object data model file or files of the 3D object data model according to the indexes of the file (as labeled by the semantics and search index 114) to generate a 3D image. The shader application 118 may be executed to apply a shader from a number of shaders according to the indexes of the file. The shader may include information related to texture, color, appearance, etc., of a portion of the 3D image. .. The materials application 120 may be configured to apply a material to portions of the 3D object data model file or to files of the 3D object data model according to the indexes of the file (as labeled by the semantics and search index 114) to generate a 3D image. The materials application 120 may be executed to apply a material from a number of materials according to the indexes of the file. The materials application may apply any material, such as leather, metal, wood, etc., so as to render an appearance of a portion of the 3D image.”; [0022] of BAO” By generating a single material identifier for the initial 3D model of the target image according to the material merging instruction, multiple material identifiers of the initial 3D model are merged into a single material identifier. Multiple vertices of the initial 3D model are then shading to obtain a first 3D model. The colors of these multiple vertices can then be used to identify multiple rendering parts of the initial 3D model. Texture offsetting of these vertex colors results in a second 3D model with multiple texture maps. These texture maps provide multiple display textures for the multiple rendering parts. Based on this material identifier, the drawing interface is called to render the second 3D model, obtaining the target image..”.); and
generating another rendering parameter of a non-vertex raster based on the barycentric coordinate system of the triangle primitive and the another rendering parameter of a vertex raster of the triangle primitive (see at least col.14,lines 27-42 of Hutchins “In one embodiment, the raster stage 410 accesses the primitives comprising the polygon 1401 (e.g., triangle) and rasterizes the triangle into its constituent pixels. The bounding box 1411 is used by the rasterizer module (e.g., rasterizer) of the raster stage 410 in the rasterization process of the triangle 1401. Associated parameters for each pixel are then interpolated from the vertices 1411-1413. These parameters include a depth parameter, z. During rasterization of the triangle 1401, respective z values are interpolated by the raster stage 410 for each pixel of the triangle 1401. Each z value is represented within a predefined numerical range (e.g., an integer portion of zero and a fractional portion ranging from zero to one) which substantially corresponds to a depth range between a near clipping plane 1408 and a far clipping plane 1407, as related to a view volume. Z values outside the clipping planes are not screen displayable positions.”; col.15, lines 3-39 “Thus, for example, even though a z stepper of the raster stage 410 may begin at -2.0 z value, by the time the raster stage 410 steps into the view volume (e.g., z values between 0.0 and 1.0) the fractional portion will behave correctly and consistently. Similarly, in a case where the z stepping process begins at positive 6.0 z value, the fractional portion of z will consistently and deterministically roll over as the integer value steps from 6.0 to 0.0. It is possible to take advantage of this behavior because other separately iterated parameters (the barycentric coefficients) determine which pixels are within the two-dimensional x, y projection of the primitive. Rasterizing correct z values is only important within this two-dimensional projection of the primitive in the x,y plane; outside of this region the z stepper need only act as an error term such that the correct z values are generated once the rasterizer steps into the triangle.; The modularity characteristic of the z stepping function allows the integer portion to increment and decrement as necessary, while the raster stage 410 need only keep accurate track of the modular fractional portion of z (e.g., from 0.0 to 1.0). For example, if z is increasing outside the view volume, positive integers can be discarded. Similarly, if z is decreasing outside the view volume, negative integers can be discarded. This allows the raster stage 410 to use fewer bits for the integer portion of z (e.g., outside the 0.0 to 1.0 range). In both cases, some number of integer z bits (e.g., three bits) can be retained as a multi-bit indicator to indicate when the z stepping process is in the positive or negative range outside the view volume. This is necessary since in general the z stepper will not be exactly precise in relation to the other coefficients which precisely determine pixel membership in the two dimensional x,y projection of the triangle (i.e. the barycentric coefficients). In this manner, the z parameter values produced by the z stepping process are clamped to remain substantially within the valid range of the view volume for transitional pixels at the edges of the primitive.);Genova:[0071-0072];[0080-0081]; [0096-0099] At 408, the computing system can construct a splat for each pixel of the subset of pixels at the coordinates of each of the respective pixels. More particularly, each rasterized surface point of the two-dimensional raster can be converted into a splat, centered at the coordinates of the respective pixel, and colored by the corresponding shaded color C that was determined for the pixel. To preserve derivatives for the vertices of the polygons of the three- dimensional mesh, the coordinates at which the splats are constructed (e.g., splat center points, etc.) can be computed by interpolating clip-space vertex positions for the polygon in which a respective pixel is located based at least in part on the coordinates associated with the pixel (e.g., x,y, z, w homogeneous coordinates, barycentric coordinates, etc.). As an example, a h x w x 4 buffer of per-pixel clip-space positions V can be formed for each pixel.”) In addition, the same motivation is used as the rejection for claim 1.
In the same field of endeavor, Crassin teaches inserting, based on a position of the raster, material information into the raster to generate a material parameter of the raster ([0026] At step 120, geometry is rasterized to generate material parameters (e.g., shading properties) for each sample of the one or more samples covered by visible fragments. A sample that is covered by a visible fragment is a visible sample. In one embodiment, the geometry is rasterized in a separate processing pass from the pass during which a depth buffer is generated. The depth buffer may be used to rasterize only the visible fragments to generate material parameters for each visible sample during step 120. In the context of the present description, the material parameters may include one or more of a material albedo, specular coefficient, emissive coefficient, coverage (or sample count), and roughness. In one embodiment, the material parameters are stored in a G-buffer.[0027] At step 130, for each cluster in the plurality of clusters, the material parameters for each sample assigned to the cluster are combined to produce the aggregate. Importantly, the rasterized material parameters are combined as they are generated, so that it is not necessary to store the per-sample rasterized material parameters in a buffer. In one embodiment, additive blending is used to combine each material parameter of the samples assigned to a cluster to generate the aggregate. The cluster definitions constructed at step 110 provide a sample-to-aggregate mapping that is used to identify the samples corresponding to each aggregate. In one embodiment, the number of clusters is less than the number of samples per region or pixel. [0078] In one embodiment, roughness (i.e., the BRDF's glossy exponent term) is not stored directly but instead is injected as additional variance inside the normal vector distributions 625. The benefits of aggregating statistics from all elements contributing to a pixel, as opposed to a select few, is particularly apparent when rendering specular surfaces. By modeling the distribution of normal vectors specular highlight may be accurately represented. In contrast with a conventional deferred shading technique that stores n shading parameters for each pixel, only c shading parameters (i.e., material parameters) are stored for each pixel”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to computing rendering parameters for each of the pixels of the triangle by systematically evaluating each of the pixels of Hutchins, Genova, Hickman and BAO with generating material parameters as seen in Crassin because this modification would combine each material parameter of the samples assigned to a cluster to generate the aggregate ([0027] of Crassin)
Thus, the combination of Hutchins, Genova, Hickman, BAO and Crassin teaches wherein the rendering parameters of a raster comprise a material parameter of the raster and another rendering parameter of the raster, the rasters in the three-dimensional model comprise vertex rasters and non-vertex rasters; and the generating model parameters of the three-dimensional model based on the material information of the triangle primitives comprises: performing rasterization on the three-dimensional model to obtain at least one raster in the three-dimensional model and a barycentric coordinate system of a triangle primitive in the three-dimensional model; inserting, based on a position of the raster and a position of the triangle primitive, material information into the raster to generate a material parameter of the raster, and generating another rendering parameter of a non-vertex raster based on the barycentric coordinate system of the triangle primitive and the another rendering parameter of a vertex raster of the triangle primitive.
Regarding claim 3, Hutchins, Genova, Hickman, BAO and Crassin teach the method according to claim 2, wherein the generating another rendering parameter of a non-vertex raster based on the barycentric coordinate system of the triangle primitive and the another rendering parameter of a vertex raster of the triangle primitive comprises:
determining a variation function of the triangle primitive based on a position relationship of the vertex raster of the triangle primitive in the barycentric coordinate system, the variation function indicating variation rules of the another rendering parameter of different rasters (see at least [0033] of Genova In some implementations, the computing system can generate, based on the two- dimensional differentiable rendering, one or more derivatives for one or more respective splats of the two-dimensional rendering (e.g., at occlusion boundaries, etc.). More particularly, one or more derivatives can, be generated for the weight(s) of one or more splats of the two-dimensional differentiable rendering with regards the vertex positions (e.g., using an automatic differentiation function, etc.). The generation of derivative(s) for splat(s) will be discussed in greater detail with regards to Figure 2. [0035] In some implementations, a loss function can be evaluated that evaluates a difference between the machine-learned output and training data associated with the three- dimensional mesh based at least in part on the one or more derivatives. As an example, using a gradient descent algorithm, the one or more derivatives can be evaluated to determine a difference between the machine-learned output and the training data associated with the three-dimensional mesh (e.g., a ground truth associated with the three-dimensional mesh, etc.). Based on the loss function, one or more parameters of a machine-learned model can be adjusted.”;[0072-0073] “[0071] As an example, a line segment 201 can include a first vertex 202 and a second vertex 206. A splat can be constructed at splat position 204 for a pixel located at pixel position 208. More particularly, barycentric coordinate a 212 and barycentric coordinate /? 210 can be the 1-D barycentric coordinates of splat position s 204 along the line segment 201. As such, splat position 5 204 can be defined as: s = av + /?v2 in which a can represent barycentric coordinate 212, vr can represent vertex 202, v2 can represent vertex 206, and (i can represent barycentric coordinate 210. As described previously, the pixel at pixel position 208 can be updated (e.g., an updated color value, etc.) based at least in part on a weight iv(p) of the splat at splat position 204. More particularly, the weight W(p) can represent the weight of the splat as applied to the pixel at pixel position 208, and can be weighted based at least in part on the difference between the location of the splat position 204 and the pixel position 208. As such, substituting the above for s 204….”); and
performing, based on a position relationship between the non-vertex raster and the vertex raster, parameter conversion on the another rendering parameter of the vertex raster by using the variation function to obtain the another rendering parameter of the non-vertex raster (see at least [0072] of Genova “ After constructing the splat, a derivative can be generated from the splat based at least in part on the coordinates (e.g., 210 and/or 212) of the splat with regards to the line segment and/or the pixel. As the barycentric coordinates a 212 and (i 210 are generally not differentiable and can be considered constant, the derivative of the weight of the splat to the pixel w(p) with regards to v can be defined as:
The exponential term and barycentric coordinate a 212 can be positive, so the sign of the derivative can be determined by the sign of p — avr — (iv2 or p — s. As such, increasing a distance of vertex Figure imgf000021_0002 202 along the line segment 201 in a certain direction will increase the weight W(p) of the splat as applied to the pixel 208. [0073] As an example, if the pixel position 208 is positioned to the right of the splat 204 on the line segment 201 (e.g., p > s, etc.) the weight W(p) of the splat 204 with respect to the pixel at position 208 can increase. Similarly, the weight W(p) of the splat 204 with respect to the pixel can decrease if the pixel position 208 is positioned to the right of the splat 204 on the line segment 201 (e.g., p < s, etc.). A derivative can be generated with respect to v2 in a similar manner. In such fashion, a splat 204 can be constructed for a pixel 208, and can be utilized to generate derivatives based at least in part on the location of the splat.”; [0101] of At 502, a computing system can generate, based on a two-dimensional differentiable rendering, one or more derivatives for one or more respective splats of the two- dimensional rendering (e.g., at occlusion boundaries, etc.). More particularly, one or more derivatives can, be generated for the weight(s) of one or more splats of the two-dimensional differentiable rendering with regards the vertex positions (e.g., using an automatic differentiation function, etc.). The two-dimensional differentiable rendering can be generated as described previously with regards to FIG. 4.) In addition, the same motivation is used as the rejection for claim 2.
Regarding claim 4, Hutchins, Genova, Hickman, BAO and Crassin teach the method according to claim 2, wherein the another rendering parameter comprises at least one of a color parameter, a depth parameter, and a texture parameter (see at least col.14,lines 27-42 of Hutchins “In one embodiment, the raster stage 410 accesses the primitives comprising the polygon 1401 (e.g., triangle) and rasterizes the triangle into its constituent pixels. The bounding box 1411 is used by the rasterizer module (e.g., rasterizer) of the raster stage 410 in the rasterization process of the triangle 1401. Associated parameters for each pixel are then interpolated from the vertices 1411-1413. These parameters include a depth parameter, z. During rasterization of the triangle 1401, respective z values are interpolated by the raster stage 410 for each pixel of the triangle 1401. Each z value is represented within a predefined numerical range (e.g., an integer portion of zero and a fractional portion ranging from zero to one) which substantially corresponds to a depth range between a near clipping plane 1408 and a far clipping plane 1407, as related to a view volume. Z values outside the clipping planes are not screen displayable positions.”; col.15, lines 3-39 “Thus, for example, even though a z stepper of the raster stage 410 may begin at -2.0 z value, by the time the raster stage 410 steps into the view volume (e.g., z values between 0.0 and 1.0) the fractional portion will behave correctly and consistently. Similarly, in a case where the z stepping process begins at positive 6.0 z value, the fractional portion of z will consistently and deterministically roll over as the integer value steps from 6.0 to 0.0. It is possible to take advantage of this behavior because other separately iterated parameters (the barycentric coefficients) determine which pixels are within the two-dimensional x, y projection of the primitive. Rasterizing correct z values is only important within this two-dimensional projection of the primitive in the x,y plane; outside of this region the z stepper need only act as an error term such that the correct z values are generated once the rasterizer steps into the triangle.; The modularity characteristic of the z stepping function allows the integer portion to increment and decrement as necessary, while the raster stage 410 need only keep accurate track of the modular fractional portion of z (e.g., from 0.0 to 1.0). For example, if z is increasing outside the view volume, positive integers can be discarded. Similarly, if z is decreasing outside the view volume, negative integers can be discarded. This allows the raster stage 410 to use fewer bits for the integer portion of z (e.g., outside the 0.0 to 1.0 range). In both cases, some number of integer z bits (e.g., three bits) can be retained as a multi-bit indicator to indicate when the z stepping process is in the positive or negative range outside the view volume. This is necessary since in general the z stepper will not be exactly precise in relation to the other coefficients which precisely determine pixel membership in the two dimensional x,y projection of the triangle (i.e. the barycentric coefficients). In this manner, the z parameter values produced by the z stepping process are clamped to remain substantially within the valid range of the view volume for transitional pixels at the edges of the primitive.);Genova:[0071-0072];[0080-0081]; [0096-0099] At 408, the computing system can construct a splat for each pixel of the subset of pixels at the coordinates of each of the respective pixels. More particularly, each rasterized surface point of the two-dimensional raster can be converted into a splat, centered at the coordinates of the respective pixel, and colored by the corresponding shaded color C that was determined for the pixel. To preserve derivatives for the vertices of the polygons of the three- dimensional mesh, the coordinates at which the splats are constructed (e.g., splat center points, etc.) can be computed by interpolating clip-space vertex positions for the polygon in which a respective pixel is located based at least in part on the coordinates associated with the pixel (e.g., x,y, z, w homogeneous coordinates, barycentric coordinates, etc.). As an example, a h x w x 4 buffer of per-pixel clip-space positions V can be formed for each pixel.”; Hickman: see at least col.9, lines 63-67-col.1, lines 1-11 “…In another example, appearance attributes associated with the portion of the 3D object data model may be modified. For example, the portion of the 3D object data model may include a base color, texture coordinates, and lighting information, among other parameters, which are used by a shader to determine a final pixel color that is rendered or displayed on a screen. Any of the appearance attributes may be modified based on the appearance metric…; [0082] of Crassin “The raster operations stage 480 may perform various operations on the shaded fragment data such as performing alpha tests, Z-test, stencil tests, and blending the shaded fragment data with other pixel data corresponding to other fragments associated with the pixel. When the raster operations stage 480 has finished processing the shaded fragment data to produce pixel data (i.e., the output data 402), the pixel data may be written to a display surface (i.e., render target such as a frame buffer, a color buffer, Z-buffer, or the like). During the third pass, the raster operations stage 480 outputs the shaded fragment data for each cluster to the aggregate G-buffer 475. In one embodiment, the raster operations stage 480 performs additive blending to combine the material parameters for each sample with a cluster. The raster operations stage 480 then outputs the combined material parameters divided by the sample count 620 for the cluster to store as the aggregated material parameters 630 for the cluster. Dividing by the sample count 620 avoids overflow and allows incremental computation of the mean.” ;BAO: [0016] The shading module is used to shading multiple vertices of the initial 3D model to obtain a first 3D model. The colors of multiple vertices of the first 3D model are used to identify multiple rendering parts of the initial 3D model. [0017] The offset module is used to perform texture offset on the colors of the multiple vertices of the first 3D model to obtain a second 3D model with multiple texture maps, which are used to provide multiple display textures for the multiple rendering parts;”) In addition, the same motivation is used as the rejection for claim 2.
Regarding claim 11, Hutchins, Genova, Hickman, BAO teach the computer device according to claim 10, Remaining limitations of claim 11 is similar scope to claim 2 and therefore rejected under the same rational.
Regarding claim 12, Hutchins, Genova, Hickman, BAO and Crassin teach the computer device according to claim 11, Remaining limitations of claim 12 is similar scope to claim 3 and therefore rejected under the same rational.
Regarding claim 13, Hutchins, Genova, Hickman, BAO and Crassin teach the computer device according to claim 11, Remaining limitations of claim 13 is similar scope to claim 4 and therefore rejected under the same rational.
3. Claims 5-6, 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Hutchins, U.S Patent No. 8432394 (Hutchins”) in view of Genova et al,. WO2022046113A1, (“Genova”) further in view of Hickman et al., U.S Patent No.825846 (“Hickman”) further in view of BAO et al, IDS, CN109961498A (English translated) (“BAO”) further in view of Crassin et al., U.S Patent Application Publication No. 20150317827 (“Crassin”) further in view of ZHANG et al., U.S Patent Application Publication No.20220012842 (“Zhang”)
Regarding claim 5, Hutchins, Genova, Hickman, BAO and Crassin teaches the method according to claim 2, wherein the performing rasterization on the three-dimensional model to obtain at least one raster in the three-dimensional model comprises:
acquiring first vertex data of the three-dimensional model, the first vertex data indicating vertex information of the three-dimensional model in a model coordinate system (see at least , col.6, lines 17-34 of Hutchins, “A setup stage 405 receives instructions and graphics primitives from a host, such as a software application running on the CPU 201. In one embodiment, setup stage 405 performs the functions of geometrical transformation of coordinates (X-form), clipping, and setup. The setup unit takes vertex information (e.g., x, y, z, color and/or texture attributes, etc.) from primitives and applies a user defined view transform to calculate screen space coordinates for each geometric primitive (often referred to as triangles because primitives are typically implemented as triangles), which is then sent to the raster stage 410 to draw the given triangle. A vertex buffer 408 may be included to provide a buffer for vertex data used by setup stage 405. In one embodiment, setup stage 405 sets up barycentric coordinate transforms. In one implementation, setup stage 405 is a floating point Very Large Instruction Word (VLIW) machine that supports 32-bit IEEE fl, S15.16 fixed point and packed 0.8 formats.”; [0055] of Crassin “The vertex shading stage 420 processes vertex data by performing a set of operations (i.e., a vertex shader or a program) once for each of the vertices. Vertices may be, e.g., specified as a 4-coordinate vector associated with one or more vertex attributes. The vertex shading stage 420 may manipulate properties such as position, color, texture coordinates, and the like. In other words, the vertex shading stage 420 performs operations on the vertex coordinates or other vertex attributes associated with a vertex. Such operations commonly including lighting operations (i.e., modifying color attributes for a vertex) and transformation operations (i.e., modifying the coordinate space for a vertex). For example, vertices may be specified using coordinates in an object-coordinate space, which are transformed by multiplying the coordinates by a matrix that translates the coordinates from the object-coordinate space into a world space or a normalized-device-coordinate (NCD) space. The vertex shading stage 420 generates transformed vertex data that is transmitted to the tessellation/primitive assembly stage 430.”);
performing first space conversion on the first vertex data to obtain second vertex data, the second vertex data indicating vertex information of the three-dimensional model in a world coordinate system (see at least , col.6, lines 17-34 of Hutchins “A setup stage 405 receives instructions and graphics primitives from a host, such as a software application running on the CPU 201. In one embodiment, setup stage 405 performs the functions of geometrical transformation of coordinates (X-form), clipping, and setup. The setup unit takes vertex information (e.g., x, y, z, color and/or texture attributes, etc.) from primitives and applies a user defined view transform to calculate screen space coordinates for each geometric primitive (often referred to as triangles because primitives are typically implemented as triangles), which is then sent to the raster stage 410 to draw the given triangle. A vertex buffer 408 may be included to provide a buffer for vertex data used by setup stage 405. In one embodiment, setup stage 405 sets up barycentric coordinate transforms. In one implementation, setup stage 405 is a floating point Very Large Instruction Word (VLIW) machine that supports 32-bit IEEE fl, S15.16 fixed point and packed 0.8 formats.”; [0055] of Crassin “The vertex shading stage 420 processes vertex data by performing a set of operations (i.e., a vertex shader or a program) once for each of the vertices. Vertices may be, e.g., specified as a 4-coordinate vector associated with one or more vertex attributes. The vertex shading stage 420 may manipulate properties such as position, color, texture coordinates, and the like. In other words, the vertex shading stage 420 performs operations on the vertex coordinates or other vertex attributes associated with a vertex. Such operations commonly including lighting operations (i.e., modifying color attributes for a vertex) and transformation operations (i.e., modifying the coordinate space for a vertex). For example, vertices may be specified using coordinates in an object-coordinate space, which are transformed by multiplying the coordinates by a matrix that translates the coordinates from the object-coordinate space into a world space or a normalized-device-coordinate (NCD) space. The vertex shading stage 420 generates transformed vertex data that is transmitted to the tessellation/primitive assembly stage 430.”);
determining a contour image of the three-dimensional model in a screen space based on the second vertex data (see at least , col.6, lines 17-34 of Hutchins “A setup stage 405 receives instructions and graphics primitives from a host, such as a software application running on the CPU 201. In one embodiment, setup stage 405 performs the functions of geometrical transformation of coordinates (X-form), clipping, and setup. The setup unit takes vertex information (e.g., x, y, z, color and/or texture attributes, etc.) from primitives and applies a user defined view transform to calculate screen space coordinates for each geometric primitive (often referred to as triangles because primitives are typically implemented as triangles), which is then sent to the raster stage 410 to draw the given triangle. A vertex buffer 408 may be included to provide a buffer for vertex data used by setup stage 405. In one embodiment, setup stage 405 sets up barycentric coordinate transforms. In one implementation, setup stage 405 is a floating point Very Large Instruction Word (VLIW) machine that supports 32-bit IEEE fl, S15.16 fixed point and packed 0.8 formats.”; col.7, lines 38-49 “The raster stage 410 advantageously utilizes an array of programmable interpolators 501-508 to compute the parameters in parallel. As the raster stage 410 walks each pixel, the parameters for that pixel are iterated, and the resulting data is passed down to subsequent stages of the pipeline (e.g., as a pixel packet). The interpolated results can be placed in programmably selectable positions in the pixel packet. As is generally known, complex 3D scenes can typically have a large number of polygons, and additionally, a large number of rendering parameters for each polygon. Such parameters include, for example, color, texture coordinates, transparency, depth, level of detail (LOD), and the like. A real-time 3D rendering pipeline needs to perform many millions of calculations per second to maintain the pixel throughput (e.g., fill rate) required to draw a realistic 60-70 frames per second. The raster stage 410 utilizes the parallel array of interpolators 501-508 to maintain the required pixel fill rate while conserving power consumption and silicon area.”; Genova:[0022] The computing system can rasterize the three-dimensional mesh to obtain a two- dimensional raster of the three-dimensional mesh. The two-dimensional raster can be or otherwise include a plurality of pixels and a plurality of coordinates respectively associated with a subset of the plurality of pixels (e.g., by sampling the surface of the three-dimensional mesh, etc.). These coordinates can describe the locations of pixels relative to the vertices of the polygons in which the pixels are located. As an example, a first coordinate can describe a location of a first pixel relative to the vertices of a first polygon in which the first pixel is located. A second coordinate can describe a location of a second pixel relative to the vertices of a second polygon in which the second pixel is located. In some implementations, each of the plurality of coordinates can be or otherwise include barycentric coordinates.[0024] It should be noted that the computing system can rasterize the three-dimensional mesh to obtain the two-dimensional raster using any type of rasterization scheme. As an example, the two-dimensional raster (e.g., the plurality of coordinates, the polygon identifiers, etc.) may be obtained using a conventional z-buffer graphics processing (e.g., depth buffering, etc.)).; and
performing rasterization on the image to obtain the at least one raster in the three-dimensional model (see at least: Hutchins, col.7, lines 38-49 “The raster stage 410 advantageously utilizes an array of programmable interpolators 501-508 to compute the parameters in parallel. As the raster stage 410 walks each pixel, the parameters for that pixel are iterated, and the resulting data is passed down to subsequent stages of the pipeline (e.g., as a pixel packet). The interpolated results can be placed in programmably selectable positions in the pixel packet. As is generally known, complex 3D scenes can typically have a large number of polygons, and additionally, a large number of rendering parameters for each polygon. Such parameters include, for example, color, texture coordinates, transparency, depth, level of detail (LOD), and the like. A real-time 3D rendering pipeline needs to perform many millions of calculations per second to maintain the pixel throughput (e.g., fill rate) required to draw a realistic 60-70 frames per second. The raster stage 410 utilizes the parallel array of interpolators 501-508 to maintain the required pixel fill rate while conserving power consumption and silicon area.”; Genova:[0022] The computing system can rasterize the three-dimensional mesh to obtain a two- dimensional raster of the three-dimensional mesh. The two-dimensional raster can be or otherwise include a plurality of pixels and a plurality of coordinates respectively associated with a subset of the plurality of pixels (e.g., by sampling the surface of the three-dimensional mesh, etc.). These coordinates can describe the locations of pixels relative to the vertices of the polygons in which the pixels are located. As an example, a first coordinate can describe a location of a first pixel relative to the vertices of a first polygon in which the first pixel is located. A second coordinate can describe a location of a second pixel relative to the vertices of a second polygon in which the second pixel is located. In some implementations, each of the plurality of coordinates can be or otherwise include barycentric coordinates.[0024] It should be noted that the computing system can rasterize the three-dimensional mesh to obtain the two-dimensional raster using any type of rasterization scheme. As an example, the two-dimensional raster (e.g., the plurality of coordinates, the polygon identifiers, etc.) may be obtained using a conventional z-buffer graphics processing (e.g., depth buffering, etc.) [0027] The computing system can construct a splat for each pixel of the subset of pixels at the coordinates of each of the respective pixels. More particularly, each rasterized surface point of the two-dimensional raster can be converted into a splat, centered at the coordinates of the respective pixel, and colored by the corresponding shaded color C that was determined for the pixel. In some implementations, a splat can be constructed as a small area of color with a smooth falloff of color that spreads out from the origin of the splat. As an example, the color of a splat with a bright red center location may smoothly fall off as the distance from the center of the splat grows further (e.g., a gradient from the edge of the splat to the center of the splat, etc.). [0059] of Crassin “The rasterization and depth test stage 460 converts the 3D geometric primitives into 2D fragments. The rasterization and depth test stage 460 may be configured to utilize the vertices of the geometric primitives to setup a set of surface equations from which various attributes can be interpolated. In one embodiment, the surface equations are plane equations in the form Ax+By+C, where x and y are sample locations and A, B, and C are plane equation parameters. In other embodiments, a surface equation specifies a high-order surface such as a patch. The rasterization and depth test stage 460 may also compute a coverage mask for a plurality of pixels that indicates whether one or more screen-space sample locations for the plurality of pixels intersect the geometric primitive.”) In addition, the same motivation is used as the rejection for claim 5.
In the same field of endeavor, Zhang teaches acquiring first vertex data of the three-dimensional model, the first vertex data indicating vertex information of the three-dimensional model in a model coordinate system; performing first space conversion on the first vertex data to obtain second vertex data, the second vertex data indicating vertex information of the three-dimensional model in a world coordinate system ([0120] Local Space: [0121] The local space is a coordinate space in which an object is located, namely, a place at which the object is initially located. For example, a cube is created in modeling software (for example, Blender). An origin of the created cube may be located in (0, 0, 0), even though it is likely that the created cube is finally located in a completely different location in a program. Even, it is likely that (0, 0, 0) is used as initial locations for all created models (however, the created models finally appear in different locations in the world). Therefore, all vertices of the created model are in the local space: the vertices are local to the object.[0122] World Space: [0123] If all objects are imported into a program, all the objects may be centralized on an origin (0, 0, 0) of a world. This is not desired. One location needs to be defined for each object, so that the objects can be placed in a larger world. As the name suggests, coordinates in the world space are coordinates of a vertex relative to the (game) world. If the objects need to be scattered in the world (especially in a very real form), the world space is a space to which the objects need to be transformed. Coordinates of the objects are to be transformed from the local to the world space. The transformation is implemented by using a model matrix (Model Matrix).[0124] The model matrix is a transformation matrix that can displace, scale, or rotate an object to place the object in a location or an orientation in which the object originally should be. For example, if a house needs to be transformed, the house first needs to be scaled down (the house is too large in the local space) and displaced to a small town in the suburbs, and then left rotated a little bit on a y axis to match a nearby house”);
determining a contour image in a screen space based on the second vertex data and performing rasterization on the contour image to obtain the at least one raster ([0117] In the coordinate transformation process, the local coordinates are coordinates of an object relative to a local origin, and are also start coordinates of the object. Next, the local coordinates are transformed into the world space coordinates. The world space coordinates fall within a larger space range. These coordinates are relative to a global origin of a world, and are placed together with those of another object relative to the origin of the world. Then, the world coordinates are transformed into the view space coordinates, so that each coordinate is viewed from an angle of a camera or a viewer. When reaching the view space, the vertex coordinates need to be projected into the clip coordinates. The clip coordinates are processed into coordinates within a range from −1.0 to 1.0, and vertices that are to appear on a screen are determined. Finally, the clip coordinates are transformed into the screen coordinates. Next, a process referred to as viewport transform (Viewport Transform) is used. The viewport transform transforms the coordinates within the range from −1.0 to 1.0 to a coordinate range defined by a glViewport function. The finally transformed coordinates are sent to a rasterizer to convert the coordinates into segments (after the coordinates are converted into the segments, a video image can be displayed based on the segments).” where vertices that are to appear on a screen are determined which it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to recognize vertices that are to appear on a screen are determined of Zhang as including determine contour image of the three-dimensional model because this modification would achieve the expected benefits of allowing for analysis of shape ; [0125] View Space:[0126] The view space is often referred to as a camera (sometimes referred to as a camera space (Camera Space) or an eye Space (Eye Space)) of a cross-platform graphics application programming interface (open graphics library, OPENGL). The view space is a result generated by converting world space coordinates into coordinates in front of a field of view of a user. Therefore, the view space is a space viewed from a field of view of a camera. In this case, a panning/rotation scenario is usually completed by using a series of displacement and rotation combinations, to enable a specific object to be transformed to the front of the camera. These combined transformations are usually stored in a view matrix (View Matrix) used to transform the world coordinates to the view space. [0127] Clip Space: [0128] At the end of running of a vertex shader, an OPENGL expects that all coordinates can fall within a specific range, and any point outside this range should be clipped (Clipped). Clipped coordinates are ignored, and therefore remaining coordinates become visible segments on a screen. This is the name origin of the clip space (Clip Space). [0129] Because it is not very intuitive that all visible coordinates are specified to fall within a range from −1.0 to 1.0, coordinate sets (Coordinate Set) may be specified and transformed back to a standardized device coordinate system, as expected by the OPENGL.[0130] To transform vertex coordinates from the view to the clip space, a projection matrix (Projection Matrix) needs to be defined. The projection matrix specifies a range of coordinates, for example, −1000 to 1000, on each dimension. Then, the projection matrix transforms coordinates in this specified range to a standardized device coordinate range (−1.0, 1.0). All coordinates outside the range are not mapped to the range from −1.0 to 1.0, and therefore are clipped. Within the range specified by the projection matrix, coordinates (1250, 500, 750) are invisible because an x coordinate in the coordinates falls outside the range and is converted into a standardized device coordinate greater than 1.0 and therefore the coordinates are clipped.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to computing rendering parameters for each of the pixels of the triangle by systematically evaluating each of the pixels of Hutchins, Genova, Hickman, BAO and Crassin with projecting the vertex coordinates into the clip coordinates as seen in Zhang because this modification would determine vertices that are to appear on a screen ([0117] of Zhang)
Thus, the combination of Hutchins, Genova, Hickman, BAO, Crassin and Zhang teaches wherein the performing rasterization on the three-dimensional model to obtain at least one raster in the three-dimensional model comprises: acquiring first vertex data of the three-dimensional model, the first vertex data indicating vertex information of the three-dimensional model in a model coordinate system; performing first space conversion on the first vertex data to obtain second vertex data, the second vertex data indicating vertex information of the three-dimensional model in a world coordinate system; determining a contour image of the three-dimensional model in a screen space based on the second vertex data; and performing rasterization on the contour image to obtain the at least one raster in the three-dimensional model.
Regarding claim 6, Hutchins, Genova, Hickman, BAO, Crassin and Zhang the method according to claim 5, wherein the determining a contour image of the three-dimensional model in a screen space based on the second vertex data comprises:
performing second space conversion on the second vertex data to obtain third vertex data, the third vertex data indicating vertex information of the three-dimensional model in a clip coordinate system (see at least: [0022]. [0080] of Genova “The computing system can rasterize the three-dimensional mesh to obtain a two- dimensional raster of the three-dimensional mesh. The two-dimensional raster can be or otherwise include a plurality of pixels and a plurality of coordinates respectively associated with a subset of the plurality of pixels (e.g., by sampling the surface of the three-dimensional mesh, etc.). These coordinates can describe the locations of pixels relative to the vertices of the polygons in which the pixels are located. As an example, a first coordinate can describe a location of a first pixel relative to the vertices of a first polygon in which the first pixel is located. A second coordinate can describe a location of a second pixel relative to the vertices of a second polygon in which the second pixel is located. In some implementations, each of the plurality of coordinates can be or otherwise include barycentric coordinates. [0058] of Crassin “The viewport stage 450 performs a viewport transform, culling, and clipping of the geometric primitives. Each surface being rendered to is associated with an abstract camera position. The camera position represents a location of a viewer looking at the scene and defines a viewing frustum that encloses the objects of the scene. The viewing frustum may include a viewing plane, a rear plane, and four clipping planes. Any geometric primitive entirely outside of the viewing frustum may be culled (i.e., discarded) because the geometric primitive will not contribute to the final rendered scene. Any geometric primitive that is partially inside the viewing frustum and partially outside the viewing frustum may be clipped (i.e., transformed into a new geometric primitive that is enclosed within the viewing frustum. Furthermore, geometric primitives may each be scaled based on depth of the viewing frustum. All potentially visible geometric primitives are then transmitted to the rasterization and depth test stage 460.”; Zhang :[0125] View Space: [0126] The view space is often referred to as a camera (sometimes referred to as a camera space (Camera Space) or an eye Space (Eye Space)) of a cross-platform graphics application programming interface (open graphics library, OPENGL). The view space is a result generated by converting world space coordinates into coordinates in front of a field of view of a user. Therefore, the view space is a space viewed from a field of view of a camera. In this case, a panning/rotation scenario is usually completed by using a series of displacement and rotation combinations, to enable a specific object to be transformed to the front of the camera. These combined transformations are usually stored in a view matrix (View Matrix) used to transform the world coordinates to the view space.[0127] Clip Space:[0128] At the end of running of a vertex shader, an OPENGL expects that all coordinates can fall within a specific range, and any point outside this range should be clipped (Clipped). Clipped coordinates are ignored, and therefore remaining coordinates become visible segments on a screen. This is the name origin of the clip space (Clip Space). [0129] Because it is not very intuitive that all visible coordinates are specified to fall within a range from −1.0 to 1.0, coordinate sets (Coordinate Set) may be specified and transformed back to a standardized device coordinate system, as expected by the OPENGL. [0130] To transform vertex coordinates from the view to the clip space, a projection matrix (Projection Matrix) needs to be defined. The projection matrix specifies a range of coordinates, for example, −1000 to 1000, on each dimension. Then, the projection matrix transforms coordinates in this specified range to a standardized device coordinate range (−1.0, 1.0). All coordinates outside the range are not mapped to the range from −1.0 to 1.0, and therefore are clipped. Within the range specified by the projection matrix, coordinates (1250, 500, 750) are invisible because an x coordinate in the coordinates falls outside the range and is converted into a standardized device coordinate greater than 1.0 and therefore the coordinates are clipped. [0131] For example, if only a part of a primitive (Primitive) such as a triangle exceeds a clipping volume (Clipping Volume), the OpenGL reconstructs the triangle as one or more triangles to enable the triangle to fit into the clipping range. [0132-0134] An orthographic projection matrix defines a cube-like frustum. The frustum defines a clip space. All vertices outside this space are clipped. To create an orthographic projection matrix, a width, a height, and a length of a visible frustum need to be specified. After coordinates are transformed to the clip space by using the orthographic projection matrix, all coordinates in this frustum are not clipped. The frustum of the orthographic projection matrix looks like a container:).
removing depth information from the third vertex data to obtain fourth vertex data, the fourth vertex data indicating vertex information of the three-dimensional model in a screen coordinate system ( col.1, lines 43-67-col.2,lines 1-5 of Hutchins “The rendering process involves a number of steps, such as, for example, setting up a polygon model that contains the information which is subsequently required by shading/texturing processes, applying linear transformations to the polygon mesh model, culling back facing polygons, clipping the polygons against a view volume, scan converting/rasterizing the polygons to a pixel coordinate set, and shading/lighting the individual pixels using interpolated or incremental shading techniques. Prior art FIG. 1 shows a diagram depicting the various stages of a traditional prior art pipeline 100. The pipeline 100 is a conventional "deep" pipeline having stages dedicated to performing specific functions. A transform stage 105 performs geometrical calculations of primitives and may also perform a clipping operation. A setup/raster stage 110 rasterizes the primitives. A texture address 115 and texture fetch 120 stage are utilized for texture mapping. A fog stage 130 implements a fog algorithm. An alpha test stage 135 performs an alpha test. A depth test 140 performs a depth test for culling occluded pixels. An alpha blend stage 145 performs an alpha blend color combination algorithm. A memory write stage 150 writes the output of the pipeline.” [0058] of Crassin “The viewport stage 450 performs a viewport transform, culling, and clipping of the geometric primitives. Each surface being rendered to is associated with an abstract camera position. The camera position represents a location of a viewer looking at the scene and defines a viewing frustum that encloses the objects of the scene. The viewing frustum may include a viewing plane, a rear plane, and four clipping planes. Any geometric primitive entirely outside of the viewing frustum may be culled (i.e., discarded) because the geometric primitive will not contribute to the final rendered scene. Any geometric primitive that is partially inside the viewing frustum and partially outside the viewing frustum may be clipped (i.e., transformed into a new geometric primitive that is enclosed within the viewing frustum. Furthermore, geometric primitives may each be scaled based on depth of the viewing frustum. All potentially visible geometric primitives are then transmitted to the rasterization and depth test stage 460.”; Zhang:[0130] To transform vertex coordinates from the view to the clip space, a projection matrix (Projection Matrix) needs to be defined. The projection matrix specifies a range of coordinates, for example, −1000 to 1000, on each dimension. Then, the projection matrix transforms coordinates in this specified range to a standardized device coordinate range (−1.0, 1.0). All coordinates outside the range are not mapped to the range from −1.0 to 1.0, and therefore are clipped. Within the range specified by the projection matrix, coordinates (1250, 500, 750) are invisible because an x coordinate in the coordinates falls outside the range and is converted into a standardized device coordinate greater than 1.0 and therefore the coordinates are clipped. [0155] The to-be-processed vertex data may be all vertex data or some vertex data required for one time of graphics drawing. In addition to vertex data within a field of view of a user, the to-be-processed vertex data may further include vertex data outside the field of view of the user. Processing, by the CPU, the to-be-processed vertex data to obtain the vertex data within the field of view of the user is equivalent to removing the vertex data outside the field of view of the user from the to-be-processed vertex data to obtain the vertex data within the field of view of the user.”); and
determining the contour image of the three-dimensional model in the screen space based on the fourth vertex data (see at least , col.6, lines 17-34 of Hutchins “A setup stage 405 receives instructions and graphics primitives from a host, such as a software application running on the CPU 201. In one embodiment, setup stage 405 performs the functions of geometrical transformation of coordinates (X-form), clipping, and setup. The setup unit takes vertex information (e.g., x, y, z, color and/or texture attributes, etc.) from primitives and applies a user defined view transform to calculate screen space coordinates for each geometric primitive (often referred to as triangles because primitives are typically implemented as triangles), which is then sent to the raster stage 410 to draw the given triangle. A vertex buffer 408 may be included to provide a buffer for vertex data used by setup stage 405. In one embodiment, setup stage 405 sets up barycentric coordinate transforms. In one implementation, setup stage 405 is a floating point Very Large Instruction Word (VLIW) machine that supports 32-bit IEEE fl, S15.16 fixed point and packed 0.8 formats.”; col.7, lines 38-49 “The raster stage 410 advantageously utilizes an array of programmable interpolators 501-508 to compute the parameters in parallel. As the raster stage 410 walks each pixel, the parameters for that pixel are iterated, and the resulting data is passed down to subsequent stages of the pipeline (e.g., as a pixel packet). The interpolated results can be placed in programmably selectable positions in the pixel packet. As is generally known, complex 3D scenes can typically have a large number of polygons, and additionally, a large number of rendering parameters for each polygon. Such parameters include, for example, color, texture coordinates, transparency, depth, level of detail (LOD), and the like. A real-time 3D rendering pipeline needs to perform many millions of calculations per second to maintain the pixel throughput (e.g., fill rate) required to draw a realistic 60-70 frames per second. The raster stage 410 utilizes the parallel array of interpolators 501-508 to maintain the required pixel fill rate while conserving power consumption and silicon area.” ;[0028] of Genova “To preserve derivatives for the vertices of the polygons of the three-dimensional mesh, the coordinates at which the splats are constructed (e.g., splat center points, etc.) can be computed by interpolating clip-space vertex positions for the polygon in which a respective pixel is located based at least in part on the coordinates associated with the pixel (e.g., x, y, z, w homogeneous coordinates, barycentric coordinates, etc.). As an example, a h x w x 4 buffer of per-pixel clip-space positions V can be formed for each pixel. Perspective division and a viewport transformation can be applied to the buffer to produce a h x w x 2 screen-space splat position buffer S. [0058] of Crassin “The viewport stage 450 performs a viewport transform, culling, and clipping of the geometric primitives. Each surface being rendered to is associated with an abstract camera position. The camera position represents a location of a viewer looking at the scene and defines a viewing frustum that encloses the objects of the scene. The viewing frustum may include a viewing plane, a rear plane, and four clipping planes. Any geometric primitive entirely outside of the viewing frustum may be culled (i.e., discarded) because the geometric primitive will not contribute to the final rendered scene. Any geometric primitive that is partially inside the viewing frustum and partially outside the viewing frustum may be clipped (i.e., transformed into a new geometric primitive that is enclosed within the viewing frustum. Furthermore, geometric primitives may each be scaled based on depth of the viewing frustum. All potentially visible geometric primitives are then transmitted to the rasterization and depth test stage 460.” [0117] In the coordinate transformation process, the local coordinates are coordinates of an object relative to a local origin, and are also start coordinates of the object. Next, the local coordinates are transformed into the world space coordinates. The world space coordinates fall within a larger space range. These coordinates are relative to a global origin of a world, and are placed together with those of another object relative to the origin of the world. Then, the world coordinates are transformed into the view space coordinates, so that each coordinate is viewed from an angle of a camera or a viewer. When reaching the view space, the vertex coordinates need to be projected into the clip coordinates. The clip coordinates are processed into coordinates within a range from −1.0 to 1.0, and vertices that are to appear on a screen are determined. Finally, the clip coordinates are transformed into the screen coordinates. Next, a process referred to as viewport transform (Viewport Transform) is used. The viewport transform transforms the coordinates within the range from −1.0 to 1.0 to a coordinate range defined by a glViewport function. The finally transformed coordinates are sent to a rasterizer to convert the coordinates into segments (after the coordinates are converted into the segments, a video image can be displayed based on the segments). where vertices that are to appear on a screen are determined which it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to recognize vertices that are to appear on a screen are determined of Zhang as including determine contour image of the three-dimensional model because this modification would achieve the expected benefits of allowing for analysis of shape) In addition, the same motivation is used as the rejection for claim 5.
Regarding claim 14, Hutchins, Genova, Hickman, BAO and Crassin teach the computer device according to claim 11, Remaining limitations of claim 14 is similar scope to claim 5 and therefore rejected under the same rational.
Regarding claim 15, Hutchins, Genova, Hickman, BAO, Crassin and Zhang teach the computer device according to claim 14, Remaining limitations of claim 15 is similar scope to claim 6 and therefore rejected under the same rational.
4. Claims 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Hutchins, U.S Patent No. 8432394 (Hutchins”) in view of Genova et al,. WO2022046113A1, (“Genova”) further in view of Hickman et al., U.S Patent No.825846 (“Hickman”) further in view of BAO et al, IDS, CN109961498A (English translated) (“BAO”) further in view of Crassin et al., U.S Patent Application Publication No. 20150317827 (“Crassin”) further in view of ZHANG et al., U.S Patent Application Publication No.20220012842 (“Zhang”) further in view of Mammou et al., U.S Patent Application Publication No.20210090301(“Mammou”)
Regarding claim 7, Hutchins, Genova, Hickman, BAO, Crassin and Zhang teach the method according to claim 5, wherein the acquiring first vertex data of the three-dimensional model comprises: acquiring a plurality of sub-models of the three-dimensional model; and combining vertex data of the plurality of sub-models into the first vertex data of the three-dimensional model (see at least Genova [0002] In many industries, three-dimensional polygonal meshes are the predominant shape representation for three-dimensional modeling (e.g., graphics, computer vision, machine-learning, etc.). As such, the capacity to compute accurate derivatives of these meshes with respect to the underlying scene parameters is of increasing interest ; [0019] Generally, the present disclosure is directed to differentiable rendering. More particularly, the present disclosure relates to splat-based forward rendering for three- dimensional meshes that generates smooth derivatives near occlusion boundaries of the mesh. As an example, a three-dimensional mesh can be obtained that includes a plurality of polygons alongside associated texture data and/or shading data. This three-dimensional mesh can be rasterized to generate a two-dimensional raster of the three-dimensional mesh (e.g., represented as a plurality of pixels, etc.); col.8,lines 59-67-col.9, lines 3 of Hickman “In one example, the portion of the 3D object data model may be a component of the 3D object data model having common material properties, such as a common texture map or material shader. For instance, if the 3D object data model is a boot, the portion may be a rubber sole of the boot (or a portion of the rubber sole). A view of solely the portion may be rendered, or a view that includes the portion as well as other portions of the 3D object data model may be rendered. In one instance, a view of 3D object data model in which the portion is visible may be rendered to match an orientation of a product that is represented by the 3D object data model in a 2D image of the product.”’; BAO: [0005] In a scene where a building is being rendered, the building can first be modeled to obtain a 3D model of the building, which has multiple faces. To make different faces of a building present different visual effects, different materials can be set for different faces. By applying different textures to different materials, faces with different textures can present different visual effects.”; [0022] By generating a single material identifier for the initial 3D model of the target image according to the material merging instruction, multiple material identifiers of the initial 3D model are merged into a single material identifier. Multiple vertices of the initial 3D model are then shading to obtain a first 3D model. The colors of these multiple vertices can then be used to identify multiple rendering parts of the initial 3D model. Texture offsetting of these vertex colors results in a second 3D model with multiple texture maps. These texture maps provide multiple display textures for the multiple rendering parts. Based on this material identifier, the drawing interface is called to render the second 3D model, obtaining the target image. This transforms the process from distinguishing different rendering parts by different material identifiers to distinguishing them by multiple vertex colors. Since the entire second 3D model uses a single material identifier, the drawing interface can be called only once for rendering, still resulting in a target image with rich visual effects. This reduces the number of times the drawing interface is called, avoids CPU overload, improves CPU processing efficiency, and ensures the normal operation of the terminal.”) In addition, the same motivation is used as the rejection for claim 5. Hutchins, Genova, Hickman, BAO, Crassin and Zhang are understood to be silent on the remaining limitations of claim 7.
In the same field of endeavor, Mammou teaches acquiring a plurality of sub-models of the three-dimensional model; and combining vertex data of the plurality of sub-models into the first vertex data of the three-dimensional model ([0016] The program instructions of the decoder system when executed further cause the one or more computing devices to determine, based on the patch texture or attribute coordinates and corresponding geometry patches for respective ones of the sub-meshes, locations of vertices of the respective ones of the sub-meshes in three-dimensional space. Also, the program instructions of the decoder system when executed cause the one or more computing devices to reconstruct the three-dimensional mesh by applying the patch connectivity information to the vertices, wherein the boundary stitching information is further used to merge vertices of adjacent sub-meshes that correspond to a same vertex in the reconstructed three-dimensional mesh. Also, the program instructions cause the one or more computing devices to determine texture values or attribute values for the vertices of the respective ones of the sub-meshes based on the texture or attribute patches corresponding to the respective ones of the sub-meshes. Additionally, the program instructions may cause the one or more computing devices to interpolate texture or attribute values for interior points of a polygon of a respective sub-mesh based on texture or attribute values determined for vertices of the polygon.; [0008] The geometry patches indicate for each of a plurality of sub-meshes of the three-dimensional mesh, depth values for vertices of the respective sub-meshes. For example, the three-dimensional mesh may be represented by a plurality of sub-meshes and each sub mesh may be projected onto a patch plane, wherein respective distances of vertices of the sub-mesh from the patch plane are used to determine depth values for the respective vertices of the sub-mesh. Respective X, Y, and Z coordinates of the vertices of the sub-mesh may be determined using the relative location of a pixel corresponding to a vertex in a geometry patch that has been generated based on projection of the sub-mesh onto the patch plane and the depth values of the pixel associated with the vertex. For example, the X and Y locations of pixels in a geometry patch may correspond to respective X and Y locations signaled as texture or attribute coordinates. Alternatively geometry patch images and texture or attribute patch images may be independently packed such that X and Y locations of pixels in a geometry patch do not correspond to texture or attribute coordinates for a corresponding texture or attribute patch.”; [0012] Also, the program instructions, when executed, cause the one or more computing devices to determine patch texture or attribute coordinates for the patches, such as may represent locations of pixels in the image frames that correspond to vertices in a corresponding sub-mesh. Additionally, the program instructions, when executed, cause the one or more computing devices to determine patch connectivity information indicating how the vertices of the geometry patches connected together to form polygons of the respective sub-meshes. Additionally, because vertices of adjacent sub-meshes may represent a same vertex in the full three-dimensional mesh, the program instructions, when executed, cause the one or more computing devices to determine boundary stitching information to be used to join the sub-meshes back into the three-dimensional mesh. [0555] Next, the reconstruction process reconstructs the mesh connectivity C(i) by stitching the patches connectivities PC(i,0), PC(i,1), . . . , PC(i,M−1), by exploiting the boundary stitching information. During this process one or multiple vertices are merged together to generate a single vertex. If a lossy codec is used to encode the geometry frames, artefacts/discontinuities may appear at the patch boundaries. A smoothing process is then applied to filter out such artefacts. A simple smoothing method could comprise associating with each boundary vertex resulting from the merging process the centroid of the merged vertices positions. More sophisticated techniques such as Laplacian smoothing could also be used)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to computing rendering parameters for each of the pixels of the triangle by systematically evaluating each of the pixels of Hutchins, Genova, Hickman, BAO, Crassin and Zhang with determining patch connectivity information indicating how the vertices of the geometry patches connected together as seen in Mammou because this modification would j form polygons of the respective sub-meshes ([0012] of Mammou)
Thus, the combination of Hutchins, Genova, Hickman, BAO, Crassin, Zhang and Mammou teaches wherein the acquiring first vertex data of the three-dimensional model comprises: acquiring a plurality of sub-models of the three-dimensional model; and combining vertex data of the plurality of sub-models into the first vertex data of the three-dimensional model.
Regarding claim 16, Hutchins, Genova, Hickman, BAO, Crassin and Zhang teach the computer device according to claim 14, Remaining limitations of claim 16 is similar scope to claim 7 and therefore rejected under the same rational.
Contact
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SARAH LE whose telephone number is (571)270-7842. The examiner can normally be reached Monday: 8AM-4:30PM EST, Tuesday: 8 AM-3:30PM EST, Wednesday: 8AM-2:30PM EST, Thursday and Friday off.
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, Kent Chang can be reached at (571) 272-7667. 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.
/SARAH LE/Primary Examiner, Art Unit 2614
Prosecution Insights