Systems and methods for compressing objects

Abstract

A method includes obtaining a three-dimensional (3D) object comprising a first plurality of polygons that form a mesh and generating a first set of lighting values associated with the 3D object. The lighting values of the first set of lighting values are associated with one or more simulated lighting conditions used to illuminate the 3D object. One or more polygons to be removed are identified from the mesh. A compressed version of the 3D object is generated by removing the identified one or more polygons from the mesh. The compressed version comprises a second plurality of polygons. A second set of lighting values associated with the initial compressed version of the 3D object is generated. A difference between the first set of lighting values and the second set of lighting values is determined and an output compressed version of the 3D object is generated based upon the determined difference.

Description

SYSTEMS AND METHODS FOR COMPRESSING OBJECTSTECHNICAL FIELD

[0001] The disclosed implementations relate generally to compression tools. More particularly, the disclosed implementations relate to methods, systems, graphical user interfaces, and data structures for compressing three-dimensional (3D) objects.BACKGROUND

[0002] Three-dimensional (3D) modeling refers to the process of developing a mathematical coordinate-based representation of one or more surfaces of an object in three dimensions. The object (model) can be developed using specialized software by manipulating edges, vertices, and polygons in a simulated 3D space. More specifically, 3D objects can represent a physical body using a collection of points in 3D space, connected by various geometric entities such as triangles, lines, curved surfaces, etc. This collection of data can be created manually, algorithmically, or by scanning. The surfaces of 3D object can be further defined with texture mapping.

[0003] Computer animation refers to the process of digitally generating animation. In an illustrative example, objects are built on the computer monitor and 3D models are rigged with a virtual skeleton. The limbs, eyes, mouth, clothes, etc. of the object can be moved by the animator on key frames. The differences in appearance between key frames are automatically calculated by the computer and then the animation is rendered.

[0004] The 3D objects (still or animated) can be used by certain applications, such as video games in virtual reality (VR), applications in augmented reality (AR), avatars in certain programs, etc. to represent the objects to a user. In an example, a sports game played by a user in a virtual reality environment may require the generation of a virtual field, equipment, and players. In some applications, each object (e.g., each player) includes a polygon mesh (e.g., triangular mesh) having a set of vertices, i.e., points in space that form the polygon (e.g., triangle). Such a polygon mesh involves a large quantity of data that can be stored on a data store and transmitted to the user. Practical implementations of storing and transmitting the polygon mesh data representing a virtual object include compressing the polygon mesh data.SUMMARY

[0005] The following presents a simplified summary of various aspects of this disclosure in order to provide a basic understanding of such aspects. This summary is not an extensiveoverview of all contemplated aspects, and is intended to neither identify key or critical elements nor delineate the scope of such aspects. Its purpose is to present some concepts of this disclosure in a simplified form as a prelude to the more detailed description that is presented later.

[0006] An aspect of the disclosure provides a computer-implemented method comprising: obtaining, by a processor, a three-dimensional (3D) object comprising a first plurality of polygons that form a mesh; generating a first set of lighting values associated with the 3D object, wherein lighting values of the first set of lighting values are associated with one or more simulated lighting conditions used to illuminate the 3D object; identifying one or more polygons to be removed from the mesh; generating a compressed version of the 3D object comprising a second plurality of polygons by removing the identified one or more polygons from the mesh; generating a second set of lighting values associated with the compressed version of the 3D object, wherein lighting values of the second set of lighting values are associated with one or more simulated lighting conditions used to illuminate the compressed version of the 3D object; determining a difference between the first set of lighting values and the second set of lighting values; and generating an output compressed version of the 3D object based upon the determined difference.

[0007] Responsive to the difference between the first set of lighting values and the second set of lighting values satisfying a threshold criterion, a new one or more polygons may be identified to remove from the mesh. For example, one or more polygons of the second plurality of polygons may be identified to remove from the mesh. Responsive to a difference between the first set of lighting values and the second set of lighting values failing to satisfy the threshold criterion, the compressed version of the 3D object may be stored. Alternatively, responsive to a difference between the first set of lighting values and the second set of lighting values failing to satisfy the threshold criterion, a further compressed version of the 3D object may be generated different to the compressed version of the 3D object and that comprises a third plurality of polygons different to the second plurality of polygons by removing one or more polygons from the mesh different to the one or more polygons removed from the mesh to generate the first compressed version of the 3D object. The further compressed version of the 3D object may be processed to obtain lighting values and determine a difference in a corresponding manner to the compressed version. Receiving, from a client device, a request for the 3D object; selecting, based on a system resource or a setting parameter of the client device, the compressed version of the 3D object; and sending, to the client device, the compressed version of the 3D object. Each lighting value of the firstset of lighting values may be associated with a particular pixel of an image of the 3D object, a particular vertex of the image of the 3D object, or a particular segment of the image or frame of the 3D object. Generating a first sum reflecting each value of the first set of lighting values; generating a second sum reflecting each value of the second set of lighting values; generating the difference between the first set of lighting values and the second set of lighting values by subtracting the second sum from the first sum. Generating a set of compressed versions of the 3D object, wherein each compressed version of the set of compressed versions comprises a respective mesh; generating a respective set of lighting values associated with each compressed version of the set of compressed versions; determining, a respective difference value between the first set of lighting values and each respective set of lighting values; and selecting, for storage, at least one compressed version of the 3D object based on a relationship of the difference value associated with the at least one compressed version to the difference values associated with the remaining compressed versions of the 3D object. Selecting a camera angle of the 3D object, wherein the lighting values are based on the selected camera angle of the 3D object, wherein the camera angle is selected based on an associated weight value satisfying a threshold criterion.

[0008] A further aspect of the disclosure provides a system comprising: a memory; and a processing device, coupled to the memory, the processing device to perform a method according to any aspect or implementation described herein.

[0009] A further aspect of the disclosure provides a non-transitory computer-readable medium comprising instructions that, responsive to execution by a processing device, cause the processing device to perform operations according to any aspect or implementation described herein.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Aspects and implementations of the present disclosure will be understood more fully from the detailed description given below and from the accompanying drawings of various aspects and implementations of the disclosure, which, however, should not be taken to limit the disclosure to the specific aspects or implementations, but are for explanation and understanding only.

[0011] FIG. 1 illustrates an example of system architecture for generating and providing compressed 3D objects, in accordance with implementations of the disclosure.

[0012] FIG. 2 depicts a computer system in accordance with implementations of the disclosure.

[0013] FIG. 3 depicts a flow diagram of a method showing a process for generating a compressed object, in accordance with implementations of the disclosure.

[0014] FIG. 4 depicts a flow diagram of another method showing a process for generating a compressed object, in accordance with implementations of the disclosure.

[0015] FIG. 5 depicts a flow diagram of a method for performing a selection of an object version for display on a user interface, in accordance with implementations of the disclosure.

[0016] FIG. 6 depicts a flow diagram of a method for requesting, by a client device, an object version for display on a user interface, in accordance with implementations of the disclosure.

[0017] FIG. 7 depicts a block diagram of an example computing device operating in accordance with one or more aspects of the present disclosure.DETAILED DESCRIPTION

