Patent Description:
When rendering graphics objects in, for example, computer games, the objects are rendered according to models provided by a graphics artist. To promote better performance, memory usage, and flexibility during rendering, the artist may provide a simple model of the object along with a scalar displacement data structure (or "texture") that indicates displacement in the direction of the surface normal for various parts of the object in the simple model to arrive at a final, more complex model of the object. By "scalar" is meant a single value for the displacement, which implicitly means the amount to displace in the direction of the surface normal, as opposed to vector displacement, where the direction and magnitude of the displacement is encoded in a 3D vector.

Prior to displacement, the surface of the simple model is filled in or "tessellated" typically with small triangles, and then displacement is applied to the simple model to arrive at the complex, final model of the object envisioned by the artist.

Some portions ("patches") of objects, are seen from the emulated vantage point (or "camera position") of the graphics while other patches are hidden from view. In particular, in the case of closed objects the patches that are on the side of the mesh facing the camera position will occlude those patches facing away from the camera position. In this context, patches that are seen are referred to as front-facing while patches that are not seen are referred to as back-facing. More generally, the facing of a patch refers to whether or not the normal is in the same direction as the view vector to the camera. Note that a winding order typically is also specified, either clockwise or counter-clockwise, which determines how the cross product is done for determining the side of the normal that counts as front-facing.

Recognizing that tessellating back-facing patches is needless, to save processing time, techniques have been provided for culling back-facing patches from tessellation. Doing so is particularly advantageous when rendering with hardware tessellation, because any patch could potentially generate a significant amount of domain shader work if the tessellation factors are high.

Two techniques to cull back-facing patches before tessellating are a cone of normals and a parametric tangent plane (PTP).

Previously proposed arrangements are disclosed in <NPL>; and in <NPL>. According to the abstract of Loop Charles ET AL, an approach using the Bezier convex hull of the parametric tangent plane is described. According to the abstract of Jon Hasselgren ET AL, an algorithm for automatically computing tight positional and normal bounds on the fly for a base primitive is described.

As understood herein, PTPs typically result in more patch culling than using a cone of normals. The PTP is used to indicate which patches of an object are back-facing (for culling) and which are front-facing (and thus not to be culled from tessellation). The PTP technique is described by <NPL>).

As further understood herein, when displacement is applied to the simple model, back-facing patches in the simple model culled from tessellation by the PTP may in fact contain some front-facing portions after the application of displacement because the bounds of a patch change when it displaced. What this means is that a noticeable gap or hole in the final rendered object may appear owing to what has become over-culling once displacement is applied. Present principles accordingly extend the PTP technique to work with displacement without culling patches that may contain front-facing portions after displacement, which still advantageously providing a higher cull rate compared to other techniques, without a significant run-time cost.

The invention is defined by the independent claims, with various optional features being set out in the dependent claims.

The details of the present application, both as to its structure and operation, can best be understood in reference to the accompanying drawings, in which like reference numerals refer to like parts, and in which:.

This disclosure relates generally to computer ecosystems including aspects of consumer electronics (CE) device networks such as but not limited to distributed computer game networks, video broadcasting, content delivery networks, virtual machines, and machine learning applications.

A system herein may include server and client components, connected over a network such that data may be exchanged between the client and server components. The client components may include one or more computing devices including game consoles such as Sony PlayStation® and related motherboards, portable televisions (e.g. smart TVs, Internet-enabled TVs), portable computers such as laptops and tablet computers, and other mobile devices including smart phones and additional examples discussed below. These client devices may operate with a variety of operating environments. For example, some of the client computers may employ, as examples, Orbis or Linux operating systems, operating systems from Microsoft, or a Unix operating system, or operating systems produced by Apple, Inc. These operating environments may be used to execute one or more browsing programs, such as a browser made by Microsoft or Google or Mozilla or other browser program that can access websites hosted by the Internet servers discussed below. Also, an operating environment according to present principles may be used to execute one or more computer game programs.

