US20140380197A1

US20140380197A1 - System and Methods for Managing Distributed Physics Simulation of Objects in a Virtual Environment

Info

Publication number: US20140380197A1
Application number: US14/480,905
Authority: US
Inventors: David Baszucki
Original assignee: Individual
Current assignee: Individual
Priority date: 2009-11-20
Filing date: 2014-09-09
Publication date: 2014-12-25
Also published as: US8832568B2; US20110126131A1

Abstract

A computerized server managing a Virtual Environment (VE) has a network port for communicating with remote computerized appliances, a plurality of virtually-defined rigid objects in the VE, including one or more avatars representing persons in the VE, a physics simulation engine executing from a machine-readable medium, for calculating object states and properties, including motion of virtually-defined rigid objects, and a mechanism for assigning and tracking identification of remote computerized appliances connected via the network port, each remote appliance capable of physics simulation. The server responds to signals from the remote computerized appliances to assign individual ones of the virtually-defined rigid objects to individual ones of the remote computerized appliances for physics simulation, and the server simulates all virtually-defined objects in the VE that are not assigned to at least one of the remote computerized appliances.

Description

CROSS-REFERENCE TO RELATED DOCUMENTS

The present application is a continuation application of co-pending U.S. application Ser. No. 12/623,292, filed Nov. 20, 2009, and incorporates all disclosure of the parent application at least by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention
The present invention is in the field of computer-aided modeling and pertains particularly to methods and apparatus for managing physics simulation of three dimensional objects over multiple client computing appliances.
2. Discussion of the State of the Art
In the art of computer-aided modeling, virtual environments (VEs) are created and exist for such as educational and entertainment purposes. Virtual reality games, three dimensional toys, and other types of virtual environments exist where clients subscribe to a gaming site or virtual-world site and engage in interaction with the virtual presentations. Virtual environments comprise objects with attributes and properties. Many of these objects require physics simulation of the objects to emulate the results of object interaction during runtime of the VE. A rigid-body-dynamics simulation engine is an example of one processing engine adapted to simulate motion and dynamics of a three dimensional object in a virtual environment.
As users demand larger and more complex VEs, physics simulation of rigid body dynamics of a very large virtual world may become a challenge to accomplish on a single computer. Simulating a large virtual world is computationally expensive and requires robust server resources.
Therefore, what is clearly needed is a system and methods for managing physics simulation of objects in a virtual environment distributed over multiple client computing devices of clients engaged in interacting with the virtual environment. A system such as this would decrease load on a core server machines, reduce perceived lag time between interaction and simulation results and would result in a capability of offering larger and more complex virtual environments with less expense relative to computer processing resources required to simulate the physics of the environment.

SUMMARY OF THE INVENTION

The inventor has recognized a need for reducing the computation load of servers providing Dynamic Virtual Environments which may be visited and interacted with by persons using computerized appliances connected to the server through network paths. Accordingly, in an embodiment of the invention a computerized server managing a Virtual Environment (VE) is provided, comprising a network port for communicating with remote computerized appliances, a plurality of virtually-defined rigid objects in the VE, including one or more avatars representing persons in the VE, a physics simulation engine executing from a machine-readable medium, for calculating object states and properties, including motion of virtually-defined rigid objects, and a mechanism for assigning and tracking identification of remote computerized appliances connected via the network port, each remote appliance capable of physics simulation. The server responds to signals from the remote computerized appliances to assign individual ones of the virtually-defined rigid objects to individual ones of the remote computerized appliances for physics simulation, and the server simulates all virtually-defined objects in the VE that are not assigned to at least one of the remote computerized appliances.
Also in an embodiment of the invention the network is the Internet network, and the remote computerized appliances are internet-connected appliances used by persons to interact with the VE managed by the server. Further in an embodiment of the invention the server periodically receives simulation data from individual ones of the remote computerized appliances, according to virtually-defined rigid objects assigned for simulation to those appliances, updates the VE accordingly, and transmits updated state of the VE periodically to individual ones of the remote computerized appliances.
In one embodiment the assignment of virtual objects for simulation to remote appliances is dynamic, and reassignment is made periodically according to data received from the remote computerized appliances. Further in this embodiment, individual ones of the remote computerized appliances comprise a mechanism for tracking local computer resources available for physics simulation of virtually defined objects, and individual ones of the appliances expand or contract requests for local simulation depending on computer resources available.
In another aspect of the invention a method for managing a Virtual Environment (VE) by a network-connected server is provided, comprising the steps of (a) defining a plurality of virtual rigid objects in the VE, including one or more avatars representing persons in the VE; (b) establishing communication with one or more remote computerized appliances via a network port; (c) assigning identification to connected remote computerized appliances; (d) assigning individual ones of the virtual rigid objects in the VE to individual ones of the remote computerized appliances for physics simulation according to requests from the remote computerized appliances in communication with the network-connected server; and (e) simulating state and properties of all virtually-defined objects in the VE that are not assigned to at least one of the remote computerized appliances, by a simulation engine coupled to the network-connected server.
In one embodiment the network is the Internet network, and the remote computerized appliances are internet-connected appliances used by persons to interact with the VE managed by the server. Also in an embodiment the server periodically receives simulation data from individual ones of the remote computerized appliances, according to virtually-defined rigid objects assigned for simulation to those appliances, updates the VE accordingly, and transmits updated state of the VE periodically to individual ones of the remote computerized appliances.
Further in an embodiment the assignment of virtual objects for simulation to remote appliances is dynamic, and reassignment is made periodically according to data received from the remote computerized appliances. And still further, individual ones of the remote computerized appliances comprise a mechanism for tracking local computer resources available for physics simulation of virtually defined objects, and individual ones of the appliances expand or contract requests for local simulation depending on computer resources available.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