[0018] Skeletal rigging is a technique in computer animation in which a 3D object (such as a character, a car, an animal, a door, etc.) is represented in two parts. The first part includes a surface representation used to draw the character (called the polygon mesh or skin) and the second part includes a hierarchical set of interconnected parts called bones. The polygon mesh can include a collection of vertices, edges and faces that defines the shape of a polyhedral object. Specifically, the polygon mesh can include a set of polygons composed to make up the surface of the object. For example, the data representing an object can include a triangular mesh having a set of vertices that form triangles (and possibly other attributes such as normals, color, lighting, or UV coordinates associated with corresponding texture images). The bones collectively form the skeleton or rig, which is a virtual framework used to animate the vertices of the polygons. The animation can be composed of keyframes and in-between frames. The key frames are markers or anchor points that define the start and end points for an action. For example, the keyframes canbe the significant poses in a character's action, such as the first and last positions in a jump. In-between frames include the poses between the keyframes. That is, the in-between frames move the animation from one keyframe to another.

[0019] Other techniques for computer animation include Blendshape animation, morph target animation, etc. Blendshape animation includes making expressive facial animations in the digital production industry. A Blendshape model is represented as a linear weighted sum of the target faces, which exemplify user-defined facial expressions or approximate facial muscle actions. Morph target animation is a method of 3D computer animation used with techniques such as skeletal animation. In a morph target animation, a "deformed" version ofa mesh is stored as a series of vertex positions. In each key frame of an animation, the vertices are then interpolated between these stored positions.

[0020] The 3D objects can be used in certain environments, such as video games, virtual reality, movies (e.g., computer generated imagery), augmented reality, avatars, video conferencing, virtual assistants, maps, computer-generated imagery (CGI), etc. In some systems, the 3D objects (e.g., the rigging and animations) can be created in an external modeling and animation application and then exported to a client device. For certain applications, it is beneficial to provide the object in one or more approximations of varying level of detail (LOD). LOD refers to the complexity (e.g., number of triangles or other polygons) of a 3D object. Typically, an object with a lower LOD requires less data than an object with a higher LOD. In one example, an object having a low LOD (requiring less data) can be used as a placeholder while the actual object is still loading to improve the experience of the user. In another example, a system may not be able to smoothly run the rendered 3D object due to a lack of certain system resources (e.g., inadequate processing power or memory), and require a compressed 3D object. In yet another example, a low LOD object is displayed while the object is in the distance, and an object with a higher LOD can be loaded once needed (e.g., as the distance between the user and the object decreases to a certain interval). LOD can be decreased as the object moves away from the user or according to other metrics such as object importance, viewpoint-relative speed or position, etc. LOD techniques increase the efficiency of rendering by decreasing the workload on graphics pipeline stages, such as vertex transformations.

[0021] Systems can use data compression methods to decrease the LOD of a 3D object. Data compression is a process of encoding information using fewer bits than the original representation. Typically, data compression can be either lossy or lossless. Lossless compression reduces bits by identifying and eliminating statistical redundancy. No information is lost in lossless compression. Lossy compression (or irreversible compression) reduces bits by removing unnecessary or less important information. A device that performs data compression can be referred to as an encoder, and one that performs the reversal of the process (decompression) can be referred to as a decoder.

[0022] In some instances, 3D objects can be illuminated using simulated lighting, thus providing areas of high and low visible detail based on the lighting conditions. 3D lighting is an important element in the visual representation of a 3D object and can refer to a collection of tools and techniques used to simulate light in a computer-generated 3D environment. For example, one or more simulated light sources can be used to draw attention to a particularpart of a 3D object or of a related setting, set the mood of a scene involving the 3D object, represent natural properties of the scene (e.g., the time of day), etc. Rendering engines can produce 3D lighting using algorithms such as Skydome Lighting (e.g., algorithms used to simulate light from a dome above the scene that typically represents the sky), Global Illumination (e.g., algorithms used to calculate light traveling throughout an entire scene, such as direct illumination and indirect (reflected) illumination), and others. These algorithms can use different types of simulated light sources, such as directional light (a light source that strikes the polygons in a scene with equal intensity), point light (a light source that emits light from a single small point, in all directions), area light (a light source that emits light from a specified surface with a specific shape and size), spotlight (a light source that produces a cone of light in a single direction), etc.

[0023] Based on the lighting environment, a computer program referred to as a shader can calculate the appropriate levels of light, darkness, and color during the rendering of a 3D scene. This process is known as shading. Shaders can use different methods to shade an image or frame of a 3D object, such as by generating a lighting value (e.g., a High Dynamic Range image (HDRI) pixel value or other lighting values) for each pixel of the image (e.g., screenshot) or frame of the 3D object, for each vertex of the image or frame of the 3D object, for each segment of the image or frame of the 3D object, and so forth,

[0024] Current systems do not account for lighting conditions when compressing 3D objects since these systems typically perform a uniform compression (e.g., reduce 100 triangle meshes into 50 triangular meshes by combining neighboring vertices throughout the entire object). This can cause the reduced visual quality caused by the compression of the object to be noticeably deformed, stiff or irregular due to the compression of areas having a greater visible level of detail from the lighting conditions. For example, a standing character can be displayed on a stage with an overhead spotlight illuminating the character from above, thus having their head, shoulders and chest in a high lighting condition, while having their waist and legs in a low lighting condition. The high lighting condition can show a greater amount of detail than the low lighting condition. As such, compressing the areas under the high lighting condition can negatively impact the quality of the resulting 3D object and can be detrimental and unpleasant to the user experience.

[0025] Aspects and implementations of the present disclosure address the above and other deficiencies by providing a mechanism for compressing 3D objects such that the detail of object sections under a high lighting condition do not experience significant deformations. In an illustrative example, a compression server can encode one or more compressed versionsof an object, each compressed version having a different LOD. To generate the compressed versions, the compression server can render the 3D object, from the viewpoint of the particular camera position, with the related lighting conditions. The compression server can then generate a screenshot of the rendered 3D object and determine the total lighting magnitude of the screenshot. The total lighting magnitude can be a sum of each lighting value in the screenshot. For example, the total lighting magnitude can be the sum of each lighting value of each pixel in the screenshot, the sum of each lighting vertex in the screenshot, etc.

[0026] The compression server can then select a vertex for removal from the object mesh. In one implementation, the vertex can be selected randomly, via a predetermined order, etc. In other implementations, the vertex can be selected based on areas of high and low lighting values. For example, the compression server can prioritize, for compression, the areas (e.g., pixels, vertices, segments, etc.) having low lighting values (e.g., lighting values below a certain threshold value, lighting value at a particular location in a sorted list, etc.). Responsive to selecting the vertex, the compression server can perform a quality reduction operation to remove the vertex and generate a lower LOD object. The compression server can then generate a screenshot of the lower LOD object from the same viewpoint as the original snapshot and determine the total lighting magnitude of the lower LOD screenshot. The compression server can then determine the difference in the total lighting magnitude values of the two screenshots.