Servers and/or gateways may include one or more processors executing instructions that configure the servers to receive and transmit data over a network such as the Internet. Or, a client and server can be connected over a local intranet or a virtual private network. A server or controller may be instantiated by a game console and/or one or more motherboards thereof such as a Sony PlayStation®, a personal computer, etc..

Information may be exchanged over a network between the clients and servers. To this end and for security, servers and/or clients can include firewalls, load balancers, temporary storages, and proxies, and other network infrastructure for reliability and security. One or more servers may form an apparatus that implement methods of providing a secure community such as an online social website to network members.

As used herein, instructions refer to computer-implemented steps for processing information in the system. Instructions can be implemented in software, firmware or hardware and include any type of programmed step undertaken by components of the system.

A processor may be any conventional general-purpose single- or multi-chip processor that can execute logic by means of various lines such as address lines, data lines, and control lines and registers and shift registers.

Software modules described by way of the flow charts and user interfaces herein can include various sub-routines, procedures, etc. Without limiting the disclosure, logic stated to be executed by a particular module can be redistributed to other software modules and/or combined together in a single module and/ or made available in a shareable library.

Present principles described herein can be implemented as hardware, software, firmware, or combinations thereof; hence, illustrative components, blocks, modules, circuits, and steps are set forth in terms of their functionality.

Further to what has been alluded to above, logical blocks, modules, and circuits described below can be implemented or performed with a general-purpose processor, a digital signal processor (DSP), a field programmable gate array (FPGA) or other programmable logic device such as an application specific integrated circuit (ASIC), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A processor can be implemented by a controller or state machine or a combination of computing devices.

The functions and methods described below may be implemented in hardware circuitry or software circuitry. When implemented in software, the functions and methods can be written in an appropriate language such as but not limited to Java, C# or C++, and can be stored on or transmitted through a computer-readable storage medium such as a random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), compact disk read-only memory (CD-ROM) or other optical disk storage such as digital versatile disc (DVD), magnetic disk storage or other magnetic storage devices including removable thumb drives, etc. A connection may establish a computer-readable medium. Such connections can include, as examples, hard-wired cables including fiber optics and coaxial wires and digital subscriber line (DSL) and twisted pair wires. Such connections may include wireless communication connections including infrared and radio.

Components included in one embodiment can be used in other embodiments in any appropriate combination. For example, any of the various components described herein and/or depicted in the Figures may be combined, interchanged or excluded from other embodiments.

"A system having at least one of A, B, and C" (likewise "a system having at least one of A, B, or C" and "a system having at least one of A, B, C") includes systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc..

Now specifically referring to <FIG>, an example system <NUM> is shown, which may include one or more of the example devices mentioned above and described further below in accordance with present principles. The first of the example devices included in the system <NUM> is a consumer electronics (CE) device such as an audio video device (AVD) <NUM> such as but not limited to an Internet-enabled TV with a TV tuner (equivalently, set top box controlling a TV). However, the AVD <NUM> alternatively may be an appliance or household item, e.g. computerized Internet enabled refrigerator, washer, or dryer. The AVD <NUM> alternatively may also be a computerized Internet enabled ("smart") telephone, a tablet computer, a notebook computer, a wearable computerized device such as e.g. computerized Internet-enabled watch, a computerized Internet-enabled bracelet, other computerized Internet-enabled devices, a computerized Internet-enabled music player, computerized Internet-enabled head phones, a computerized Internet-enabled implantable device such as an implantable skin device, etc. Regardless, it is to be understood that the AVD <NUM> is configured to undertake present principles (e.g. communicate with other CE devices to undertake present principles, execute the logic described herein, and perform any other functions and/or operations described herein).