FIG. 1 is an architectural overview of a communications network that supports distributed physics simulation and management thereof according to an embodiment of the present invention.

FIG. 2 is a block diagram of a client physics-simulation region established geometrically about a client avatar according to an embodiment of the present invention.

FIG. 3 is a block diagram of the client physics-simulation region of FIG. 2 expanded to include one or more virtual objects for physics simulation according to an embodiment of the present invention.

FIG. 4 is a line graph representing a client CPU capacity curve representing physics simulation of virtual objects over time.

FIG. 5 is a block diagram illustrating a server view of multiple client simulation regions within a virtual environment space according to an embodiment of the present invention.

FIG. 6 is a process flow chart illustrating steps for dynamic assignment of client physics simulation properties according to an embodiment of the present invention.

FIG. 7 is a block diagram illustrating a physics simulation ownership map according to an embodiment of the present invention.

FIG. 8 is a process flow chart illustrating steps for managing distributed physics simulation of multiple virtual objects according to an embodiment of the present invention.

DETAILED DESCRIPTION

In embodiments of the present invention, the inventors provide a system and methods for managing distributed physics simulation loads relative to virtual objects on multiple clients in a server/client-based virtual environment hosted on a digital network. The present invention is described in enabling detail using the following illustrated examples, which may include more than one embodiment of the present invention.
FIG. 1 is an architectural overview of a communications network 100 that supports distributed physics simulation and management thereof according to an embodiment of the present invention. Communications network 100 represents a digital wide-area-network (WAN) such as an Internet network. A network backbone 101 is illustrated in this example and represents all of the lines, equipment, and access points that make up the Internet network as a whole. Therefore, there are no geographic limitations to the practice of the present invention. Network 100 may include the Internet network and any connected sub-networks including telephone carriers that may provide access to network 100 physically represented herein by backbone 101.
In this example, network backbone 101 serves as a carrier network for communications between an online gaming service (OGS) 102 and multiple clients 112 (1-n) of OGS 102. OGS 102 represents any business adapted to provide an online virtual environment (VE), including virtual worlds and other online games. Such virtual worlds and online games may be accessed by subscribing clients operating client computing devices 112 (1-n). OGS 102 may lease or may host and maintain a Web server (WS) 103 including a Web site (not illustrated) that serves as service access point (SAP) for clients operating client computing devices 112 (1-n). WS 103 has connection to network backbone 101 for communication and access purposes.
WS 103 includes a digital medium (not illustrated) coupled thereto which is adapted to store all of the software and data required to enable server function as a Web server capable of serving electronic information pages to clients of OGS 102, and of registering clients for access to virtual environments and or online gaming available through OGS 102. In one embodiment WS 103 may be located within the physical domain of OGS 102 without departing from the spirit and scope of the present invention.
Client computing devices 112 (1-n) are desktop personal computers (PCs) in this example. In other embodiments other types of personal computing devices might be used to access WS 103 and to engage services offered by OGS 102. Other type of device that might be used to connect to WS 103 for the purpose of accessing OGS services include but are not limited to a laptop computer, a cellular (smart) telephone, a personal digital assistant (PDA), a specialized gaming box, or a Web-TV. In this example, client computing devices 112 (1-n) are connected to network backbone 101 via logical access line connections 107, 108, 109, and 110. It is noted herein that client computing devices 112 (1-n) may connect to network backbone 101 through an Internet Service Provider (ISP) using a high-speed Internet access protocol like digital services line (DSL), broadband, T1-X, wireless (WiFi), cable/modem, and in other ways as well.
Each client device 112 (1-n) includes at least one central processing unit (CPU) coupled thereto and adapted to execute all of the software and data required to enable multi-task or dedicated computing function. Each client device 112 (1-n) includes a browser application 111(one per device), used to connect to and to navigate to Web-based services including Web Pages and gaming services though re-direction of clients from WS 103 to an online gaming server (GS) 105 illustrated within the physical domain of OGS 102. GS 105 has connection to network backbone 101 and includes at least one digital medium (not illustrated) coupled thereto and adapted to store all of the software and data required to enable server function as an online game server. OGS 105 includes, among other game server components, a physics simulation engine (PSE) 106 a. PSE 106 a provides real-time physics simulation of 3D objects of a VE. In one embodiment PSE 106 a is a rigid-body-dynamics simulation engine although other types and combinations thereof might be used in practice of the present invention.
In this example client computing devices 112 (1-n) are all connected online over network backbone 101 with GS 105 and are actively engaged in a VE offered through the server, such as a virtual world or other online game comprising one or more virtual three dimensional (3D) objects that require physics simulation of motion during game play or engagement with the virtual world. Each client computing device has an executable application resident thereon that includes at least a subset or a version of PSE (106 a) provided on GS 105. Those illustrated versions of PSE are a PSE 106 b running on client computing device 112 (1), a PSE 106 c running on client computing device 112 (2), a PSE 106 d running on client computing device 112 (3), and a PSE 106 x running on client computing device 112 (n).
In this regard, each display of client computing devices 112 (1-n) exhibits an avatar and a local client simulation region (CSR). Machine readable code including at least a CPU monitor and a PSE is available to client computing devices through a downloaded application or plug-in from WS 103 or GS 105. The respective versions of PSE enable each client computing device 112 (1-n) to physically simulate motion of such virtual objects that may reside within each CSR. Each CSR represents a portion of space of the total available virtual space of a virtual world or other VE containing objects for physics simulation. Each avatar, for example, represents a 3D object owned by the client engaged in a 3D VE offered by OGS 102.
A 3D object in a VE includes but is not limited to properties and attributes such as a Guid (unique identifier), a position property including a position rotation property, a velocity property including a rotational velocity property, and geometry. A 3D object in a VE may also contain but is not limited to containing the following physical properties: object mass, moment of inertia for the object, object density, and friction. The appearance attributes of an object include the geometry and texture of the object. In most virtual environments the avatar represents the client engaged in the environment. Multiple avatars indicate multiple clients engaged in the virtual world or environment. In this example, client computing device 112 (1) exhibits a CSR 113 on the display of the device. Similarly, computing clients 112 (2-n) exhibit CSRs 114, 115, and 116 on the associated display devices respectively.
For purpose of this specification a CSR is a client physics simulation region defining an area of virtual space of a VE within which a client may physically simulate objects. A CSR is enabled by a CPU monitoring application (not illustrated) residing on the computing client. Such an application is part of the same machine-readable application code including the PSE version residing on the client computing device. A CSR has an evolving shape and/or volume/size that is dictated by available CPU capacity monitored in real time during client engagement with a VE offered through OGS 102.
The shape of a CSR may vary or may be relatively consistent. A CSR may be spherical, rectangular, polygonal, trapezoidal, cylindrical, triangular, elliptical, or some other geometry without departing from the spirit and scope of the present invention. Each CSR may be geometrically aligned in a true position relative to the center of mass of the avatar with which it is associated. For example, if the CSR is a sphere, the center of mass of the avatar may mark the center of the sphere. A client operating in a VE at the position of it's avatar in total virtual space attempts to physically simulate those 3D objects residing closest to it. Therefore, within a CSR of an avatar there would presumably be one or more 3D objects other than the avatar to be physically simulated by that client computing device (CPU) using the resident PSE version on that device. More about distributed physics simulation of 3D objects in a VE is described later in this specification.
GS 105 has a separate digital network connection 117 to various support servers and data repositories adapted to facilitate game service delivery. An image server (IS) 118 is provided within OGS 102 and is connected to GS 105 over network 117. IS 118 has a digital medium coupled thereto adapted to store all of the software and data required to enable function as an image server. IS 118 is adapted primarily to serve VE images to GS 105 from an image repository 119. Repository 119 may be a mechanical disk drive, a magnetic disk or an optical disk, or other known data repository without departing from the spirit and scope of the present invention.
A file server (FS) 122 is provided within OGS 102 and is connected to GS 105 over network 117. FS 122 has a digital medium coupled thereto and adapted to store all of the software and data required to enable function as a file server. FS 122 is adapted to serve files representing online VEs including virtual worlds, virtual games, etc. to GS 105 for rendering. FS 122 manages game or VE files on a file repository 123, which may be a mechanical, magnetic or an optical storage medium.
A data server (DS) 120 is provided within OGS 102 and is connected to GS 105 via network 117. DS 120 has a digital medium coupled thereto which is adapted to store all of the software and data required to enable server function as a data server. DS 120 is adapted to serve run-time data relative to any VEs being rendered by GS 105. Data may include any technical data and information required to successfully render a VE in real time.
GS 105 has a dynamic simulation owner assignment engine (SOAE) 104 provided thereto as an executable parent application resident on the digital medium of the server. SOAE 104 is adapted to assign ownership of physics simulation of one or more 3D objects of a VE to one or more computing clients 112 (1-n). The invention is practiced using an automated server/client connection between each client and GS 105.
In practice of the invention, assume computing clients 112 (1-n) are all connected to GS 105 and are all participating in interaction with a VE running on the server. PSEs 106 b through 106 x facilitate local physics simulation of 3D objects on the client computing devices. CSRs 113 through 116 represent the physics simulation regions containing objects that the clients are allowed (and enabled) to simulate locally. PSE 106 a running on GS 105 simulates (server-side) all of the 3D objects of the VE that are not simulated locally (client-side). SOAE 104 listens for information updates from client computing devices and assigns simulation ownership to those objects which fall within a CSR to the client ID associated with that CSR for all of the client CSRs. Objects that do not fall within a CSR are simulated by the server engine (PSE 106 a). It is noted herein that assignments made by SOAE 104 are temporary and dynamic, such that an object may change simulation owners many times during run time.
The volume of a CSR changes depending on the current processing capacity of the local CPU supplying the processing resource for the local PSE used to simulate motion, collision, contact, and other attributes of an object. A local PSE contains all of the logic, instructions, and rules to enable complete physics simulation of an object on the local computing device. A small monitoring application keeps track of the simulation process and calculates a total volume of a local CSR based on the time that it takes for the CPU to process simulation of one or multiple objects within the CSR. As a result, the current volume of a local CSR is expanded and decreased on a continual basis throughout runtime of the VE.
One or more threshold values relative to objects simulated over time may be established, in one embodiment with weighting associated with CPU type and available RAM. In one embodiment available bandwidth can also be a weighting factor in determining size of a physics simulation region for a client. There may be minimum system requirements for local physics simulation of VE objects. As a local CSR, such as CSR 113 on client computing device 112 (1) expands, it may encompass additional 3D objects that may then, by reassignment, be simulated by that client. Similarly, the available volume of a local CSR may contract thus freeing up some 3D objects for reassignment to another physics simulation owner (PSO) such as another client or the server. All of the current CSRs of a VE are mapped according to avatar position in a preferred embodiment to a data structure held and maintained by data server 120 or by GS 105. This data structure (not illustrated here) is termed a “client ownership map” which is continually updated with new information during runtime. The primary intelligence of the mapping is which client is currently in charge of simulating which objects in the VE, and which objects in the VE have the server (PSE 106 a) as the simulation owner.
The amount of physics simulation of objects performed by clients or players is determined locally on the computing device of each client/player. Any objects not simulated by a client are simulated by the server. SOAE 104 updates the client ownership mapping as a result of continuous client updates relative to the current volume of the CSR. Those objects that become included in a CSR may be reassigned to the client of that CSR for simulation and those objects that become freed from a CSR due to decreasing volume of the CSR are reassigned to another client (if “positionally” within another CSR or to the server if they are not found within a boundary of a CSR). A continual process of object lookup, object simulation owner reassignment, and mapping update takes place at the server based on continuous or periodic client updates.
Updating is frequent, on the order of 30 cycles per second more or less. GS 105 also propagates all of the updates in object position and properties to all other clients engaged in game play. It is noted in this example that communication between GS 105 and client computing devices 112 (1-n) occurs in unidirectional transmissions similar to a walkie-talkie transmission. When a client has some information to update to the server it pushes the information to the server transparent of the client. When GS 105 has information to send to clients, it pushes the information to each client transparent of the client. In this way updates are faster and more efficient. More detail about managing dynamic assignment of simulation ownership is provided later in this specification.
FIG. 2 is a block diagram illustrating a client physics-simulation region (CSR) 113 established geometrically about a client avatar 200 according to an embodiment of the present invention. Simulation region 113 may be a three dimensional sphere or cylinder or any other volumetric geometry. Region 113 is established locally based on what objects a client attempts to physically simulate locally using the primary CPU of the client's computing device with the aid of the local PSE. Simulation region 113 is not visible to the client and all physics simulation whether performed at the server by the client or by other clients is transparent to the client as far as simulation owner is concerned. However, in one embodiment a small interface may be made available to clients where simulation activity performed on the client and the drain on processing resources of such physics simulation may be reported statistically for informational purposes. Such an interface may be integrated into the OS CPU performance interface that reports threads, networking status, and other CPU performance data.
Avatar 200 represents the client and is given a unique identifier or client identification (CL-ID). The center of mass of avatar 200 may be the center of simulation region 113. Objects that the client could simulate relative to physics include avatar 200, castle 201, rocket 203, and sports car 204. In this case region 113 does not encompass any of the objects with the exception of avatar 200, which the client simulates the entire runtime of the VE. Based on CPU processing capacity, region 113 will expand and contract to include or exclude virtual objects that require physics simulation. In this example the client is in charge of physics simulation of his or her own avatar 200.
As more processing power is available, region 113 will expand as the client attempts to simulate some of the nearby objects being simulated by the server or another client. Each virtual object that is rigid has a rigid center of mass. This center of mass may be a variable in simulation ownership assignment. For example, in this case the center of mass for objects 201, 202, 203, and 204 lie outside the boundary of sphere 113, thus they are being simulated by other clients or the server. However, client (avatar) 200 will attempt to simulate these objects based on available processing capacity and region 113 will then expand to encompass the center of mass of one or more of these objects. When this occurs, the client reports these objects to the server as objects that the client can simulate or objects that the client is currently simulating. The server may lookup these objects and may reassign these objects to the client (200) for physics simulation. The server then updates the simulation ownership map and propagates the change to all other clients. In another embodiment, other types of tests to determine if an object might be within a simulation region, rather than reliance on the center of mass point for an object. For example, an alternate test might be if any part of a 3D object was in the simulation region, rather than the center of mass.
FIG. 3 is a block diagram illustrating client physics-simulation region 113 of FIG. 2 expanded to include all of the virtual objects shown in FIG. 2 for physics simulation according to an embodiment of the present invention. Simulation region 113 is expanded in this case based on monitored CPU capacity, to encompass objects 201, 202, 203, and 204. In one embodiment all of these objects must be simulated relative to physics by client 200 because they lie within the boundary of simulation region 113. As described above, it may be sufficient that the center of mass of an object lie within the region in order to qualify for simulation ownership. This means that part of the object may lie outside the region of simulation of the client.
It is possible that two or more client simulation regions might overlap one another such that the center of mass of a virtual object lies within the boundaries of two or more client simulation regions (CSRs). In such a case, the server may partition the overlapped portions of the regions such that they no longer overlap. The region that is currently the largest region trying to simulate an object may “win” assignment of a contested object. That is to say that the region having the most capacity may get the decision in a case where an object equally shares two or more simulation regions. In another embodiment it may be required that an object lies fully within the bounds of a region before it may be simulated locally by the client of that region.
In one embodiment there is no CSR established until a client attempts to physically simulate one or more objects other than the client avatar. In this case the client requests physics simulation of an object during interaction with the object and a CSR is first established about the avatar and the initial object, which is assigned automatically to the client attempting to simulate it. As the client attempts to simulate more objects close to it, the assignments of new objects will be made as long as sufficient processing capacity exists on that client such that the CSR encompasses those objects. Processing capacity might be measured as a function of processing drain over time when physically simulating objects. Some clients will have more processing capacity than others for physics simulation of objects.
As long as processing capacity remains stable for a client physically simulating objects, then the size of the CSR region and the number of objects being simulated by the client may remain relatively constant. However, if processing capacity destabilizes with respect to the processing load on the CPU while simulating objects, the size of region 113 may decrease to the point that one or more objects being simulated by the client now lie outside the boundary of the CSR and are thus reassigned to another client or the server for physics simulation. Any virtual objects that cannot be simulated by a client because they lie outside any CSR boundary may be simulated by the server.
It is important to note herein that some virtual objects will require more processing power to simulate the physics thereof than other objects. This may also be true relative to the intensity of simulation of an object having multiple properties that may be simulated. In one embodiment a priority might be established for high-profile game objects in any VE where a hierarchy is represented for the objects such that those with lower processing requirements are physically simulated by clients while those requiring higher levels of processing are retained by the server for simulation. Other priority schemes may be ordered without departing from the spirit and scope of the present invention. One effect of local simulation is that there is a reduction in perceived lag time to individual players because object motion for nearby objects, which those players will first attempt to simulate, is simulated locally, rather than on a server or by another client. Thus there is a very small, if any, perceivable time delay between when an object is simulated and when a player sees the results of that simulation (typically motion). This is especially convenient for the player's avatar, which may also be physically simulated.
A server simulation region (SSR) is a volume of virtual space left over from all CSRs in the virtual space. Hence the server region is not defined as a sphere or cylinder or other geometry, rather the cumulative space left over from all of the CSR region space. It is possible that the server may have no SSR available to process physics of objects if all of the virtual space is handled by clients. It is dually noted herein that physics simulation of an object may conceivably be shared by two or more clients as long as those clients get realtime feedback about which properties of the object may be simulated by which client. Such granularity is possible without departing from the spirit and scope of the present invention.
FIG. 4 is a line graph representing a client CPU capacity curve representing physics simulation of virtual objects over time. Initially all virtual objects of a VE are assigned to be simulated relative to physics by the game server such as GS 105 of FIG. 1. However, when a client enters the VE the client may begin attempting to simulate those objects that are closest to the avatar of the client. In this respect, and in one embodiment, the client tells the server which parts or objects it is attempting to simulate. As long as there is no capacity issue, a CSR is established around those objects and the client is assigned ownership of simulating those objects.
At time 0 of runtime the client is not simulating any objects in the VE. However, as time progresses, the client CSR expands and the local PSE running on the local CPU begins simulating objects assigned to the CSR. As time moves forward the CSR grows in size or volume. At 0.25 seconds for example, the client is simulating the physics of approximately 178 objects. The number of objects is used logically in this example as some objects require more processing power to simulate than others. However, given standalone objects with stated simulation requirements, numbers of objects may be used as some gauge of capacity for simulation.
In this example the curve represents the capacity of the local client for simulating more objects. The curve tops out at about 0.4 seconds, meaning that the CSR has expanded to include approximately 214 objects having been simulated by the client at that point in time. As the curve flattens the CPU processing capacity for that client to simulate physic of VE objects stabilizes and the CSR volume remains relatively stable. If for some reason CPU power at the client is simultaneously used to perform other tasks not related to object simulation, then the curve will begin to dive resulting in a contracting CSR. The CSR will decrease in volume to a point where stabilization again occurs and will expand again if more CPU resources are freed up to simulate more objects.
It is noted herein that not all objects within a CSR are being simulated by that client simultaneously. Objects are simulated relative to physics based on player actions reported during runtime; hence moments of fluctuation in CSR volume may occur to prevent simulation of too many objects within the region at once. A single object may require significantly more CPU resources to simulate than another object or a group of objects. It is also noted herein that objects may be simulated in groups or “superbodies” as long as the objects included in the superbody do not move relative to one another. It is also apparent to one with skill in the art that physics of a single object may be broken down by type of motion or movement and may be shared in terms of simulation by one or more clients or by the server and a client.
FIG. 5 is a block diagram illustrating a server view of multiple client simulation regions within a virtual environment space 500 according to an embodiment of the present invention. Virtual space 500 represents all of the virtual space available to a VE such as an online game or a virtual world. It is noted herein that total virtual space of a VE may expand or contract during runtime of the VE without departing from the spirit and scope of the invention. For example, creation of new objects that require more space may result in more virtual space allotted during runtime. The total volume of a VE may be a dynamic or a fixed component.
Virtual space 500 represents all of the space for a specific VE represented. There are 5 clients engaged in play, the clients defined by avatars 501, 502, 503, 504, and 505. Each client has a CSR established. These are CSR 501 a for client 501, CSR 502 a for client 502, CSR 503 a for client 503, CSR 504 a for client 504, and CSR 505 a for client 505. All of the virtual space that is not included within a CSR is defined as a server simulation region (SSR).
Each CSR is centered about an avatar representing the client or player and each CSR includes a number of objects for physics simulation. The client of a CSR is responsible for simulating all of the objects within the CSR of that client. Objects 508 are illustrated as falling within a CSR. Each object has a unique object ID and each CSR has a unique ID which is that of the client or CL-ID. Objects 507 reside outside of any CSR. Therefore objects 507 are simulated by the server, which has a unique server ID and SSR.
CSR 504 a and CSR 505 a are standalone CSRs, meaning that they do not overlap any other CSRs. CSR 501 a, CSR 502 a, and CSR 503 a overlap one another, meaning that potentially two or more CSRs might encompass a single object for physics simulation. In this case the server may partition such overlapping regions so that the boundaries between them are clearly defined in space. Typically objects that are simulated by a client are those that reside closest to that client's avatar. By partitioning the overlapping regions, this distinction can be made without ambiguity.
In one embodiment a voronoi region approach might be used to partition overlapping CSRs. In this approach space is divided between the overlapping CSRs based on distance to the character point (avatar). In a variation of this embodiment multiplicatively weighted voronoi regions are used where space is divided based on a weighted distance to the character point or avatar. The weight used may include the size, radius, or volume of the CSR. Any objects such as objects 507, which reside outside the bounds of any CSR fall into the SSR by default and are simulated by the game server with the aid of the game server PSE.
FIG. 6 is a process flow chart 600 illustrating steps for dynamic assignment of client physics simulation ownership according to an embodiment of the present invention. At step 601 a virtual 3-D environment is launched. At step 602, the game server presets all of the objects to the unique server ID as the physics simulation owner (PSO). At this point all objects are simulated by the server. At step 603 a client enters the VE. At step 604 the server assigns the client a unique identifier known as a client ID or CL-ID.
Upon entering the VE, the local client app on the CPU of the client computing device executes at step 605. This application includes a local physics processing engine (PSE), in one embodiment, a rigid body dynamics simulation engine. The application also includes a local CPU monitor, which is responsible for establishing a CSR for the client and for managing the volume of the CSR on an ongoing basis. At step 606 the monitor begins tracking local CPU capacity. The client is assumed to have a unique identifier (CL-ID), and an avatar to anchor the CSR. All of the objects in the VE have unique object IDs. All of the objects are set to be simulated by the server.
At step 607 the client requests physics simulation of one or more objects closest to the client avatar. This information is passed to the server as a unidirectional message from the client computing device over an open connection between the game server and the client. The server assigns the client (CL-ID) as physics simulation owner of the objects of the request received by the server at step 608. The assignment removes the former PSO for each object, in this case, the game server. The game server has a unique identifier, which may be (0) in one embodiment. Step 608 may be a default step for any client initially requesting to simulate locally one or more objects, which are currently being simulated at the server.
At step 609 a CSR is established about the client avatar, which incorporates those objects that have been assigned to the client for physics simulation. The server changes the PSO property of the objects from 0 to the client ID. Now all of those objects will be simulated at the client unless reassigned to another client or back to the server. At step 610, the local CPU monitor determines if the CPU capacity for physics simulation at the local client is stable relative to the number of objects being simulated by the client computing device with the aid of the local PSE over time. If so, the local client does nothing and the CSR remains relatively constant and all of the parts within the CSR that are assigned to the client for physics simulation are simulated by that client whenever necessary. The process loops back to step 610.
If at step 610, it is determined by the CPU monitor that the CPU capacity for physics simulation is not stable or constant, it means that it is increasing due to extra processing capacity, or decreasing due to less CPU capacity available for physics simulation of VE objects. The process moves to determine if the available CPU capacity has increased at step 612. If it is determined at step 612 by the CPU monitor of the client computing device that the available CPU capacity for physics simulation has increased, then the CSR region increases accordingly at step 614 and may then encompass additional objects not currently assigned to the client that may be re-assigned to that local client for physics simulation.
In one embodiment as a CSR increases in volume and one or more unique objects come within its bounds, those objects may be reported to the game server as objects subject to a request for local simulation by that client, at which time the GS may reassign those objects to the local client because they fall within the simulation region of that client. In another embodiment a rule exists whereby any objects residing within any CSR shall be locally simulated relative to physics by the client associated with the CSR. In this case re-assignment is automated at the client and replicated to the server for mapping update and update propagation to other clients. In this case the game server is not responsible for determining assignment of an object for simulation. Rather each client determines what objects it can simulate based solely on current processing resources available at the client.
If the CPU monitor determines at step 612 that the CPU capacity has not increased then at step 613 the monitor determines if it has decreased or there is less capacity for physics simulation of objects. If the CPU monitor determines that the capacity of the CPU/PSE has decreased, at step 614 the CSR may be decreased in volume accordingly possibly freeing up one or more objects for physics simulation by the server or by other clients. If at step 613 the CPU monitor cannot determine if the capacity has decreased after determining that it was not stable and not increasing, then the process moves by default or in error mode back to step 611 and then back to step 610 again. At step 615 all of the objects affected by CSR expansion or contraction are reassigned according to which CSR/SSR they currently reside in.
All physics simulation activity executed on a local client is replicated to the server so the server may update the system including the system PSO map tracking all of the objects in the VE and their PSO properties. Steps 610 through 615 are part of a process loop that continuously loops for each client in the VE as long as that client is detected and is online with the game server. Steps 604 through 608 are repeated for each client playing the game, or more particularly, each client computing device engaged but not yet simulating objects. At step 614 only the objects that fall outside a CSR as a result of CSR contraction are assigned new physics simulation owners (PSO's). It will apparent to one with skill in the art of object management that step 610 is not absolutely required to practice this method of the invention. The local monitor may only determine if the capacity has increased or decreased in no specific order.
In an alternate implementation, steps from 605 onward might be implemented at the server, for example one runtime instance for each client connected to the server. In the case where steps 605 onward are implemented in the server, the client transmits its current CPU load to the server so that the server can implement the CPU capacity algorithm.
FIG. 7 is a block diagram illustrating a physics simulation ownership map 700 according to an embodiment of the present invention. Map 700 is logically illustrated herein as a table of metadata loaded onto data server (DS) 120 connected to the game server of the architecture of FIG. 1. Map 700 as a data table is displayed as a column and row table having a first column 701 labeled VE-ID. This column identifies all of the VEs running on the game server at any time. The tuple may be expressed as a name (name of virtual world or game) and version number of the VE.
Mapping table 700 has a second column 702 labeled CL-ID, which lists all of the current clients that are engaged in game play or otherwise interacting with a virtual environment. Each client ID tuple may be a single value each unique to the client. Random generation and assignment of an identifier may be the default method of identifying clients. Clients may be identified by serial number (machine), IP address, random value, or by other methods. The first VE listed in column 701 has 4 clients engaged. This is subjective only as there may be many more clients engaged in a virtual world for example than can be illustrated in this example.
Mapping table 700 has a third column 703 labeled CSR (client simulation region). Column 703 lists the CSR coordinates and volume or size for every engaged client ID. The CSR may be a sphere or some other volumetric geometry where the coordinates in 3 dimensional space may be quantified such as the volume. In one embodiment the coordinate of a CSR is the center of mass of the client avatar. In a game or virtual environment where an avatar can die, then the CSR and client ID disappear from the table once the information replicates to the game server. All of the objects that were within the CSR of the deceased client now have to be reassigned another PSO (one or more clients, or the server, or a combination thereof).
Mapping table 700 has a fourth column labeled SSR (server simulation region). SSR may be equated to the total virtual space for the VE minus all of the CSR space that exists. The SSR may not have an anchor point or any coordinates. In the abstract sense any coordinate in the total space that is not included within the bounds of a CSR is in the SSR. If there is more than one server working in concert to support the VE then the SSRs of those servers may be combined into one SSR since from the client perspective it does not matter which server of more than one server simulates an object.
Listing many, possibly thousands of objects in such a two-dimensional table may not be efficient. Therefore, one or more pointers to the object IDs may be associated with each client ID in the table each pointer pointing to all of the objects currently assigned to that client's simulation region. DS 120 may, in one embodiment, maintain a repository 706 containing all of the objects simulated by the server (object IDs SSR), and another repository 707 containing all of the objects simulated by clients (object IDs CSR). Looking up an object ID will tell the system whether the object has a PSO of server or client and if client, which client. There are many different ways a mapping table of simulation ownership might be constructed and different ways it may be operated.
FIG. 8 is a process flow chart illustrating steps 800 for managing distributed physics simulation of multiple virtual objects according to an embodiment of the present invention. At step 801 a physics simulation owner (PSO) table is constructed for a VE launch. In one embodiment a single table is built for any VEs launched by the game server. In another embodiment each VE running has its own mapping table for mapping objects to PSOs.
At step 802, all of the objects of the VE are preset to be simulated by the game server PSE (PSO=server=0) for all object IDs. At step 803, as clients enter the VE, they are assigned client IDSs and the server receives CSR data from those clients indicating the objects that those clients are attempting to simulate. The server may also automatically establish a CSR for any client that indicates a capability to simulate one or more objects. Once a CSR is established, it is monitored locally and may increase or decrease in volume depending on current CPU capacity for simulating physics of the objects resident within each region for each client. At step 804, the server determines the SSR from calculating the total virtual space minus the current and collective CSR space.
In one embodiment the game server aggregates statistics on objects of the VE by ID at step 805 to determine where the objects are (POS) and who should be the PSO of those objects. At step 806 the server performs a lookup of object IDs and their positions (POSs) in virtual space, which may translate to the coordinates of the objects center of mass in the virtual space. At step 807 the server maps the object positions for each object found to a simulation region. That is to say that for any object position, it resides within a CSR (client) or within the SSR (server). At step 808 for each object the server determines if the object resides within a CSR.
If at step 808 the server determines that the object resides within a CSR, then the server (simulation owner assignment engine) changes the PSO property of the object to the CL-ID of the CSR at step 809. At step 810 those objects are simulated client-side by the local PSEs residing at the client computing devices. If at step 808 the server determines that objects reside outside of the boundaries of any CSR, then at step 811 those objects are simulated server-side at the game server. At step 808 objects will be found both residing in a CSR and residing in the server simulation region. These objects are assigned a PSO relative to their positions in 3D space.
At step 812 the SOAE updates the PSO mapping table with the most recent assignment changes. The process then moves to step 813 where all of the updated information including results of simulation are propagated to all of the clients engaged in interaction with the VE. The process then moves to step 814 where the server receives new CSR updates for processing. The process loops back to step 805 where the update statistics are aggregated for processing. Steps 806 through 813 are continuously performed by the server during runtime. All of the physics simulation of objects is distributed according to CSR/SSR regions where those objects are found to reside. All simulation results performed locally by clients are replicated to the server and are propagated from the server to all other clients. Physics simulation update state may, in one embodiment, be propagated among all of the clients through a peer-to-peer network rather than the server propagating all of the updates to all of the other clients.
In one embodiment all objects are simulated by the server and have a PSO=0, which may be the unique identifier of the server, and PSO reassignment to a client ID occurs only after the client has begun simulation of the object and the simulation data is replicated to the server. At this point the server only lookup the object ID of those objects and changes the PSO designation only if the current PSO assignment is not that of the client ID that was the source of the data replication. In this regard step 805 may be replaced by step 814. In another embodiment the server continuously tracks all of the VE objects and reassigns them to new “client” PSOs any time those objects become included in a client CSR. In one embodiment there may be an object that resides in two CSRs such that both clients are attempting to simulate the object. The server may assign a PSO to the object ID whose CSR is currently largest among the contending CSRs. Partitioning overlapping CSRs may be performed by the server to clarify where an object resides and thus which client will be the current PSO of the object.
As described further above, it is possible that more than one client or a client and the server may share simulation of an object if more than one object property is simulated. Such granularity is possible where an object resides in a CSR and has the client ID as a PSO and where that PSO cannot completely simulate the object without becoming unstable. In this case the serve may simulate some motion of the object and the client may simulate the rest of the motion of the object, etc. In this example all of the properties of an object are simulated by a client PSE or by a server PSE and PSO assignment is based on the calculated position of the object relative to one or more defined simulation regions. In all embodiments, the server updates object positional data and property changes replicated thereto by a client to all other clients. All object property changes resulting from server simulation are likewise propagated to all clients so that all of the clients and the server are continually interacting with the latest object versions.
A network replication system is provided that automatically sends the events “Object Create”, “Object Delete”, and “Property Change” between client and server to maintain an identical list of objects and properties for all parts on both the client and server. Physics simulation applies to at least simulation of motion, and includes full simulation of collision between objects, contact between objects, and mechanical joint properties of each object. Whenever two or more clients attempt to simulate a same object, the server arbitrates to determine which of the clients will be assigned the simulation owner. Objects may differ in properties and attributes during the miniscule amount of time that updates from a change are transmitted, however the fluid dynamics of the environment are not affected by these differences. Events transmitted between server and clients are one-way massages.
One with skill in the art of 3D animation will appreciate that other types of motion simulators and architectures may be used in addition to rigid-body-dynamics simulators without departing from the spirit and scope of the present invention. Objects with rapidly changing centers of mass or “fluid” objects may be simulated by clients or the server using the appropriate simulation components without departing from the spirit and scope of the present invention.
It will be apparent to one with skill in the art that the distributed physics simulation system of the invention may be provided using some or all of the mentioned features and components without departing from the spirit and scope of the present invention. It will also be apparent to the skilled artisan that the embodiments described above are specific examples of a single broader invention which may have greater scope than any of the singular descriptions taught. There may be many alterations made in the descriptions without departing from the spirit and scope of the present invention.

Claims

1-11. (canceled)

12. A system comprising:

a computerized server having a processor executing software (SW) from a non-transitory machine-readable medium, the SW enabling the server to manage a virtual environment (VE) comprising a plurality of virtually defined objects;

a network interface at the computerized server communicating with a remote client-side computerized appliance allowing access to and interaction with the VE by a person directly operating the computerized appliance;

a first simulation engine executing as a part of the SW at the computerized server managing the VE;

a second simulation engine executing on the client-side computerized appliance, enabled to calculate object states and properties for objects in the VE; and

an application executing on the client-side computerized appliance monitoring operating characteristics of the client-side computerized appliance and managing a variable client-simulation region (CSR), the application varying one or both of volume and shape of the CSR according to varying operating characteristics of one or both of the client-side computerized appliance;

wherein the second simulation engine executing on the client-side computerized appliance calculates object states and properties for objects of the VE within the region of the CSR, and the first physics simulation engine, at the server calculates object states and properties for all objects of the VE that are not in the CSR.

13. The system of claim 12 wherein one of the objects is an avatar, and the second simulation engine manages all changes in behavior of the avatar while the avatar is in the CSR.

14. The system of claim 13 comprising more than one avatar, wherein the second simulation engine manages all changes in behavior of any avatar while in the region of the CSR.

15. The system of claim 12 wherein any change in the VE triggered by user input at the client-side computerized appliance is managed by the second simulation engine.

16. The system of claim 14 wherein sharing of workload between the first and the second simulation engines is varied according to varying operating characteristics of one or both of the server and the client-side computerized appliance.

17. The system of claim 12 wherein the CSR is anchored to a specific object in the VE, and moves with that object.

18. The system of claim 17 wherein the object to which the CSR is anchored is an avatar.

19. A method comprising:

determining object states and properties for a first set of objects in a virtual environment (VE) by a first simulation engine executing from a non-transitory medium on a processor of a computerized server; and

determining object states and properties for a second set of objects in the VE by a second simulation engine executing from a non-transitory medium on a client-side computerized appliance operated by a user interacting with the virtual environment;

wherein objects in the first set and the second set are determined by monitoring varying computing capability of one or both of the server and the client-side computerized appliance.

20. The method of claim 19 wherein the objects in the first set and the objects in the second set are all of the objects defined in the VE.

21. The method of claim 19 wherein the objects in the second set are determined as objects within a client-simulation region that varies in one or both of size and shape according to computing capability of the client-side computerized appliance.

22. The method of claim 21 wherein one of the objects in the second set is an avatar, and the second simulation engine manages all changes in behavior of the avatar while the avatar is in the CSR.

23. The method of claim 22 comprising more than one avatar, wherein the second simulation engine manages all changes in behavior of any avatar while in the region of the CSR.

24. The method of claim 19 wherein any change for objects in the VE triggered by user input at the client-side computerized appliance is managed by the second simulation engine.

25. The method of claim 12 wherein the CSR is anchored to a specific object in the VE, and moves with that object.

26. The method of claim 25 wherein the object to which the CSR is anchored is an avatar.