[0027] In some implementations, the lighting difference value can be compared to a threshold criterion (e.g., a threshold value). Responsive to the lighting difference value failing to satisfy the threshold criterion (e.g., the lighting difference value being higher than a threshold value), the compression server can reject the removal of the identified vertex and select another vertex for removal. This above process can then be repeated until a suitable vertex (e.g., a vertex whose corresponding lighting difference values satisfies a threshold criterion) is found. Responsive to the lighting difference value satisfying the threshold criterion (e.g., the lighting difference value being lower than a threshold value), the compression server can accept the removal of the identified vertex. The compression server can then determine whether the lower LOD mesh reflects the target LOD. For example, an original object can include a mesh having 100 triangles, and a target mesh can include 50 triangles. Removal of the first identified vertex can result in a mesh having 95 triangles. Thus, the compression server can select another vertex and perform the above discussed process until an object having a mesh of 50 triangles (or less) is generated. Using the above process, the compression server can reduce triangles (or any other polygons) in areas of theobject that experience small amounts of differences in visible object quality, while maintaining triangles in areas of the object that experience large amounts of differences in visible object quality.

[0028] In some implementations, multiple lower LOD objects can be generated, each of the lower LOD object having one or more different vertices removed. For each of the lower LOD objects, a respective screenshot can be generated along with a respective total lighting magnitude. The difference between the total lighting magnitude of the original screenshot and the total lighting magnitude of each of the lower LOD object can be determined and sorted. The compression server can then select the lower LOD object with the lowest difference, which represents an LOD object with the lowest reduction in visible quality.

[0029] Aspects of the present disclosure result in improved performance of mesh compression tools. In particular, the aspects of the present disclosure enable mesh compression tools to compress mesh data with improved lighting information provided by the compressed mesh data. The mesh compression tools integrate lighting data in selecting mesh elements for removal from an object mesh. As a result, the reduced visual quality caused by the compression of the object can be noticeably improved and the loss of perceptible lighting information can be reduced when the object is obtained from the compressed mesh data. This can improve object aesthetics and user experience. Furthermore, the aspects of the present disclosure cause the client device to no longer experience performance issues related to rendering an object that consumes significant computing resources and causes the client device to experience substandard performance.

[0030] FIG. 1 is an example of a system architecture 100 for generating and providing compressed 3D objects to client devices, in accordance with implementations of the disclosure. The system architecture 100 includes a cloud-based environment 101 connected to client devices 130A-130N (generally referred to as “client device(s) 130” herein) via a network 150. Although the system architecture 100 is described in the context of a cloudbased environment 101, which can enable communication between one or more application servers 110 and / or one or more compression servers 120 in the cloud-based environment 101 and with client devices 130A-130N over the network 150 to store and share data, it can be understood that the implementations described herein can also apply to systems that are locally interconnected. In some implementations, the cloud-based environment 101 refers to a collection of physical machines that host applications (e.g., a gaming application, virtual reality application, a video conferencing application, a virtual assistant application, a graphics application, a CGI application, webpage application, etc.) providing one or more services(e.g., gaming, virtual reality, augmented reality, animation of objects such as avatars, etc.) to multiple client devices 130A-130N via the network 150. While the above list is used by way of example, it should be understood to those skilled in the art that the systems, methods, functions, and implementations of the present disclosure can apply to any type of programs or services offered by any type of host applications.

[0031] The network 150 can be a public network (e.g., the Internet), a private network (e.g., a local area network (LAN) or wide area network (WAN)), or a combination thereof. Network 150 can include a wireless infrastructure, which can be provided by one or more wireless communications systems, such as a wireless fidelity (Wi-Fi) hotspot connected with the network 150 or a wireless carrier system that can be implemented using various data processing equipment, communication towers, etc. Additionally or alternatively, network 130 can include a wired infrastructure (e.g., Ethernet).

[0032] The cloud-based environment 101 can include one or more application servers 110, one or more compression servers 120 and a data store 140. Data store 140 can be a persistent storage that is capable of storing objects (e.g., object 142A-142N), respective compressed objects (e.g., compressed object 144AA-144AZ and 144NA-144NZ), animation packages (e.g., animation package 146A-146N), and lighting data 148A-148N. Data store 140 may be hosted by one or more storage devices, such as main memory, magnetic or optical storage-based disks, tapes or hard drives, NAS, SAN, and so forth. In some implementations, data store 140 may be a network-attached file server, while in other implementations data store 140 may be some other type of persistent storage such as an object-oriented database, a relational database, and so forth, that may be hosted by cloudbased environment 101 or one or more different machines coupled to cloud-based environment 101. In some implementations, data store 140 may be coupled to application server 110, compression server 120, and / or client device 130A-130N via network 150.

[0033] In some implementations, application server 110 can host an application 112 that provides a user interface 132A-132N for presentation on the client devices 130A-130N. The user interface 132A-132N maybe presented via a web browser (not shown). Alternatively, the client device 130A-130N includes a local (mobile or desktop) application (not shown) that provides user interface 132A-132N and communicates with the application 112 via network 130.

[0034] Application 112 can provide one or more 3D objects for display in user interface 132A-132N. For each object, an original version of the object (e.g., object 142A-142N) can be stored on data store 140 in association with one or more corresponding compressedversions (e.g., compressed object 144AA-144AZ, compressed object 144NA-144NZ) of the original object. Object 142A-142N can be a representation of a respective object with the original LOD (e.g., typically, the highest available LOD). For example, object 142A-142N can be the uncompressed version of the respective object. In some implementations, each object 142A-142N can be uploaded to data store 140 or to compression server 120 by a user (not shown), such as a content creator.

[0035] Each compressed object 144AA-144AZ, 144NA-144NZ can represent the corresponding object in one or more LOD versions. In some implementations, each compressed object 144AA-144AZ, 144NA-144NZ can be generated by compression server 120. Details regarding the methods of compressions will be discussed below. In some implementations, each corresponding compressed object can be of a different LOD version. For example, for object 142A, compressed object 144 AA can be compressed to a first LOD version, compressed object 144AZ can be compressed to a second LOD version, and so forth.

[0036] An animation package (e.g., animation package 146A-146N) can include data that enables animation of one or more objects (e.g., objects 142A-142N, compressed objects 144AA-144AZ, 144NA-144NZ). In some implementations, each animation package can include two or more keyframes (significant poses in the object’s action) and one or more sets of in-between frames (poses between the keyframes).

[0037] Lighting data 148A-148N can include data related to the simulated lighting conditions data, camera angles, and lighting values for one or more 3D objects (e.g., objects 142A-142N, compressed objects 144AA-144AZ, 144NA-144NZ). Simulated lighting conditions data can relate to the type of simulated light sources (e.g., simulated directional light, simulated point light, simulated area light, simulated spotlight, etc.) used to illuminate the 3D object. Camera angle data can include one or more views of the 3D object. For example, the camera angle data can include a view of the 3D object from above, from a side, from an isometric position, etc. Each camera angle can be predetermined (e.g., a default view), user selected (e.g., a user can rotate the 3D object into a position and store the desired view), etc.