Accordingly, to undertake such principles the AVD <NUM> can be established by some or all of the components shown in <FIG>. For example, the AVD <NUM> can include one or more displays <NUM> that may be implemented by a high definition or ultra-high definition "<NUM>" or higher flat screen and that may be touch-enabled for receiving user input signals via touches on the display. The AVD <NUM> may include one or more speakers <NUM> for outputting audio in accordance with present principles, and at least one additional input device <NUM> such as e.g. an audio receiver/microphone for e.g. entering audible commands to the AVD <NUM> to control the AVD <NUM>. The example AVD <NUM> may also include one or more network interfaces <NUM> for communication over at least one network <NUM> such as the Internet, an WAN, an LAN, etc. under control of one or more processors. Thus, the interface <NUM> may be, without limitation, a Wi-Fi transceiver, which is an example of a wireless computer network interface, such as but not limited to a mesh network transceiver. Furthermore, note the network interface <NUM> may be, e.g., a wired or wireless modem or router, or other appropriate interface such as, e.g., a wireless telephony transceiver, or Wi-Fi transceiver as mentioned above, etc..

It is to be understood that the one or more processors control the AVD <NUM> to undertake present principles, including the other elements of the AVD <NUM> described herein such as e.g. controlling the display <NUM> to present images thereon and receiving input therefrom. The one or more processors may include a central processing unit (CPU) <NUM> as well as a graphics processing unit (GPU) <NUM> on a graphics card 25A. A GPU may be associated with a compute shader implemented in software using, for example, DirectX <NUM> style High Level Shading Language.

In addition to the foregoing, the AVD <NUM> may also include one or more input ports <NUM> such as, e.g., a high definition multimedia interface (HDMI) port or a USB port to physically connect (e.g. using a wired connection) to another CE device and/or a headphone port to connect headphones to the AVD <NUM> for presentation of audio from the AVD <NUM> to a user through the headphones. For example, the input port <NUM> may be connected via wire or wirelessly to a cable or satellite source 26a of audio video content. Thus, the source 26a may be, e.g., a separate or integrated set top box, or a satellite receiver. Or, the source 26a may be a game console or disk player containing content that might be regarded by a user as a favorite for channel assignation purposes described further below. The source 26a when implemented as a game console may include some or all of the components described below in relation to the CE device <NUM> and may implement some or all of the logic described herein.

The AVD <NUM> may further include one or more computer memories <NUM> such as disk-based or solid-state storage that are not transitory signals, in some cases embodied in the chassis of the AVD as standalone devices or as a personal video recording device (PVR) or video disk player either internal or external to the chassis of the AVD for playing back AV programs or as removable memory media. Also in some embodiments, the AVD <NUM> can include a position or location receiver such as but not limited to a cellphone receiver, GPS receiver and/or altimeter <NUM> that is configured to e.g. receive geographic position information from at least one satellite or cellphone tower and provide the information to the processor <NUM> and/or determine an altitude at which the AVD <NUM> is disposed in conjunction with the processor <NUM>. However, it is to be understood that that another suitable position receiver other than a cellphone receiver, GPS receiver and/or altimeter may be used in accordance with present principles to e.g. determine the location of the AVD <NUM> in e.g. all three dimensions.

Continuing the description of the AVD <NUM>, in some embodiments the AVD <NUM> may include one or more cameras <NUM> that may be, e.g., a thermal imaging camera, a digital camera such as a webcam, and/or a camera integrated into the AVD <NUM> and controllable by the processor <NUM> to gather pictures/images and/or video in accordance with present principles. Also included on the AVD <NUM> may be a Bluetooth transceiver <NUM> and other Near Field Communication (NFC) element <NUM> for communication with other devices using Bluetooth and/or NFC technology, respectively. An example NFC element can be a radio frequency identification (RFID) element.

Further still, the AVD <NUM> may include one or more auxiliary sensors <NUM> (e.g., a motion sensor such as an accelerometer, gyroscope, cyclometer, or a magnetic sensor, an infrared (IR) sensor, an optical sensor, a speed and/or cadence sensor, a gesture sensor (e.g. for sensing gesture command), etc.) providing input to the processor <NUM>. The AVD <NUM> may include an over-the-air TV broadcast port <NUM> for receiving OTA TV broadcasts providing input to the processor <NUM>. In addition to the foregoing, it is noted that the AVD <NUM> may also include an infrared (IR) transmitter and/or IR receiver and/or IR transceiver <NUM> such as an IR data association (IRDA) device. A battery (not shown) may be provided for powering the AVD <NUM>.

Still referring to <FIG>, in addition to the AVD <NUM>, the system <NUM> may include one or more other CE device types. In one example, a first CE device <NUM> may be used to control the display via commands sent through the below-described server while a second CE device <NUM> may include similar components as the first CE device <NUM> and hence will not be discussed in detail. In the example shown, only two CE devices <NUM>, <NUM> are shown, it being understood that fewer or greater devices may be used. As alluded to above, the CE device <NUM>/<NUM> and/or the source 26a may be implemented by a game console. Or, one or more of the CE devices <NUM>/<NUM> may be implemented by devices sold under the trademarks Google Chromecast™, Roku®. A CE device may be established by a digital assistant, an example of which is shown and described further below.

In the example shown, to illustrate present principles all three devices <NUM>, <NUM>, <NUM> are assumed to be members of an entertainment network in, e.g., a home, or at least to be present in proximity to each other in a location such as a house. However, for present principles are not limited to a particular location, illustrated by dashed lines <NUM>, unless explicitly claimed otherwise.

The example non-limiting first CE device <NUM> may be established by any one of the above-mentioned devices, for example, a digital assistant, a portable wireless laptop computer or notebook computer or game controller (also referred to as "console"), and accordingly may have one or more of the components described below. The second CE device <NUM> without limitation may be established by a video disk player such as a Blu-ray player, a game console, and the like. The first CE device <NUM> may be a remote control (RC) for, e.g., issuing AV play and pause commands to the AVD <NUM>, or it may be a more sophisticated device such as a tablet computer, a game controller communicating via wired or wireless link with a game console implemented by the second CE device <NUM> and controlling video game presentation on the AVD <NUM>, a personal computer, a wireless telephone, etc..

Accordingly, the first CE device <NUM> may include one or more displays <NUM> that may be touch-enabled for receiving user input signals via touches on the display. The first CE device <NUM> may include one or more speakers <NUM> for outputting audio in accordance with present principles, and at least one additional input device <NUM> such as e.g. an audio receiver/microphone for e.g. entering audible commands to the first CE device <NUM> to control the device <NUM>. The example first CE device <NUM> may also include one or more network interfaces <NUM> for communication over the network <NUM> under control of one or more CE device processors <NUM>. Thus, the interface <NUM> may be, without limitation, a Wi-Fi transceiver, which is an example of a wireless computer network interface, including mesh network interfaces. It is to be understood that the processor <NUM> controls the first CE device <NUM> to undertake present principles, including the other elements of the first CE device <NUM> described herein such as e.g. controlling the display <NUM> to present images thereon and receiving input therefrom. Furthermore, note the network interface <NUM> may be, e.g., a wired or wireless modem or router, or other appropriate interface such as, e.g., a wireless telephony transceiver, or Wi-Fi transceiver as mentioned above, etc..

In addition to the foregoing, the first CE device <NUM> may also include one or more input ports <NUM> such as, e.g., a HDMI port or a USB port to physically connect (e.g. using a wired connection) to another CE device and/or a headphone port to connect headphones to the first CE device <NUM> for presentation of audio from the first CE device <NUM> to a user through the headphones. The first CE device <NUM> may further include one or more tangible computer readable storage medium <NUM> such as disk-based or solid-state storage. Also in some embodiments, the first CE device <NUM> can include a position or location receiver such as but not limited to a cellphone and/or GPS receiver and/or altimeter <NUM> that is configured to e.g. receive geographic position information from at least one satellite and/or cell tower, using triangulation, and provide the information to the CE device processor <NUM> and/or determine an altitude at which the first CE device <NUM> is disposed in conjunction with the CE device processor <NUM>. However, it is to be understood that that another suitable position receiver other than a cellphone and/or GPS receiver and/or altimeter may be used in accordance with present principles to e.g. determine the location of the first CE device <NUM> in e.g. all three dimensions.