[0038] In some implementations, each camera angle can be assigned a weight. The camera angle weight can reflect an expected use of the camera angle by a user. For example, multiple camera views can be generated for a particular 3D object. Typically, the front view of a 3D object and an isometric view of the 3D object are used much more often than other views. As such, a first high weight value can be assigned to the camera view related to the front view of the 3D object, a second high weight value can be assigned to the camera viewrelated to the isometric view of the 3D object, and low weights (or no weights) can be assigned to the remaining views. In some implementations, the camera angle weights can be used to determine which views to select for lighting related compression operations performed by compression server 120, as described in detail below. In some implementations, the camera angle weights can be assigned to the original 3D object by the creator of the object, an editor of the object, a user of the object, etc.

[0039] The lighting values can relate to a value reflecting a level of light, darkness, and / or color for a particular feature of the 3D object during the rendering of a 3D scene. The lighting value can be determined based on the simulated lighting conditions and camera angle data. In some implementations, the lighting data 148A-148N can include a lighting value for each pixel of an image (e.g., screenshot) of the 3D object. In some implementations, the lighting data 148A-148N can include a lighting value for each vertex of the image of the 3D object. In some implementations, the lighting data 148A-148N can include a lighting value for each segment of the image or frame of the 3D object.

[0040] In the illustrative example, application 112 is a gaming application that allows a user to play, via client device 130A, a video game that includes an object representing a character. In another illustrative example, application 112 is an online platform that allows a user to represent themselves using an avatar. The original object (e.g., object 142A) can include the character or avatar having a polygon mesh of 1,000 polygons. The first compressed version of the object (e.g., compressed object 144AA) can include the character or avatar having a polygon mesh of 500 polygons. The second compressed version of the object (e.g., compressed object 144AB, not shown) can include the character or avatar having a polygon mesh of 250 polygons. The third compressed version of the object (e.g., compressed object 144AZ) can include the character or avatar having a polygon mesh of 100 polygons. The application server 110 can select which object (e.g., original or a compressed version) to send for display by user interface 132A-132N based on one or more display criteria, which will be discussed in FIGS. 2 and 4 below.

[0041] Compression server 120 can be configured to compress data associated with a polygon mesh (e.g., a triangular mesh) representing the original object. The compression server 120 includes encoder 122 for compressing original objects into one or more compressed objects 144AA-144AZ, 144NA-144NZ. In particular, compression server 120 can generate one or more compressed versions of the original object such that areas of high illumination (areas with relatively high lighting values) are uncompressed or compressed less than areas of low illumination (areas with relatively low lighting values). Compression server120 will be discussed in detail below in regard to FIG. 2. In some implementations, a 3D computer graphics application can be configured to perform one or more operations of compression server 120. For example, a content creator can run a 3D computer graphics application on a client device that provides tools for performing one or more operations of compression server 120, such as compressing object 142A-N to generate compressed object(s) 144AA-144AZ, 144NA-144NZ.

[0042] In some implementations, a user can initiate a session of application 112 on client device 130A-130N. A session of the application 112 can correspond to one or more objects 142A-142N or compressed objects 144AA-144AZ, 144NA-144NZ being displayed on user interface 132A-132N, and ean include a sequence of communications between a session start event and a session end event. The session start event can be triggered by the initiating of the application 112 (e.g., executing the application, logging into the application, etc.). The session end event can be triggered by the user exiting the application (e.g., closing the application, logging out (e.g., a user logout) from the application, etc.). A user logout can occur automatically (e.g., based on network conditions or lack of user interaction with the application) or in response to a user request. A session can refer to the time between initiation of the application to exiting the application.

[0043] The servers 110, 120 can be physical machines (e.g., server machines, desktop computers, etc.) that each include one or more processing devices communicatively coupled to memory devices and input / output (I / O) devices. The processing devices can include a computer, microprocessor, logic device or other device or processor that is configured with hardware, firmware, and software to carry out some of the implementations described herein. Application servers 110 can host application 112, which can display 3D objects on one or more user interfaces 132A-132N. Application 112 can be implemented as computer instructions that are executable by one or more processing devices on application server 110.

[0044] In some implementations, the user interfaces 132A-132N can be web pages rendered by a web browser and displayed on the client devices 130A-130N in a web browser window. In another implementation, the user interfaces 132A-132N can be provided by a stand-alone application (e.g., a mobile application also referred to as a mobile app) downloaded to the client devices 130A-130N and natively running on the client devices 130A-130N (also referred to as a “native application” or “native client application” herein).

[0045] The client devices 130-13 ON can include one or more processing devices communicatively coupled to memory devices and I / O devices. The client devices 130A-130N can be desktop computers, laptop computers, tablet computers, mobile phones (e.g.,smartphones), or any suitable computing device. The client device 130A-130N can include components, such as an input device and an output device. A user can be authenticated by application server 1 lOusing a username and password (or other identification information) provided by a user via the user interface 132A-132N, such that the same client device 130A- 130N can be used by different users at different times.

[0046] Application server 110 can also enable users using different client devices 130A- 13 ON to simultaneously access application 112 to interact with or view the contents of the application 112. In an example where the application is a hockey game, objects such as hockey players can be presented for display on each user interface 132A-132N whose respective client device 130A-130N initiated a session of the application. Each hockey player can be represented as a particular original or compressed object based on the criterion of the corresponding client device 130A-130N. In an illustrative example where object 142 A is hockey player A, client device 130A can have processing resources that support rendering hockey player A using compressed object 144AA, while client device 13 ON can have processing resources that support rendering hockey player A using compressed object 144AZ. As such, both user interfaces 132A, 132N can display the hockey player using different LOD versions. In another example, an application can generate or render a 3D avatar. The avatar can be represented as a particular original or compressed object based on the criterion of the corresponding client device 130A-130N. The avatar can be in a particular lighting environment based on lighting data 148A-148Nand can perform a set of movements based on a particular animation package 146A-146N.

[0047] Further to the descriptions above, a user may be provided with controls allowing the user to make an election as to both if and when systems, programs, or features described herein may enable collection of user information (e.g., information about a user’s social network, social actions, or activities, profession, a user’s preferences, or a user’s current location), and if the user is sent content or communications from a server. In addition, certain data may be treated in one or more ways before it is stored or used, so that personally identifiable information is removed. For example, a user’s identity may be treated so that no personally identifiable information can be determined for the user, or a user’s geographic location may be generalized where location information is obtained (such as to a city, ZIP code, or state level), so that a particular location of a user cannot be determined. Thus, the user may have control over what information is collected about the user, how that information is used, and what information is provided to the user.

[0048] FIG. 2 is a block diagram illustrating computer system 200, in accordance with implementations of the disclosure. Computer system 200 can include application server 110, compression server 120, and data store 140. Application server 110 can include application 112, which can further include selection manager 240. Compression server 120 can include components such as object manager 210, mesh decimator 220, and encoder 230. Each component can be implemented as hardware (circuitry, dedicated logic, etc.), software (such as is run on a general-purpose computer system or a dedicated machine), or a combination of both. Data store 140 can be used to store original objects, compressed objects, and animation packages.

[0049] The object manager 210 can be configured to obtain and store original objects, lighting data, and / or animation packages. In some implementations, the object manager 210 is configured to receive, from a creator client device over a network connection, one or more objects and, for each object, related lighting data and / or one or more related animation packages. The objects, lighting data, and / or animation packages can be uploaded to object manager 210 by the creator client device, or obtained, by object manager 210, from the creator client device. Object manager 210 can store the obtained objects, lighting data, and animation packages on data store 140.

[0050] Mesh decimator 220 can perform one or more quality reduction operations to reduce the number of polygons of a mesh, thereby reducing the LOD of the corresponding object. The mesh can define the geometry of the surface of an object. The mesh can include vertices, edges connecting the vertices, and polygon faces defined by the edges. The corresponding mesh data can include vertex position data, connectivity data, and edge data. The vertex position data represents the positions of the vertices of the mesh. The positions of the vertices can be represented using a three-dimensional coordinate system, such as, for example, triplets of real numbers where each triplet include the position coordinates of a vertex in three-dimensional space.

[0051] The connectivity data represents the topology and adjacency of the mesh. For example, the connectivity data is used to define a traversal of the mesh. In some implementations, the connectivity data includes triplets of integer indices for each corner of each polygon face of the mesh, each of the triplets including an index identifier of an associated vertex, an index identifier of an opposite corner, and an index identifier of an adjacent comer. The triplets are arranged in an order for traversal of the mesh. Such triplets then provide an ordering of the polygon faces for traversal and an orientation of each polygon face. The positions of the vertices represented by the vertex position data are arranged in anorder defined by the index identifiers included in the connectivity data. In some implementations, the connectivity data takes the form of a doubly connected edge list, in which an opposing comer is interpreted as a half-edge.

[0052] The edge data represents the edges of the mesh as defined by the vertex position data. In some implementations, the edges of the mesh are indexed based on the order of the triplets defined by the vertex position data.

[0053] The mesh decimator220 can perform different quality reduction operations, such as edge collapse operations, vertex removal operations, etc. An edge collapse operation can remove a mesh polygon by consolidating two neighbor faces of a mesh entity into one. In some implementations, the edge collapse operation can include half-edge, mid-edge, or fulledge collapse operations. In some implementations, collapse operations can include a vertex removal operation. In some implementations, other quality reduction operations can be used.

[0054] Encoder 230 can generate one or more compressed objects representative of one or more reduced LOD versions of an original object. Encoder 230 can use one or more schemes to compress the original object such that areas of relatively high illumination (e.g., areas with relatively high lighting values) are subject to few or no quality reduction operations while areas of relatively low or insignificant illumination (e.g., areas with relatively low lighting values) are subject to a higher amount of reduction operations.

[0055] Encoder 230 can determine a total lighting magnitude of a screenshot of a 3D object. The total lighting magnitude can reflect the sum of each (or of a subset) of the lighting values of the screenshot. For example, the total lighting magnitude can be the sum of each lighting value (e.g., such as an HDRI value or the like) of each pixel in the screenshot, the sum of each lighting vertex in the screenshot, the sum of the lighting values in a particular section of the screenshot, etc.

[0056] In some implementations, encoder 230 can determine a lighting difference value between a pair of screenshots. The lighting difference value can reflect the difference between the total lighting magnitude of one screenshot and another screenshot. For example, encoder 230 can determine a total lighting magnitude value of an original object (e.g., an uncompressed object such as object 142A-142N), can determine a total lighting magnitude value of a reduced LOD object from the same viewpoint, and then determine the difference between these total lighting magnitude values. The reduced LOD object can be a version of the original 3D object or a reduced LOD object obtained based upon the original 3D object with one or more mesh elements (e.g., vertices, edges, faces, etc.) removed relative to the original 3D object (or reduced LOD object obtained based upon the original 3D object). Insome implementations, based on the lighting difference value satisfying a threshold criterion, encoder 230 can select the reduced LOD object, perform additional quality reduction operations on the reduced LOD object, or store the reduced LOD object data store 140 as a compressed object (e.g., compressed object 144AA-144AZ, 144NA-144NZ). Alternatively, responsive to encoder 230 determining that the lighting difference value failed to satisfy a threshold criterion (e.g., the lighting difference value being higher than a threshold value), encoder 230 can reject the removal of the mesh element in the reduced LOD object and perform alternative quality reduction operations on the object from which the reduced LOD object is obtained, for example by select an alternative mesh element for removal from the object from which the reducedLOD object is obtained. Mesh decimator 220 can generate a new reduced LOD object based on a new, alternative selected mesh element and encoder 230 can determine a new lighting difference value between the new reduced LOD object and the original object. Encoder 230 can compare the new lighting difference value to the threshold criterion to determine whether to keep or discard the new reduced LOD object. This process can then be repeated until a suitable mesh element is found.

[0057] Responsive to the lighting difference value satisfying the threshold criterion (e.g., the lighting difference value being reduced than a threshold value), encoder 230 can accept the removal of the identified mesh element. Encoder 230 can then determine whether to store the reduced LOD version as a compressed object and / or whether to perform additional quality reduction operations on the reduced LOD object. To determine whether to perform additional quality reduction operations on the reduced LOD object, encoder 230 can determine whether the number of mesh elements in the reduced LOD object satisfies a threshold criterion, such as reached a target quality (e.g., reached a target number of mesh elements, reached a target data size, etc.). Responsive to determining that the reduced LOD object reached the target quality, encoder 230 can store the reduced LOD object as a compressed object. Responsive to determining that the LOD object failed to reach the target quality, encoder 230 can perform additional quality reduction operations on the reduced LOD object.