Continuing the description of the first CE device <NUM>, in some embodiments the first CE device <NUM> may include one or more cameras <NUM> that may be, e.g., a thermal imaging camera, a digital camera such as a webcam, and/or a camera integrated into the first CE device <NUM> and controllable by the CE device processor <NUM> to gather pictures/images and/or video in accordance with present principles. Also included on the first CE device <NUM> may be a Bluetooth transceiver <NUM> and other Near Field Communication (NFC) element <NUM> for communication with other devices using Bluetooth and/or NFC technology, respectively. An example NFC element can be a radio frequency identification (RFID) element.

Further still, the first CE device <NUM> may include one or more auxiliary sensors <NUM> (e.g., a motion sensor such as an accelerometer, gyroscope, cyclometer, or a magnetic sensor, an infrared (IR) sensor, an optical sensor, a speed and/or cadence sensor, a gesture sensor (e.g. for sensing gesture command), etc.) providing input to the CE device processor <NUM>. The first CE device <NUM> may include still other sensors such as e.g. one or more climate sensors <NUM> (e.g. barometers, humidity sensors, wind sensors, light sensors, temperature sensors, etc.) and/or one or more biometric sensors <NUM> providing input to the CE device processor <NUM>. In addition to the foregoing, it is noted that in some embodiments the first CE device <NUM> may also include an infrared (IR) transmitter and/or IR receiver and/or IR transceiver <NUM> such as an IR data association (IRDA) device. A battery (not shown) may be provided for powering the first CE device <NUM>. The CE device <NUM> may communicate with the AVD <NUM> through any of the above-described communication modes and related components.

The second CE device <NUM> may include some or all of the components shown for the CE device <NUM>. Either one or both CE devices may be powered by one or more batteries.

Now in reference to the afore-mentioned at least one server <NUM>, it includes at least one server processor <NUM>, at least one tangible computer readable storage medium <NUM> such as disk-based or solid-state storage. In an implementation, the medium <NUM> includes one or more solid state storage drives (SSDs). The server also includes at least one network interface <NUM> that allows for communication with the other devices of <FIG> over the network <NUM>, and indeed may facilitate communication between servers and client devices in accordance with present principles. Note that the network interface <NUM> may be, e.g., a wired or wireless modem or router, Wi-Fi transceiver, or other appropriate interface such as, e.g., a wireless telephony transceiver. The network interface <NUM> may be a remote direct memory access (RDMA) interface that directly connects the medium <NUM> to a network such as a so-called "fabric" without passing through the server processor <NUM>. The network may include an Ethernet network and/or fiber channel network and/or InfiniBand network. Typically, the server <NUM> includes multiple processors in multiple computers referred to as "blades" that may be arranged in a physical server "stack".

Accordingly, in some embodiments the server <NUM> may be an Internet server or an entire "server farm", and may include and perform "cloud" functions such that the devices of the system <NUM> may access a "cloud" environment via the server <NUM> in example embodiments for, e.g., network gaming applications, digital assistant applications, etc. Or, the server <NUM> may be implemented by one or more game consoles or other computers in the same room as the other devices shown in <FIG> or nearby.

Prior to turning to <FIG> et seq. , a "patch" (essentially, a portion of an object model to be rendered) can be classified as back-facing if no part of the patch's parametric tangent plane is front-facing. Thus, a parametric tangent plane (PTP) technique may be used to determine whether a patch is front-facing or back-facing. Rather than directly evaluating the tangent plane, this test can be done efficiently on, e.g., the GPU <NUM> in <FIG> by checking if any coefficient of the tangent plane is front-facing. The coefficients of the parametric tangent plane are calculated by performing a weighted sum of the patch's control points. This technique is described in the paper referenced above and advantageously has a high cull-rate, and can be optimized to be fast.

With the above in mind, refer now to <FIG>, which shows a standard bi-cubic Bezier front-facing patch <NUM> after tessellation (indicated by the triangles <NUM>). The patch <NUM> typically is a patch of a simple model provided by an artist, who also may provide a displacement "texture" that defines how to alter the simple model (typically after tessellation) to produce a complex model of the object for rendering.