[0058] In some implementations, encoder 230 can track and sort the lighting difference value for a set of reducedLOD objects. In particular, mesh decimator 220 can generate a set of reduced LOD objects, each having a different (or a combination of different) mesh elements removed. Encoder 230 can generate a total lighting magnitude (from the same viewpoint) for each of these reduced LOD objects. Encoder 230 can then generate a set of lighting difference values (e.g., a respective lighting difference value between the originalobject and each reduced LOD object). Encoder 230 can then sort the total lighting magnitudes in a table (e.g., a data structure). Encoder 230 can use the sorted table to determine which reduced LOD version(s) of the object to discard, and which version(s) to keep (either for further compression orto store in data store 140 as a compressed object (e.g., compressed object 144AA-144AZ, 144NA-144NZ). In some implementations, one or more reduced LOD object with the lowest lighting difference value can be kept, while the remaining reduced LOD objects can be discarded. For example, encoder 230 can generate lighting difference values between an original object and five different reduced LOD objects. The reduced LOD object with the lowest lighting difference value can be kept for further compression while the remaining four reduced LOD objects can be discarded. Alternatively, in some embodiments, the reduced LOD object with the lowest lighting difference value can be selected as the compressed LOD object.

[0059] In some implementations, encoder 230 can determine which camera angle to select for (lighting related) quality reduction operations using one or more camera angle weights. In some implementations, encoder 230 can select the one or more camera angles by determining whether the related camera angle weight satisfies a threshold criterion. For example, responsive to determining that a camera angle weight is above a threshold value, encoder 230 can generate a snapshot of the 3D object from that camera angle and perform the lighting related compression operations. By performing quality reduction operations on the 3D object from only a select number of camera angles, encoder 230 can generate a set of compressed objects that will most likely be used.

[0060] In some implementations, encoder 230 can run an animation package on the original object and obtain a set of frames reflecting different positions of the 3D object. Encoder 230 can then select a total lighting magnitude of a screenshot of each frame or of a subset of each screenshot of each of the frames of a 3D object. In some implementations, to select the subset, encoder 230 can select, for example, the screenshot of each 5thframe, each 10thframe, etc. Encoder 230 can then generate one or more compressed objects representative of one or more reduced LOD versions of an original object. Encoder 230 can then determine a total lighting magnitude of each screenshot of each frame (or of each screenshot of each frame from the subset) of the original 3D object and a total lighting magnitude of each respective screenshot of the reduced LOD version. Encoder 230 can then determine the lighting difference values between each of the respective pairs of screenshots. The sum of the lighting difference values can be compared against a threshold criterion to determine whether to keep the reduced LOD version or whether to discard the reduced LOD version. Thisenables encoder 230 to integrate both lighting data and animation packages into selecting mesh elements for removal from an object mesh, thus noticeably improvingthe visual quality of illuminated, animated objects.

[0061] Responsive to the target number of polygons being reached, encoder 230 can generate the compressed object and store the compressed object on data store 140. In some implementations, the compressed object can be stored with corresponding metadata relating to one or more particular system resources required by a client device to render the compressed object.

[0062] Selection manager 240 can select a LOD version of the object for display (on the user interface) based on, for example, a display criterion. In particular, application 112 can receive a request, from client device 130A-130N, for an object. For example, application 112 can display a hockey game on the user interface 132A-132N of client device 130A-130N, and the game can request the rendering of a particular hockey player. Selection manager 240 can determine which LOD version of the object (e.g., the hockey player) to send to client device 130A-130N for display on the user interface 132A-132N.

[0063] In one implementation, the selection manager 240 can perform the LOD version selection based on the system resources of client device 130A-130N. A system resource can be any physical or virtual component of limited availability within a computer system, such as connected devices and / or internal system components. System resources can include processors (e.g., central processing units (CPU)), processing speed, memory (e.g., volatile memory such as random-access memory (RAM), non-volatile memory such as hard disk memory, virtual memory, etc.), network throughput, cache space, external devices, etc. In some implementations, selection manager 240 can obtain, from client device 130A-130N, data relating to the system resources of the client device. For example, selection manager 240 can request and obtain particular system resource data (e.g., current network throughput, available processing power, etc.) from client device 130A-130N. Once obtained, selection manager 240 can select, based on the system resource data, which LOD version of the object to send to the requesting client device. Selection manager 240 can then obtain the selected LOD version from data store 140 and send, to client device 130A-130N, the selected LOD version of the requested object.

[0064] In another implementation, selection manager 240 can perform the LOD version selection based on one or more settings parameters selected in the application. For example, application 112 can display, via user interface 132A-132N, one or more settings parameters that can be selected or changed via user input. In some implementations, the settingparameters reflect object resolution (e.g., high resolution, medium resolution, low resolution), display resolution, object data size, etc.

[0065] In some implementations, selection manager 240 can maintain a database (e.g., a metadata table) correlating certain system resources and / or setting parameters with certain LOD versions of an object. In one example, object 142A can correlate to the high object resolution setting, compressed object 144AA can correlate to the medium object resolution setting, and compressed object 144AZ can correlate to the low object resolution setting. In another example, different network throughput thresholds can trigger the selection of different LOD versions (e.g., network throughput being above a first threshold value correlates to object 142 A, network throughput being below the first threshold value but above a second threshold value correlates to compressed object 144AA, and network throughput being below the second threshold value correlates to compressed object 144 AZ).

[0066] FIG. 3 depicts a flow diagram of a method 300 showing a process for generating a compressed object, in accordance with some aspects of the disclosure. The method 300 is performed by processing logic that can comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general-purpose computer system or a dedicated machine), or a combination of both. In one implementation, the method is performed by compression server 120 of FIG. 1, while in some other implementations one or more operations ofFIG. 3 can be performed by another machine. In one implementation, a processing device of compression server 120 performs method 300.

[0067] At operation 310, processing logic obtains a 3D object. In some implementations, the 3D object can be an original object (e.g., object 142A-142N) obtained from data store 140. In some implementations, the 3D object can be a compressed object (e.g., compressed object 144AA-144AZ, 144NA-144NZ) obtained from data store 140. In such implementations, method 300 canbe used to further compress an already compressed object. The 3D object can include a mesh formed from a set of polygons (e.g., triangles).

[0068] At operation 320, processing logic obtains lighting data corresponding to the object. For example, the processing logic can obtain the corresponding lighting data from data store 140 where the data is stored when uploaded by a creator. In some implementations, the processing logic can also obtain an animation package(s) related to the object.

[0069] At operation 330, processing logic identifies, based on the lighting data corresponding to the 3D object, a set of polygonsto be removed from the mesh of the original object. The set of polygons can be identified based on a set of mesh elements selected for removal by mesh decimator 220. In some implementations, the set of mesh elements can beselected using, for example, total lighting magnitude values, lighting difference values between multiple screenshots of the 3D object, etc. In some implementations, the processing logic also identifies the set of polygons to be removed from the mesh of the original object based on the animation package(s).

[0070] At operation 340, processing logic generates a compressed version of the 3D object. The processing logic can generate the compressed versions by performing one or more quality reduction operations to remove the identified polygons (or mesh elements). The compressed mesh can include a set of remaining polygons that reflect the difference between the initial set of polygons and the identified set of polygons.

[0071] FIG. 4 depicts a flow diagram of another method 400 showing a process for generating a compressed object, in accordance with some aspects of the disclosure. The method 400 is performed by processing logic that can comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general-purpose computer system or a dedicated machine), or a combination of both. In one implementation, the method is performed by compression server 120 of FIG. 1, while in some other implementations one or more operations of FIG. 4 can be performed by another machine. In one implementation, a processing device of compression server 120 performs method 400.

[0072] At operation 410, processing logic obtains an object and the lighting data corresponding to the object.

[0073] At operation 415, processing logic renders the original object with the lighting conditions from the lighting data.

[0074] At operation 420, processing logic selects a camera angle of the object. In some implementations, the camera angle can be a predetermined camera angle selected for use with the object. In some implementations, the camera angle can be selected based on a related camera angle weight satisfying a threshold criterion (e.g., the camera angle weight is above a threshold value).

[0075] At operation 425, processing logic determines a total lighting magnitude value of the object from the selected camera angle. In some implementations, the processing logic can generate a screenshot of the object from the selected camera view and then sum each lighting value in the screenshot. For example, the processing logic can sum each lighting value of each pixel in the screenshot, sum each lighting vertex in the screenshot, sum particular sections in the screenshot, etc.

[0076] At operation 430, processing logic selects a mesh element to remove from the mesh. The mesh element can be selected using, for example a random selection, achronological selection, a lighting value satisfying a threshold criterion, etc. In an example, the processing logic can randomly select a vertex to remove from the mesh.

[0077] At operation 435, processing logic performs a quality reduction operation on the mesh to remove the mesh element. In particular, the processing logic can perform an edge collapse operation, a vertex removal operation, etc. In an example, the processing logic performs a vertex removal operation to remove the selected vertex from the mesh. Responsive to performing the quality reduction operation, the processing logic generates a compressed object having a reduced LOD version of the mesh.

[0078] At operation 440, processing logic determines a total lighting magnitude value of the reduced LOD version from the selected camera angle. In some implementations, the processing logic can generate a screenshot of the object from the selected camera view and then sum each lighting value in the screenshot. For example, the processing logic can sum of each lighting value of each pixel in the screenshot, the sum of each lighting vertex in the screenshot, sum particular sections in the screenshot, etc.

[0079] At operation 445, processing logic determines a lighting difference value. The lighting difference value can reflect the difference in the total lighting magnitude values of the two screenshots. For example, the processing logic can subtract the total lighting magnitude value of the reduced LOD version from the total lighting magnitude value of the original object.

[0080] At operation 450, processing logic determines whether the lighting difference value satisfies a threshold criterion. For example, the processing logic can determine whether the lighting difference value is above or below a threshold value. Responsive to the lighting difference value failing to satisfy the threshold criterion (e.g., the lighting difference value being higher than a threshold value), the processing logic can reject the removal of the identified mesh element and proceed to operation 455 to select a new mesh element for removal. The mesh element can be selected using, for example a random selection, a chronological selection, a lighting value satisfying a threshold criterion, etc. The processing logic then proceeds to operation 435. This loop can then be repeated until a suitable mesh element is found. Responsive to the lighting difference value satisfying the threshold criterion (e.g., the lighting difference value being lower than a threshold value), the processing logic can accept the removal of the identified mesh element and proceed to operation 460.

[0081] In some implementations, the processing logic can generate a listing of lighting difference values from multiple reduced LOD versions. For example, the processing logic can generate 10 reduced LOD versions, generate a respective lighting difference valuecorresponding to each version, and sort the lighting difference values. The processing logic can then select the LOD version with the lowest lighting difference value and proceed to operation 460.

[0082] At operation 460, the processing logic determines whether the compressed version of the mesh satisfies an LOD criterion. The LOD criterion reflects a desired quality of the object. The quality can be based on the number of desired polygons, the data size of the desired object, etc. In some implementations, multiple qualities canbe desired. For example, an original object can include a mesh of 1,000 polygons. The desired qualities can include a compressed object having one mesh of 500 polygons, another compressed object having a mesh of 250 polygons, and a third compressed object having a mesh of 100 polygons. Accordingly, for example, the processing logic can determine whether the number of polygons in or the data size of the reduced LOD version of the mesh is at or below the desired number of polygons or the desired data size.

[0083] Responsive to the compressed version of the mesh failing to satisfy the LOD criterion, the processing logic proceeds to operation 455. At operation 455, the processing logic selects a new mesh element to remove from the reduced LOD version of the mesh. The processing logic then proceeds to operation 435.

[0084] Responsive to the compressed version of the mesh satisfying the LOD criterion, the processing logic proceeds to operation 465 and stores the compressed versions of the object in data store 140. In implementations where additional compressed versions are desired, method 400 can then proceed to operation 435 and continue generating additional compressed objects until the additional desired version(s) is obtained. In an example, where the original object includes a mesh of 1,000 polygons and operation 465 stored a compressed object having a mesh of 500 polygons, if another compressed object having a mesh of 250 polygons is desired, method 400 can proceed to operation 430 to continue selecting mesh elements for removal until the desired mesh of 250 polygons is generated.

[0085] FIG. 5 depicts a flow diagram of a method 500 for performing a selection of an object version for display on a user interface, in accordance with some aspects of the disclosure. The method 500 is performed by processing logic that can comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general-purpose computer system or a dedicated machine), or a combination of both. In one implementation, the method is performed by application server 110 or application 112 of FIG. 1, while in some other implementations one or more operations of FIG. 5 can be performed by another machine. In one implementation, a processing device of application server 110 performs method 500.

[0086] At operation 510, the processing logic receives a request for an object. The request can be received from a client device running a client application. For example, the client device can be running a client component of a hockey game application, and request the rendering of a hockey player from a server component of the hockey game application. In another example, the client device can request the rendering of an avatar from a server component of an image processing application, augmented reality application, virtual reality application, etc.

[0087] At operation 520, the processing logic determines which LOD version of the requested object to send to the client device for display on the user interface. In some implementations, the processing logic can select the LOD version based on the system resources of the client device. In particular, the processing logic can obtain, from the client device data relating to the system resources of the client device. In some implementations, the data relating to the system resources can be received along with the request for the object. In other implementations, the data relating to the system resources can be obtained from the client device prior to the request, and retrieved from a database (e.g., a metadata table). In some embodiments, the processing logic can request particular system resource data (e.g., current network throughput, available processing power, etc.) from the client device. Based on the system resources of the client device, the processing logic can select a corresponding LOD version of the object. For example, the processing logic can perform a lookup in a database for the LOD version corresponding to the system resources.

[0088] In some implementations, the processing logic can select the LOD version based on one or more settings parameters selected in the application. For example, the processing logic can obtain setting parameters that reflect desired object resolution (e.g., high resolution, medium resolution, low resolution), display resolution, object data size, viewing distance (e.g., the distance between the camera point of view and the object), etc. Based on the settings parameters selected in the application, the processing logic can select a corresponding LOD version of the object. For example, the processing logic can perform a lookup in a database for the LOD version corresponding to the selected system parameter(s)

[0089] At operation 530, the processing logic sends, to the client device, the selected LOD version of the requested object. The client device can then render the requested object.

[0090] FIG. 6 depicts a flow diagram of a method 600 for performing a selection of an object version for display on a user interface, in accordance with some aspects of the disclosure. The method 600 is performed by processing logic that can comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general-purpose computersystem or a dedicated machine), or a combination of both. In one implementation, the method is performed by client device 130A-130N of FIG. 1, while in some other implementations one or more operations of FIG. 6 can be performed by another machine. In one implementation, a processing device of client device 130A-130N performs method 600.

[0091] At operation 610, the processing logic initiates an application. In some implementations, the processing logic can send a request to application server 110 to initiate, on client device 130A-130N, application 112. Once initiated, the processing logic can run the requested application. For example, the processing logic can run a client component of a hockey game application, of an online platform, augmented reality application, virtual reality application, etc.

[0092] At operation 620, the processing logic requests rendering of an object related to the application. For example, the processing logic can send a request, to application server 110, for the rendering of a hockey player from the hockey game application, of an avatar from the online platform, etc. In some implementations, the request can include data relating to one or more system resources of the client device, data relating to one or more setting parameters selected in the application, etc. In other implementations, the data relating to the one or more system resources or the one or more settings parameters can be sent, to the application server 110, during (or prior or subsequent to) the initiation of the application.

[0093] At operation 630, the processing logic receives the requested object. In some implementations, the object can be a compressed version of the requested object. For example, the application server can select a compressed object based on the data relating to the system resource(s) and / or settings parameters.

[0094] At operation 640, the processing logic renders the received object. For example, the processing logic can render a compressed version of the hockey player, a compressed version of the avatar, etc.