In <FIG>, a control cage <NUM> is shown schematically overlaid onto the patch <NUM>. The control cage <NUM> is represented by relatively thick lines <NUM> and influences the shape of the tessellated surface. The intersections <NUM> of control cage lines <NUM> define the control points of the patch <NUM>. In the example shown, sixteen (<NUM>) control points <NUM> are defined. These control points are the input to the parametric tangent plane calculation as more fully described below. In an example non-limiting implementation, the patches are described by subdividing the simple version of a mesh produced by an artist and extracting the patches from the limit surface of the subdivision. The extraction is possible because the limit surface can be interpreted as a set of bi-cubic B-Spline patches, which can be rendered directly or converted to other forms such as Bezier. The control cage may also be defined manually.

For illustration purposes, <FIG> shows the patch <NUM> rotated to be back-facing. Note that the tessellated part is not drawn because the patch was able to be culled by checking the coefficients of the parametric tangent plane, which indicate that the patch is back-facing and hence culled from tessellation.

To facilitate understanding of how present principles extend the PTP culling technique to work with displacement, <FIG> illustrates the patch <NUM> with an example displacement applied to it. In the example shown, the displacement includes a portion <NUM> that extends relatively far outside the bounds of the original control cage <NUM> shown in <FIG>, and thus it cannot be accounted for when doing the parametric tangent plane calculation (since the only input to the calculation is the original control points).

<FIG> illustrates example logic to account for the displacement. Commencing at block <NUM>, the desired displacement map (typically provided by the artist who created the model) can be sampled in a pre-process to determine the extents of displacement per patch. This is to establish tight bounds when culling, because if the displacement is not known per patch then the cull rate may be very poor. Note that positive and negative displacements for each patch are obtained by finding the largest displacement on the patch in the direction of the normal and the largest displacement on the patch in the direction opposite the normal, respectively for creating the new patches to bound the displacement extents.

At run-time, e.g., during rendering of a graphics program such as a computer game by a computer game console such as any of those described herein, each patch to be rendered is loaded at block <NUM> into, e.g., a compute shader prior to drawing. As mentioned previously, the compute shader may be implemented on a graphics card 25A.

At block <NUM>, four normals of the patch are calculated, for example by the compute shader. The four normals are calculated for each of the four corner control points. This is executed by a simple cross product between the corner control point vector and the corner's immediate neighboring control point vectors.

<FIG> illustrates. Assume the original cage <NUM> shown in <FIG> is used, in which sixteen control points are defined. For illustration, <FIG> numbers these control points as shown. The control points numbered <NUM>, <NUM>, <NUM>, and <NUM> are the corner control points. The normal at corner <NUM> is calculated using the cross-products of control points <NUM>, <NUM>, and <NUM>. The normals for points <NUM>, <NUM>, and <NUM> are similarly calculated using, respectively, the cross-products associated with the points <NUM>, <NUM>, <NUM> (for control point <NUM>), <NUM>, <NUM>, <NUM> (for control point <NUM>), and <NUM>, <NUM>, and <NUM> (for control point <NUM>).

Once the control point normals are determined, the logic of <FIG> moves to block <NUM> in which the corner control point normals are used to displace their respective nearest non-corner control points by the displacement extents identified at block <NUM>. The nearest non-corner control points are displaced twice (in both the positive and then negative directions) to create two new patches that form a convex hull around the original patch <NUM>. As stated above, the largest displacement on the patch in the direction of the normal and the largest displacement on the patch in the direction opposite the normal are used at block <NUM>.

Thus, for the corner control point <NUM>, the corner control point <NUM> is left as-is, and points <NUM>, <NUM>, and <NUM> (the nearest neighbor control points to the corner control point <NUM>) are displaced by the extents in the direction of the normal at the corner control point <NUM>. Similarly, the corner control point <NUM> is left as-is, and points <NUM>, <NUM>, and <NUM> (the nearest neighbor control points to the corner control point <NUM>) are displaced by the extents in the direction of the normal at the corner control point <NUM>, the corner control point <NUM> is left as-is, and points <NUM>, <NUM>, and <NUM> (the nearest neighbor control points to the corner control point <NUM>) are displaced by the extents in the direction of the normal at the corner control point <NUM>, and the corner control point <NUM> is left as-is, and points <NUM>, <NUM>, and <NUM> (the nearest neighbor control points to the corner control point <NUM>) are displaced by the extents in the direction of the normal at the corner control point <NUM>.