[0095] FIG. 7 depicts a block diagram of a computer system operating in accordance with one or more aspects of the present disclosure. In certain implementations, computer system 700 can be connected (e.g., via a network, such as a Local Area Network (LAN), an intranet, an extranet, or the Internet) to other computer systems. Computer system 700 can operate in the capacity of a client device. Computer system 700 can operate in the capacity of a server or a client computer in a client-server environment. Computer system 700 can be provided by a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, switch or bridge, or any device capable of executing a set of instructions (sequential or otherwise) thatspecify actions to be taken by that device. Further, the term "computer" shall include any collection of computers that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methods described herein.

[0096] In a further aspect, the computer system 700 can include a processing device 702, a volatile memory 704 (e.g., random access memory (RAM)), a non-volatile memory 706 (e.g., read-only memory (ROM) or electrically erasable programmable ROM (EEPROM)), and a data storage device 718, which can communicate with each other via a bus 708.

[0097] Processing device 702 can be provided by one or more processors such as a general purpose processor (such as, for example, a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a microprocessor implementing other types of instruction sets, or a microprocessor implementing a combination of types of instruction sets) or a specialized processor (such as, for example, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), or a network processor).

[0098] Computer system 700 can further include a network interface device 722. Computer system 700 also can include a video display unit 710 (e.g., an LCD), an input device 712 (e.g., a keyboard, an alphanumeric keyboard, a motion sensinginput device, touch screen), a cursor control device 714 (e.g., a mouse), and a signal generation device 716.

[0099] Data storage device 718 can include a non-transitory machine-readable storage medium 724 on which can store instructions 726 encoding any one or more of the methods or functions described herein, including instructions encoding components of client device of FIG. 1 for implementing methods 300, 400, 500 and 600.

[0100] Instructions 726 can also reside, completely or partially, within volatile memory 704 and / or within processing device 702 during execution thereof by computer system 700, hence, volatile memory 704 and processing device 702 can also constitute machine-readable storage media.

[0101] While machine-readable storage medium 724 is shown in the illustrative examples as a single medium, the term “computer-readable storage medium” shall include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) that store the one or more sets of executable instructions. The term “computer-readable storage medium” shall also include any tangible medium that is capable of storing or encoding a set of instructions for execution by a computer that cause the computer to perform any one or more of the methods described herein. The term “computer-readable storage medium” shall include, but not be limited to, solid-state memories, optical media, and magnetic media.

[0102] The methods, components, and features described herein can be implemented by discrete hardware components or can be integrated in the functionality of other hardware components such as ASICS, FPGAs, DSPs or similar devices. In addition, the methods, components, and features can be implemented by firmware modules or functional circuitry within hardware devices. Further, the methods, components, and features can be implemented in any combination of hardware devices and computer program components, or in computer programs.

[0103] Unless specifically stated otherwise, terms such as “receiving,” “determining,” “sending,” “displaying,” “identifying,” “selecting,” “excluding,” “creating,” “adding,” or the like, refer to actions and processes performed or implemented by computer systems that manipulates and transforms data represented as physical (electronic) quantities within the computer system registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices. Also, the terms “first,” “second,” “third,” “fourth,” etc. as used herein are meant as labels to distinguish among different elements and cannot have an ordinal meaning according to their numerical designation.

[0104] Examples described herein also relate to an apparatus for performing the methods described herein. This apparatus can be specially constructed for performing the methods described herein, or it can comprise a general-purpose computer system selectively programmed by a computer program stored in the computer system. Such a computer program can be stored in a computer-readable tangible storage medium.

[0105] The methods and illustrative examples described herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems can be used in accordance with the teachings described herein, or it can prove convenient to construct more specialized apparatus to perform methods 300 and 400 and / or each of its individual functions, routines, subroutines, or operations. Examples of the structure for a variety of these systems are set forth in the description above.

[0106] The above description is intended to be illustrative, and not restrictive. Although the present disclosure has been described with references to specific illustrative examples and implementations, it will be recognized that the present disclosure is not limited to the examples and implementations described. The scope of the disclosure should be determinedwith reference to the following claims, along with the full scope of equivalents to which the claims are entitled.

Claims

CLAIMSWhat is claimed is:1 . A method, comprising: obtaining, by a processor, a three-dimensional (3D) object comprising a first plurality of polygons that form a mesh; generating a first set of lighting values associated with the 3D object, wherein lighting values of the first set of lighting values are associated with one or more simulated lighting conditions used to illuminate the 3D object; identifying one or more polygons to be removed from the mesh; generating a compressed version of the 3D object comprising a second plurality of polygons by removing the identified one or more polygons from the mesh; generating a second set of lighting values associated with the initial compressed version of the 3D object; determining a difference between the first set of lighting values and the second set of lighting values; and generating an output compressed version of the 3D object based upon the determined difference.

2. A method according to claim 1, further comprising: responsive to the difference between the first set of lighting values and the second set of lighting values satisfying a threshold criterion, identifying one or more polygons of the second plurality of polygons to remove from the mesh.

3. The method of claim 1 or 2, further comprising: responsive to a difference between the first set of lighting values and the second set of lighting values failing to satisfy the threshold criterion, storing the compressed version of the 3D object.

4. The method of claim 1 or 2, further comprising: responsive to a difference between the first set of lighting values and the second set of lighting values failing to satisfy the threshold criterion, generating a further compressed version of the 3D object different from the compressed version of the 3D object.

5. The method of claim 3, further comprising: receiving, from a client device, a request for the 3D object; selecting, based on a system resource or a setting parameter of the client device, the compressed version of the 3D object; and sending, to the client device, the compressed version of the 3D object.

6. The method of any preceding claim, wherein each lighting value of the first set of lighting values is associated with a particular pixel of an image of the 3D object, a particular vertex of the image of the 3D object, or a particular segment of the image or frame of the 3D object.

7. The method of any preceding claim, further comprising: generating a first sum reflecting each value of the first set of lighting values; generating a second sum reflecting each value of the second set of lighting values; generating the difference between the first set of lighting values and the second set of lighting values by subtracting the second sum from the first sum.

8. The method of any preceding claim, further comprising: generating a set of compressed versions of the 3D object, wherein each compressed version of the set of compressed versions comprises a respective mesh; generating a respective set of lighting values associated with each compressed version of the set of compressed versions; determining, a respective difference value between the first set of lighting values and each respective set of lighting values; and selecting, for storage, at least one compressed version of the 3D object based on a relationship of the difference value associated with the at least one compressed version to the difference values associated with the remaining compressed versions of the 3D object.

9. The method of any preceding claim, further comprising: selecting a camera angle of the 3D object, wherein the lighting values are based on the selected camera angle of the 3D object, wherein the camera angle is selected based on an associated weight value satisfying a threshold criterion.

10. A system comprising: a memory; and a processing device, coupled to the memory, the processing device to perform operations comprising a method according to any preceding claim.

11. A non-transitory computer-readable medium comprising instructions that, responsive to execution by a processing device, cause the processing device to perform operations comprising a method according to any one of claims 1 to 9.

Images