Thus, the corner control points remain "anchored" as they were prior to displacement, and only the closest interior control points to the respective corner control points are displaced.

<FIG> show the result of displacing the control points in both the positive and negative extents, from two different orientations, to render a cage depiction <NUM> from a first orientation and a cage depiction <NUM> from a second orientation for illustration. Note that the positive extent is the large cage that extends up around the bump. The negative extent is much smaller in the example patch shown but can be seen going slightly below the patch plane in <FIG>. In <FIG> the positive extent is still the side with the large bump because it is positive or negative relative to the surface normal. The negative extent may be more clearly seen in <FIG> which illustrates the patch being displaced opposite the normal slightly. In any case, <FIG> illustrates that when the patch is rotated, it is no longer erroneously culled.

Returning to <FIG>, rather than checking the original cage <NUM> using PTP, culling with displacement can be done by checking against both of the new cages shown in <FIG>. Note that for discussion purposes, "cages" are referred to here to emphasize that the new patches are defined by the control points of the new cages in the diagrams. The patch that is tessellated in those figures is still the original patch. The diagram does not show the tessellation of the new patches because the new patches are only used as an intermediate in calculating the culling and are never actually drawn as a surface.

More specifically, proceeding to decision diamond <NUM>, PTP is implemented on a first displacement to determine whether any coefficient of the PTP of the positive displacement patch indicates front-facing. If no coefficient in checking the positive displacement indicates front-facing, the logic may move to decision diamond <NUM> to determine whether any coefficient of the PTP implemented on the negative displacement patch indicates front-facing. If no coefficient in the negative displacement indicates front-facing, the logic can move to block <NUM> to cull the patch from tessellation. On the other hand, if any coefficient of any control point of either displacement indicates front-facing, the patch is not culled at block <NUM> and thus is tessellated. If all patches of the frame are processed as determined at decision diamond <NUM>, the next frame is processed as indicated at block <NUM>; otherwise, the next patch in the frame is accessed at block <NUM> and the process loops back to block <NUM> to load the next patch.

Thus, the process at run time, in an example, may be executed by a compute shader on a game console such as a PlayStation®. At the start of each frame, each patch is checked for culling. This allows the compute shader to dynamically cull as the camera moves around a scene or a mesh moves within a scene. Only the patches that pass the culling are sent to be drawn at block <NUM>.

The methods herein may be implemented as software instructions executed by a processor, suitably configured application specific integrated circuits (ASIC) or field programmable gate array (FPGA) modules, or any other convenient manner as would be appreciated by those skilled in those art. Where employed, the software instructions may be embodied in a non-transitory device such as a CD ROM or Flash drive. The software code instructions may alternatively be embodied in a transitory arrangement such as a radio or optical signal, or via a download over the internet.

Claim 1:
A device comprising:
at least one compute circuit configured to receive data input and generate output, the circuit being configured to:
receive data from at least one displacement map prior to tessellating graphics object patches with which the displacement map is associated;
for at least a first patch of the graphics object patches:
calculate four normals of the patch, one at each patch corner control point, using a cross product between vectors of the respective corner control point and control points of the patch that are nearest to the respective corner control point;
using each normal, displace the control points of the patch that are nearest the respective corner control point, according to data from the displacement map, to create two new patches, one new patch due to a largest positive displacement on the patch in the direction of the normal and one new patch due to a largest negative displacement on the patch in the direction opposite the normal; wherein the corner control points are not displaced, and control points that are nearest to a respective corner control point are displaced;
determine whether any coefficient of either new patch's parametric tangent plane indicates that the new patch is front-facing;
responsive to determining that either new patch is front-facing, tessellate the first patch; and
responsive to determining that neither new patch is front-facing, not tessellate the first patch.