Dynamic interaction between avatar attachments

Abstract

The present invention provides a method, storage medium, and computing system to support physical interaction between avatars. [Solution] A method for triggering an action in response to a collision between a first avatar and a second avatar, comprising: detecting a collision between a collider set on the first avatar and a receiver set on the second avatar; reporting the detected collision to the player that has been hit; updating parameters on the avatar associated with the receiver in response to the detected collision; triggering an action; determining whether the action is related to a permanent state change of the second avatar; and sending a state change notification to a remote instance of an application rendering the first and second avatars.

Description

Background Art

[0001] Users of computing systems are using avatars as a substitute for their physical presence in a variety of applications, ranging from simple chat applications to sophisticated three-dimensional (3D) environments used in video game applications and virtual reality applications. A simple version of an avatar can be the shape of the shoulders and head without any distinguishing features. Some avatars can be complex, associated with detailed graphics, textures, and capable of various animations. For example, some avatars include many parts that are animated separately for realistic and non-realistic movements, such as hair, tails, ears, clothing, etc.

[0002] Details of one or more aspects of the subject matter described in this disclosure are set forth in the accompanying drawings and the following description. However, the accompanying drawings illustrate only some exemplary aspects of this disclosure and should not be considered as limiting its scope. Other features, aspects, and advantages will become apparent from this specification, the drawings, and the claims.

Brief Description of the Drawings

[0003] [Figure 1] FIG. 1 shows an exemplary virtual world platform for playing and hosting a multiplayer virtual reality (VR) experience according to some aspects of the present technology.

[0004] [Figure 2] FIG. 2 shows an example of a quick menu according to some aspects of the present technology.

[0005] [Figure 3] FIG. 3 shows an exemplary method for triggering an action in response to a collision between a first avatar and a second avatar according to some aspects of the present technology.

[0006] [Figure 4] Figure 4 illustrates exemplary methods for supporting interactions that affect the secondary motion of parts of an avatar, according to several embodiments of the present technology.

[0007] [Figure 5A] Figure 5A illustrates an exemplary method for determining whether avatar contact interaction is permitted, according to several aspects of the present technology. [Figure 5B] Figure 5B illustrates an exemplary method for determining whether avatar contact interaction is permitted, according to several aspects of the present technology. [Figure 5C] Figure 5C illustrates an exemplary method for determining whether avatar contact interaction is permitted, according to several aspects of the present technology.

[0008] [Figure 6] Figure 6 illustrates an exemplary method, according to several aspects of the present technology, for determining whether there is mutual consent between a pair of avatars in order to allow supported contact interaction.

[0009] [Figure 7] Figure 7 shows exemplary contact settings and an exemplary table indicating whether or not contact interaction is permitted by those settings, according to several embodiments of the present technology.

[0010] [Figure 8] Figure 8 shows a portion of an avatar composed of one or more colliders according to several embodiments of this technology.

[0011] [Figure 9A] Figure 9A shows two avatars performing contact interaction according to several embodiments of this technology.

[0012] [Figure 9B]Figure 9B shows the moment immediately following a high-touch contact interaction in several embodiments of this technology.

[0013] [Figure 10] Figure 10 shows an avatar having a part configured as a collider and a part configured as a secondary motion movement, according to several embodiments of this technology.

[0014] [Figure 11] Figure 11 shows an exemplary interface for setting secondary motion attributes on parts of an avatar, according to several aspects of this technology.

[0015] [Figure 12] Figure 12 shows an example of a system for implementing one aspect of this technology. [Modes for carrying out the invention]

[0016] User interaction in virtual worlds, such as those hosted by several virtual reality platforms, continues to evolve. Initially, interaction was limited to coexisting in the same world and playing games together. Interaction progressed to live communication and eventually to participating in virtual events together. More recently, users have expanded the range of motion of their avatars, enabling more physical interactions in these virtual worlds. For example, it has become possible to exercise in virtual worlds or dance in nightclubs.

[0017] The next advance in human-to-human (albeit avatar) interaction in virtual worlds is physical interaction. That is, there has been a need in this field to support physical interaction between avatars. This technology addresses this problem and other related issues associated with contact-based interaction between avatars.

[0018] Previously, it was possible for parts of an avatar to come into contact with parts of another avatar, but this was no more than two objects in space being in close proximity. Each avatar occupied a volume of space and, although they could collide with each other, there were no interactions or reactions due to the contact. This technology can support an avatar that has received an interaction due to contact to react to that interaction. In some embodiments, the reaction to the interaction can be an animation, sound, or other effect. This technology can also support continuous interactions between parts of an avatar. For example, this technology can enable one avatar to ruffle the hair of another avatar.

[0019] This technology includes a software development kit for constructing an avatar in which the user can define parts of the avatar as colliders (objects that represent physical collision determination processing). In some embodiments, parts of the avatar, such as hands or other appendages, can be automatically considered as colliders. Also, in this technology, it is possible for the user to define parts of the avatar as receivers. A receiver is a part of the avatar that can trigger an animation, sound, or other effect when the receiver receives contact from a collider.

[0020] This technology also relates to a method of detecting a collision between a collider and a receiver and enabling the resulting effect. A collider defines the shape of an object for the purpose of a physical collision. Generally invisible, a collider does not need to be exactly the same shape as the object and, in fact, a rough approximation is often more efficient and indistinguishable in gameplay. In some examples, a collider does not need to behave as a solid object and simply allows other colliders to pass through it.

[0021] A receiver can be a collider with a trigger set to result in an effect. When an object enters the receiver's space, the receiver invokes a function on it to execute a script set for the receiver. The scripting system or physics engine can detect that a collision has occurred between the collider and the receiver and initiate an action.

[0022] This technology includes a software development kit for building avatars that allow users to define parts of the avatar to support continuous interaction. Some parts of the avatar are configured to have secondary motion, and such parts of the avatar can be manipulated by forces from a collider acting on the parts of the avatar configured to have secondary motion. As discussed herein, a collider on a part of an avatar (on the same avatar or a different avatar) can interact with the parts of the avatar configured to have secondary motion to cause movement of those parts.

[0023] Primary motion refers to explicit movements of an avatar caused by explicit inputs that drive the movement, such as the movement of limbs through explicit control to move the limbs, or movement through space where the volume of space occupied by the avatar is transformed into different coordinate positions in the virtual world. Secondary motion refers to movements caused by environmental forces, such as physical forces accompanying the movement of parts of the avatar, wind blowing, or forces applied by other avatars. These movements are generated by physical forces applied to parts of the avatar that are composed of secondary motion attributes as a result of primary motion. For example, as a result of the primary motion of walking, inertial forces and gravity are applied to the hair, causing the hair to bounce.

[0024] In addition to supporting interaction between avatars and their parts, this technology also solves other problems associated with supporting interaction between avatars. One of these is the issue of consent. Just because touch interaction is supported does not mean that the user wants their avatar to be touched. The essence of a virtual reality environment is that the user can connect closely with their avatar. Often, users choose to view the world from a first-person perspective, and as a result, an interaction in which one avatar touches another is perceived as a touch from a first-person perspective. Thus, just as some touches are unwelcome in the real world, others are unwelcome in the virtual world as well. Therefore, this technology provides a safety framework that declares the user's consent to touch and disables touch when it is not desired.

[0025] Another challenge this technology addresses is improving the efficiency of the processing required to support such contact interactions. This technology utilizes an efficient mechanism for detecting contact interactions. Since detecting overlapping volumes is a difficult problem, an efficient mechanism for this determination has been devised. Another area of ​​efficiency improvement is separating the secondary motion caused by contact interactions from the main thread used to render the virtual world, thereby more efficiently supporting the secondary motion of these objects.

[0026] These and other advantages of this technology are further described herein.

[0027] Figure 1 shows an exemplary virtual world platform 102 suitable for implementing this technology, for playing and hosting multiplayer virtual reality (VR) experiences. The virtual world platform 102 connects clients 104 via web services 110 and networking services 112, allowing them to socially interact together in the virtual world hosted by the virtual world platform 102.

[0028] The virtual world platform 102 primarily includes clients 104, which are instances of applications running on client devices 106. Clients 104 interact via network connectivity with web services 110, which support them by providing various services through one or more application programming interfaces (APIs). Some of the main services provided by web services 110 include support for the virtual world through the world API 128, user profiles through the user API 132, trust and security through the trust API 144, and complex avatars through the avatar API 136. Among other functions, web services 110 generally store and provide long-term state information.

[0029] Client 104 also interacts with Networking Service 112, which provides communication services between Client 104, Networking Service 112, and remote instances of Client 104 (not shown), and shares state information among the instances of Client 104. In particular, state information is received by Networking Service 112 from multiple instances of Client 104 when each instance of Client 104 controls its local player 116. Networking Service 112 can forward state information about each player to other instances of Client 104 when all of the local players 116 of each client instance are engaged in gameplay in the same virtual world. Networking Service 112 provides optimized packet routing through Optimized Packet Routing Service 140 and moderation between one or more clients through Moderation Service 142.

[0030] Client 104 is a runtime environment that runs on a specific client device 106. In this specification, client 104, local client, and remote client may all refer to instances of client 104 running on their respective client devices 106. A specific user account is logged into a particular instance of client 104. Local and remote clients are distinguished to explain how client 104 handles first-person input from a user on the client device 106 on which client 104 is running, and how a remote client handles third-person input received from another user operating the client device on which the remote client is running.

[0031] The client device 106 can be any computing device. While client 104 is particularly suited to providing an immersive virtual reality experience through interactions that require a VR headset to experience, client 104 can also run on computers and mobile devices. Some virtual worlds or complex avatars may not be configured to work well on certain device types, and therefore, while client 104 can run on many platforms and devices, not all virtual worlds or complex avatars are available or fully functional on all client devices 106.

[0032] The user interface service 108 is one of the services that are part of the client 104. The user interface service 108 is configured to provide various user interface elements, such as menus that display various user settings, available worlds, saved complex avatars, and friend lists. The user interface service 108 can populate its menus through interaction with one or more APIs provided by the web service 110, while the rest of the menus are loaded directly from the user interface service 108.

[0033] The user interface service 108 can provide a menu of available worlds by calling the World API 128 to obtain a list of worlds that the user account logged into client 104 is permitted to enter. The World API 128 can retrieve all public worlds from the World Asset Database 130 and send a list of them to client 104. Furthermore, the World API 128 can request the World ID of any private worlds associated with the user account logged into client 104, retrieve the private worlds from the World Asset Database 130, and send them to client 104. The user interface service 108 can receive user input via a hardware interface to navigate the world menu and receive the selection of worlds to visit.

[0034] Another user interface provided by user interface service 108 relates to various user settings. Such settings may relate to whether the human player is sitting or standing, settings to minimize motion sickness for players prone to motion sickness when playing in VR, settings for selecting complex avatars, and settings regarding how the player is seen in the virtual world and who sees the player.

[0035] One notable user interface feature provided by the user interface service 108 is the Trust and Safety menu. The user interface service 108 can contact the user API 132 to retrieve current trust and safety settings from the user profile database 134 and display these settings in the Trust and Safety menu. The Trust and Safety menu provides the user account with the ability to determine which remote players 124 can see the user's avatar (local player 116), or which can be seen by the user's avatar when both are in the same world. For example, it may be desirable to avoid interaction with a new user of the virtual world platform 102 because they have not yet established a trust relationship within the virtual world platform 102. It may also be desirable to restrict the functionality of a remote player's avatar as it is handled by the instance of client 104 to which the local user is logged in. This is because some avatars may have malicious data embedded in them, or they may be too complex to render without degrading the performance of the client device 106. For example, the user account may decide to turn off the lights of a remote avatar to avoid shaders, or not allow custom animations, etc. In some embodiments, each of these options may be set based on the degree of trust placed in the remote player. For example, a user account may allow a friend's avatar to have full functionality, while other user accounts may only see basic avatar functionality.

[0036] The user interface service 108 can also provide the option to mute or block specific remote players. Furthermore, the user interface service 108 can provide a panic mode that mutes non-friends both audibly and visually.

[0037] After the user selects a virtual world from a menu provided by the user interface service 108, the client 104 can download an instance of the virtual world by calling the world API 128, which can retrieve the virtual world from the worlds in the world asset database 130 and send it to the client 104 for execution.

[0038] World assets are large binary files built for game engines such as Unity using an editor with a software development kit (SDK) provided for use with the virtual world platform 102. When a user moves to a world, they need to download that world asset from the world asset database 130. If there are already people in an instance of that world, the client 104 also needs a list of those people's avatars so that they can be rendered in the virtual world instance.

[0039] In some embodiments, the functionality of World API 128 can verify that a user account has access to the requested world. A user account should only have the ability to view public worlds in the user interface menu, or only knowledge of the link to a world shared with the user account, but as a redundancy measure, World API 128 can verify that the user account is permitted to access the virtual world.

[0040] In addition to downloading a virtual world instance, client 104 can also establish a session with networking service 112 for a specific instance of the virtual world. Networking service 112 can provide information about the current state of the virtual world instance. For example, networking service 112 can provide client 104 with a list of remote avatars 126 present in the virtual world instance. Client 104 can then contact avatar API 136 to download a list of composite avatar assets for the remote composite avatars from avatar asset database 138.

[0041] If client 104 does not have an asset for local avatar 118, client 104 can also contact the avatar API 136 to request and receive a local avatar asset. An avatar asset is a single binary file containing all the textures, model and animation data necessary to render the avatar. In some cases, it may include more complex features, such as data related to particle systems and light sources, whether the avatar should follow or defy the established physical laws in the virtual world, or if the avatar has non-standard motion dynamics. In some embodiments, an avatar asset may include colliders and receivers defined for parts of the avatar, or a tree of transforms that cause parts of the avatar to exhibit secondary motion behavior (for example, dynamic bones or physical bones (aka phys.bones) are examples of systems that can be configured to cause parts of the avatar to exhibit secondary motion behavior).

[0042] The downloaded virtual world instance may be run by client 104 as the current world 120. The current world 120 may include the coordinates within the current world 120 in which the local player 116 and each remote player 124 are located. The local player 116 and remote player 124 are each collision volume of space occupied by the respective local player 116 or remote player 124.

[0043] Local avatars 118 can be mapped to local players 116, and each remote avatar 126 can be mapped to each remote player 124, thereby allowing each player to appear as their own avatar in the current world 120. The movement of the remote avatars 126 is handled by receiving state data about each remote avatar / player and rendering the movement or sound by the client 104.

[0044] The VR tracking service 114 relates to a client 104 that operates on a client device 106 that has access to VR tracking peripherals. For example, some VR headsets have cameras (integrated or external) for tracking the player's hands and feet. Many VR headsets can be paired with controllers that can report the position of the user's hands in space. Some client devices 106 also include other peripherals configured to perform full skeleton tracking. The VR tracking service 114 can merge all VR inputs connected to the client.

[0045] The VR tracking service 114 can map the fused VR input to the local player 116, allowing the local player 116 to interact within and with the current world 120. Meanwhile, the local player 116 can interact with the local avatar 118, mapping the local avatar 118 to the local player and displaying the local player 116 as its own avatar.

[0046] In some embodiments, the parts of the user's body tracked by the VR tracking service 114 vary. Some users may have full skeleton tracking, while many may only have the ability to perform hand tracking. To accommodate such differences in the hardware capabilities of possible client devices 106, the local player 116 can derive parts of the skeleton that are not tracked by the VR tracking service 114. For example, even if the VR tracking service 114 only provides information regarding the tracking of the user's hands, the local player can further derive the user's full skeleton and move parts of the skeleton to correspond to hand movements. In this way, the avatar's hands do not move in isolation from the rest of the avatar.

[0047] Local Player 116 is an entity that moves around the environment within the current World 120. It can pick up and place objects. It has no animation and is a collision volume. It can do anything in the world, but has no appearance and does not need to be animated.

[0048] The local player is further connected to the networking layer, which is referred to as the runtime networking service 122, and broadcasts status information about the local player 116 to other users in the current world 120 instance over the network.

[0049] Local player 116 and remote player 124 are similar in that they are collision volumes that move within the environment of the current world 120. The main difference is that local player 116 is controlled by client 104, and the user of client 104 is authoring the experience. In contrast, remote player 124 is a playback mechanism that represents actions broadcast to client 104, representing other players present in the current world 120.

[0050] As described above, the local avatar 118 is overlaid on the local player 116 to give the user a visual appearance. Actions by the local player 116 are animated as the local player interacts with the current world. For example, the local player 116 can interact to pick up an object in the current world 120, but without the local avatar 118, the object would appear to be floating in mid-air. When the local avatar 118 is overlaid on the local player 116, the object appears to be held by the avatar's hands.

[0051] The remote player 124 and remote avatar 126 operate similarly to the local player, except for the source of the input that controls the remote player 124. The remote player 124 and remote avatar 126 are playback devices for state information received by the runtime networking service 122 from the networking service 112. Figure 1 shows only one remote player 124 and remote avatar 126, but there may be many.

[0052] Client 104 can also support contact interactions between avatars, between parts of the same avatar and other parts of the same avatar, or between parts of an avatar and objects in the virtual world. To detect these interactions, client 104 may be configured to detect collisions between objects using a collision detection system 148. In some embodiments, the collision detection system 148 may be a broadband phase collision detection system.

[0053] Furthermore, the current World 120 has features that require a network. The current World 120 can have objects that users can pick up, such as scissors or light switches, and these objects need to broadcast their state over the network so that other users within the current World 120 can see the object's current state.

[0054] Local player 116, current world 120, and remote player 124 are each connected to the runtime networking service 122. Local player 116 primarily sends updated state information of local player 116 to a remote instance of client 104, which is also running the same virtual world. Current world 120 can send and receive state information about the virtual world instance. Current world, running on client 104, sends state information when the state change is owned by local player 116 and receives state information when the state change is owned by remote player 124.

[0055] The networking service 112 is the network-side portion of the networking layer of the virtual world platform 102. In some embodiments, part of the networking service 112 is provided by a networking plugin, such as the PHOTON networking engine, which broadcasts state information to all users within the virtual world instance.

[0056] In addition to general broadcasting of state information to all users interacting with virtual world instances, the optimized packet routing service 140 provides more advanced capabilities that deliver an enhanced user experience and implement other virtual world platform 102 features such as trusted and secure configurations.

[0057] For example, to provide an enhanced user experience, the optimized packet routing service 140 can filter out voice packets coming from remote players 124 that may be far away from the local player 116 in the current instance of world 120. Without such optimization, a remote player 124 that is not interacting with the local player or is not visible to the local player may receive voice packets from tens or hundreds of other remote players 124, making it difficult to communicate with any subset of remote players 124.

[0058] In another example, the optimized packet routing service 140 can implement trust and safety settings. As discussed above, trust and safety settings can specify certain user accounts or groups of user accounts that are filtered so that they cannot interact with the local player 116, or so that interaction with the local player 116 is restricted. The optimized packet routing service 140 can call the trust API 144 to find out a list of remote players 124 that may need to be subject to some level of filtering or blocking of network traffic going to or coming from the client 104 for the local player 116 that has trust and safety settings.

[0059] The Trust API 144 can determine which remote players 124 should be blocked for the local player 116, or which remote players 124 should have their complex avatar configurations restricted. Some of these decisions are based on logic and rules that classify remote players 124 based on the amount and type of past interactions with the virtual world platform 102. The Trust API 144 can make these decisions by using settings stored in the local player 116's user profile and comparing these settings with data stored in the remote player 124's user profile.

[0060] Another networking service 112 is a moderation service 142 that can provide conflict resolution and access control. For example, before a user can access a world, especially a private world, the moderation service 142 can call the world API 128 to ensure that the user can enter the world. In another example, two different users may try to claim control of an object in a virtual world at almost the same time. The moderation service 142 can handle such a type of conflict by selecting a specific user who will control the object until they relinquish control of it. The user who controls the object can broadcast a packet to the remote player 124 informing it of the object's state.

[0061] In some embodiments, the client 104, the virtual world, and the complex avatar can be configured to run on a specific game engine, particularly one that supports three-dimensional (3D) environments. Two common game engines include Unity and Unreal Engine.

[0062] In some embodiments, the virtual world and complex avatars must be developed in accordance with the Software Development Kit (SDK) in order to be supported by the virtual world platform 102. For example, a complex avatar may require specific scripts to be usable on the virtual world platform 102. In another example, there may be many requirements that must be followed in order to play the avatar's animations. In some embodiments, the SDK may define other details necessary to support a particular client device. For example, the SDK may define specific shaders to be used when the avatar is used with the OCULUS QUEST VR headset.

[0063] In some embodiments, the SDK requires that the virtual world utilize a specific coding language to ensure that the world has compliant behavior. For example, the SDK may require that behavior within the world be defined using UDON, a programming language specific to a particular virtual world platform 102, VRChat. In some embodiments, the programming language facilitates the world being built using the programming language to comply with file access protections provided by the virtual world platform 102. For example, the world may not be able to read or write anything to the hard drive, and only authorized web pages may be rendered in the world on the virtual world platform 102.

[0064] In some embodiments, the virtual world platform 102 may also include a simplified avatar service 146. As described herein, the simplified avatar service 146 can create simplified versions of complex avatars and store the avatar assets of these simplified versions of complex avatars in an avatar asset database 138.

[0065] While the virtual world platform 102 is suitable for implementing this technology, those skilled in the art will understand that this technology can also be used in other environments.

[0066] Figure 2 shows an exemplary quick menu 202 according to several embodiments of the present technology. In particular, the quick menu 202 can be displayed by the user interface service 108 on the client 104 at any time or place on the virtual world platform 102.

[0067] Quick Menu 202 includes a Quick Links section 204 containing many commonly used menu options, such as menus for browsing the world, avatars, and friends, and a Safety Menu 208 for configuring user profile security settings.

[0068] The Trust and Safety menu 208 provides the user account with the ability to determine which remote players 124 can see the user's avatar (local player 116) or which can see the user's avatar when both are in the same world. For example, it may be desirable to avoid interacting with newer users of the virtual world platform 102, as they have not yet established a trust relationship within the virtual world platform 102. It may also be desirable to restrict the functionality of a remote player's avatar as it is handled by the instance of client 104 to which the local user is logged in. This is because some avatars may have malicious data embedded in them, or they may be too complex to render without degrading the performance of the client device 106. For example, the user account may decide to turn off the lights on a remote avatar to avoid shaders, or not allow custom animations. In some embodiments, each of these options may be set based on how trusted the remote player is. For example, the user account may allow a friend's avatar to have full functionality, while others can only see basic avatar functionality.

[0069] The user interface service 108 can also provide the option to mute or block specific remote players. Furthermore, the user interface service 108 can provide a panic mode or safe mode 210 that allows for the audio and visual muting of individuals other than friends.

[0070] The quick menu 202 may also include a quick actions 206 section to provide frequently used actions in a convenient location. Some example quick actions include an action to move to the home world, an action to resume from the world you were last in, an action to select another user's avatar (for personal communication, to copy the avatar or other functions), and an interaction toggle 216 to turn interaction between the user and local player 116 on or off.

[0071] The Quick Menu 202 also includes the Dock 212, which provides access to several common functions, including the virtual camera, volume settings, and settings menu, among other features.

[0072] Throughout this description of the technology, we will refer to avatars, users, and user accounts. Those skilled in the art will understand that an avatar is a representation of a user in a virtual environment, and that configurations belonging to an avatar may also belong to the user account to which the avatar is applied. Therefore, the term avatar may, in some cases, describe a specific aspect of a user account. Regardless of which term is used, its appropriate meaning will be understood by those skilled in the art.

[0073] Figure 3 shows an exemplary method for triggering an action in response to a collision between a first avatar and a second avatar. The exemplary method shows a specific sequence of actions, but the sequence can be modified without departing from the scope of the disclosure. For example, some of the actions shown may be performed in parallel or in a different order that does not substantially affect the function of the method. In other examples, different components of an exemplary apparatus or system implementing the method may perform their functions substantially simultaneously or in a specific order.

[0074] As described above, this technology can support avatars that receive contact interaction in responding to that interaction. In some embodiments, the reaction to the interaction may be animation, sound, or other effects.

[0075] This technology includes a software development kit for building avatars that allows users to define parts of the avatar as colliders. In some embodiments, parts of the avatar, such as hands or parts of other accessories, may be automatically considered colliders. The technology also allows users to define parts of the avatar as receivers. Receivers are parts of the avatar that can trigger animations, sounds, or other effects when they receive contact from a collider. The technology also allows users to define parts of the avatar configured to exhibit secondary motion. Secondary motion can be triggered or affected by contact from a collider.

[0076] Furthermore, this technology also relates to a method for detecting collisions between a collider and a receiver and enabling the resulting effects, as described in the method shown in Figure 3.

[0077] According to some examples, the method includes detecting a collision between a collider configured on a first avatar and a receiver configured on a second avatar in block 302. For example, client 104 shown in Figure 1 can detect a collision between a collider configured on a first avatar and a receiver on a second avatar. The first avatar can be a local avatar 118 or a remote avatar 126. The second avatar can be a remote avatar 126. In other words, a collision can occur between a local avatar and one or more remote avatars, or between two or more remote avatars.

[0078] In some embodiments, as described in more detail with respect to Figures 5A and 5B, the collider and receiver may be turned on or off according to a set of rules governing mutual agreement regarding interaction and contact between avatars.

[0079] In some embodiments, collisions can be detected by a broadband phase collision detection system 148. For example, the broadband phase collision detection system 148 can be configured to divide a rendered area of ​​a virtual world into a grid. In one example, the grid can be a grid area covering a 10m x 10m area, but any suitable area can be used. Each cell in the grid is populated in a dictionary for quick lookup by a hash created from the XYZ coordinates in the grid space of each grid. Within each grid, the broadband phase collision detection system 148 creates a sorted list in a first-in, first-out memory structure of all objects arranged in order across the axes within the area in the grid. For example, objects may be arranged along the X axis so that they occur within the area in the grid. The broadband phase collision detection system 148 determines whether each object is involved in a collision by evaluating the objects one at a time in the sorted order. Evaluating an object may include determining whether the object is of a nature that is affected by collisions. For example, if an object is neither a collider nor a receiver, the collision may be irrelevant to that object, and processing of that object can be stopped. However, if an object is likely to be affected by a collision, the broadband phase collision detection system 148 determines whether the object may overlap with another object or is overlapping with another object.

[0080] In some embodiments, collision detection by client 104 may also include determining physical attributes associated with the collision. For example, when a collision is detected by the broadband phase collision detection system 148, client 104 can determine physical attributes associated with the collision. These physical attributes may include physical forces such as force, velocity, and mass of the colliding objects. In some embodiments, the action may depend on the physical attributes. For example, if the collision is the result of a high-five action, a sound effect may only be generated if the collider is moving at a speed above a threshold.

[0081] According to some embodiments, the method includes reporting the detected collision to the player that has been contacted in block 304. For example, a broadband phase collision detection system 148 running on client 104 shown in Figure 1 may report the detected collision to an avatar controller such as local player 116 or remote player 124 shown in Figure 1.

[0082] In some embodiments, the method includes updating parameters on the avatar associated with the receiver in block 306 in response to a detected collision. For example, an avatar controller such as the local player 116 or remote player 124 shown in Figure 1 can update parameters on the avatar associated with the receiver in response to a detected collision. For example, if the remote player 124 is the receiver of a contact interaction, the remote player 124 can update parameters on the remote avatar 126. In some embodiments, the parameters can be binary parameters indicating that a collision has occurred. In some embodiments, the parameters can describe attributes of the contact interaction, such as the type of collider, the physics of the collision (e.g., the velocity of one of the objects or the force of the collision).

[0083] A receiver can be linked to a relevant response that is executed when the receiver becomes active. The response can be materialized as data or an algorithm that is part of the avatar package. Non-exclusive examples of responses that can be associated with a receiver include playing an animation, playing a sound effect, or changing a state. For example, in a high-five interaction between two avatars, the receiver one avatar above could be configured to trigger a slap sound, animate a custom change or appearance change, or trigger any type of animation. Responses can also be triggered through updates to the avatar's parameters.

[0084] In some embodiments, mutual agreement between the parties to a collision may be confirmed after the collision is reported to the avatar controller (such as the local player 116 or the remote player 124) but before the parameter change is reported to the avatar (such as the local avatar 118 or the remote avatar 126).

[0085] In some examples, if there is mutual agreement, the method includes triggering an action in block 308. For example, client 104, shown in Figure 1, may trigger the action. In some embodiments, the action is triggered by an animation controller that animates the avatar (local avatar 118 or remote avatar 126) based on data and parameters associated with the avatar. Some non-exclusive examples or responses that may be associated with the receiver may include playing an animation, playing a sound effect, or causing a state change.

[0086] According to some examples, the method includes determining in the determination block 310 whether the action is related to a permanent state change of the second avatar. For example, client 104 shown in Figure 1 can determine whether the action is related to a permanent state change of the second avatar. A permanent state change can include any action beyond a played animation. For example, an avatar can change its appearance (persistently until changed by the player or another interaction, or for a set duration), and can continue to interact with its changed appearance.

[0087] According to some examples, the method includes sending a state change notification in block 314 to a remote instance of the application rendering the first and second avatars. For example, the client 104 shown in Figure 1 can send a state change notification to a remote instance of the application rendering the first and second avatars via the networking service 112.

[0088] Figure 4 illustrates an exemplary method for supporting interactions that affect the secondary motion of parts of an avatar. While the exemplary method depicts a specific sequence of actions, the sequence can be modified without departing from the scope of this disclosure. For example, some of the actions shown may be performed in parallel or in a different order that does not substantially affect the function of the method. In other examples, different components of an exemplary apparatus or system implementing this method may perform their functions substantially simultaneously or in a specific order.

[0089] According to several examples, this method involves instantiating one or more jobs as part of a job system. A job can be responsible for handling tasks such as collision evaluation and determining secondary motion actions as a result of collisions. The job system can execute its tasks by assigning jobs to one or more threads other than the primary thread used to render the larger game environment (virtual world). Jobs can be compiled at runtime to run on threads other than the primary thread. In some embodiments, job creation is performed using the BURST COMPILING feature of the UNITY rendering engine.

[0090] Job execution is handled by a job system, which assigns its own priority to the order in which jobs are executed. Therefore, in some embodiments, client 104 can check whether a job has been completed by the job system when a frame needs to be rendered. If the job is not completed, the method includes instructing the job system to terminate the job.

[0091] According to several examples, this method involves loading avatar parameters in block 402. For example, client 104, shown in Figure 1, can load parameters for an avatar (e.g., a remote or local avatar 118). As mentioned with respect to Figure 1, an avatar can be defined by an avatar asset. An avatar asset is a single binary file containing all the texture, model, and animation data necessary to render the avatar. In some examples, it can include more complex features such as data on particle systems and light sources, whether the avatar follows or defies established physical laws in the virtual world, and whether the avatar has non-standard motion dynamics. An avatar asset can also define parts of the avatar that are designated as colliders and receivers. An avatar asset can also define parts of the avatar that have secondary motion behavior set. An avatar asset can define the complete skeleton of a humanoid or non-humanoid avatar and can configure any part of the avatar as a collider or receiver. Furthermore, secondary motion behavior can be set for any part of the avatar. However, secondary motion is typically used only for the flexible or pliable parts of an avatar, and is not usually used for rigid objects like the main skeleton of an avatar, as rigid objects are less likely to respond to small forces, such as most contact interactions, with perceptible motion.

[0092] The parts of the avatar configured for secondary motion are defined by a transform tree. For example, the root of the transform could be the avatar's head, and branches from the root could include strands of hair (or collections of strands of hair). A strand of hair can be represented by several additional branches. Each branch can be associated with various properties of the part of the avatar associated with the transform tree, such as whether it is pulled, whether it has spring-like properties, how susceptible it is to inertial forces, and how much it should be affected by gravity. In some embodiments, the transform is configured to be compiled at runtime. Further details regarding the transform tree that defines the parts of the avatar that exhibit secondary motion are illustrated with reference to Figures 10 and 11.

[0093] According to some examples, the method includes storing in memory the parameters of an avatar, including parts of the avatar configured to exhibit secondary motion, in block 404. For example, the client 104 shown in Figure 1 may store the parameters of the avatar parts in memory accessible by the job system.

[0094] In some embodiments, a memory structure that stores information about transforms defining parts of an avatar that exhibit secondary motion is stored in a memory structure accessible by threads controlled by a job system running on multiple cores of a multicore processor. In some embodiments, the memory structure is a flat memory structure such as the NATIVE CONTAINER provided by UNITY. The NATIVE CONTAINER allows access to the data by secondary threads that execute jobs and a main thread responsible for rendering the virtual world and the objects within it.

[0095] According to some examples, the method includes detecting in block 406 that the avatar has an active contact acceptor configured to accept contact. For example, client 104 shown in Figure 1 can detect that the avatar has an active contact acceptor configured to accept contact.

[0096] In some embodiments, the contact acceptor is configured to accept interactions only from a specified collider. The specified collider may be a class of colliders, such as finger or hand colliders. The specified collider may be on a specific avatar, or it may be on a category of avatars, such as a humanoid avatar.

[0097] According to some examples, the method includes detecting an interaction between a collider and a portion of an avatar configured to exhibit secondary motion in block 408. For example, client 104 shown in Figure 1 may detect an interaction between a collider and a portion of an avatar configured to exhibit secondary motion.

[0098] In some embodiments, the detection of interaction between the collider and the portion of the avatar configured to exhibit secondary motion is performed frame by frame. The detection of interaction between the collider and the portion of the avatar configured to exhibit secondary motion may be performed by a broadband phase collision detection system 148, as discussed in relation to Figure 3. The broadband phase collision detection system may also be processed by jobs under the control of a job system. The collision job only determines an approximation of the collision and is not guaranteed to affect the secondary motion. Collisions that may have been detected by the collision job can be passed to a secondary motion job, which actually determines whether the collider is actually in contact with the portion of the avatar configured to exhibit secondary motion and whether it needs to move as a result. This is for efficiency reasons, as collision data is also needed for motion calculations, and it is faster to have all the collision data inside the secondary motion job.

[0099] In some examples, when an avatar is manipulated to move by a collider according to a set secondary motion, before animating the motion of the part of the avatar configured to show the secondary motion, this method includes determining in determination block 410 whether there is mutual agreement between the pair of first and second avatars to allow the animated motion. For example, client 104 shown in Figure 1 can determine whether there is mutual agreement between the pair of first and second avatars to allow the animated motion. Further details regarding mutual agreement are described with respect to Figures 5A and 5B. If there is no mutual agreement between the avatars, the method terminates in 412.

[0100] According to some examples, if there is mutual agreement between avatars, the method includes reporting the detected interaction to the avatar controller in block 414. For example, the broadband phase collision detection system 148 may report the detected interaction to an avatar controller such as the local player 116 or the remote player 124.

[0101] In some examples, this method involves determining in block 416 that an interaction between a collider and a part of the avatar configured to exhibit secondary motion triggers a physical simulation of the transform tree. For example, client 104, shown in Figure 1, can determine that an interaction between a collider and a part of the avatar configured to exhibit secondary motion triggers a physical simulation of the transform.

[0102] According to some examples, this method includes determining in the determination block 418 whether the interaction is a grab interaction. For example, the client 104 shown in Figure 1 can determine whether the interaction is a grab interaction. A grab interaction can occur when a part of the avatar is designated as grabbing.

[0103] If the interaction is a grab, according to some examples, this method involves assigning control to the grabbed part of the avatar in block 420. For example, client 104, shown in Figure 1, can assign control to the grabbed part of the avatar. The grabbed part of the avatar has an attachment point at the location where the avatar part was grabbed. Information reporting that a grab has occurred is also sent to a remote instance of client 104 via the network. Further details regarding grab interactions are discussed with respect to Figure 10.

[0104] According to several examples, this method involves animating the motion of parts of an avatar that are manipulated by a collider to move according to a configured secondary motion in block 422. For example, client 104 shown in Figure 1 can animate the motion of parts of an avatar that are manipulated by a collider to move according to a configured secondary motion (composed of a transform tree). Job execution utilizes local physics. Local physics is limited to the interaction between the collider and the properties of the transform tree and does not affect other objects in the virtual world. As described above, the job runs on a thread other than the main thread and results in the animation of the movement of parts of the avatar when manipulated by a collider to move according to a configured secondary motion.

[0105] In some embodiments, a portion of an avatar configured to exhibit secondary motion can remain pinned as a result of operation by a collider. According to some examples, the method includes determining in a determination block 424 whether the portion of the avatar was pinned. For example, the client 104 shown in Figure 1 can determine whether the portion of the avatar remained pinned. A portion of an avatar configured to exhibit secondary motion can remain pinned when an avatar having a collider presses a trigger input to pin the portion of the avatar.

[0106] According to some examples, the method includes sending a state change notification, along with information about the state change, to a remote instance of the application rendering the first and second avatars in block 428. For example, client 104 shown in Figure 1 can send a state change notification, along with information about the state change, to a remote instance of the application rendering the first and second avatars. For example, the information about the state change may be information about the pinning status of a part of the avatar, or information about whether a part of the avatar has been grabbed and which avatar is controlling that part.

[0107] According to some examples, this method includes restoring the avatar portion to its original state if it is determined that the avatar portion is not pinned in block 426. For example, client 104 shown in Figure 1 can restore the avatar portion to its original state when it is determined that the avatar portion is not pinned.

[0108] While Figure 4 has been described in the context of a first avatar interacting with a second avatar, the manipulation of parts of an avatar configured to exhibit secondary motion movements may originate from the same avatar. In some embodiments, an avatar may wish to use its hands to manipulate its hair, tail, ears, clothing, etc. All embodiments described with respect to Figure 4 function similarly when parts of an avatar configured to exhibit secondary motion movements are manipulated through interaction with itself or interaction between avatars, except that mutual consent is not required in the case of interaction with itself.

[0109] Figures 5A, 5B, and 5C illustrate an exemplary method for determining whether avatar contact interaction is permitted. While the exemplary method illustrates a specific sequence of operations, the sequence can be modified without departing from the scope of this disclosure. For example, some of the operations shown may be performed in parallel or in a different order that does not substantially affect the functionality of the method. In other examples, different components of an exemplary apparatus or system implementing the method may perform their functions substantially simultaneously or in a specific order.

[0110] This technology is designed to support interactions between avatars or parts of avatars. It also provides a mechanism to ensure that both participants in an interaction consent to it. The fact that contact interactions are supported by avatars does not mean that users want their avatars to be touched. The nature of the virtual reality environment is that users are closely tied to their avatars. Since users often choose to view the world from a first-person perspective, an interaction where one avatar touches another may be perceived as a first-person contact. For the user, this contact may be perceived in the same way as in real life. Just as there are unwanted contacts in the real world, there are also unwanted contacts in the virtual world. Therefore, this technology provides a safe framework for declaring user consent to contact and for disabling contact if it is unwanted. Importantly, consent must be obtained from all parties involved in the contact.

[0111] According to some examples, the method includes receiving avatar contact settings for a first user and at least one second user in a world instance in block 502. For example, client 104 shown in Figure 1 can receive avatar contact settings for a first user and at least one second user in a world instance.

[0112] Avatar contact settings include contact categories. All players use contact categories to configure in their user profile whether or not to allow contact. The content categories are: (1) Allow avatar contact interactions with all avatars, (2) Allow avatar contact interactions only with avatars in the friends list, and (3) Do not allow any avatar contact interactions.

[0113] Avatar contact settings also include allow and block lists to specify certain users / avatars that are excluded from any determinations made due to contact categories. For example, a user on the local user allow list is definitively allowed to interact with the local user's avatar if the remote user's settings allow that interaction. Similarly, a user on the local user block list is definitively not allowed to interact with the local user's avatar, even if the contact category normally allows interaction. The allow and block lists for specified avatars override the contact category.

[0114] Regardless of any contact settings configured for a user account, the user account can also use the interaction toggle 216 shown in Figure 2 to turn interactions with all other avatars on or off. Therefore, even a user account with settings to interact with all other accounts or all friends can use the interaction toggle 216 to quickly turn off contact interactions. The interaction toggle 216 can override any other contact settings associated with the user account to turn off interactions, but if the interaction toggle 216 is set to allow contact interactions, the allowed interactions will be limited by the interactions configured for the user account.

[0115] In some examples, this method includes determining in the determination block 504 whether there is mutual consent between a pair of avatars to allow avatar contact interaction. For example, client 104 shown in Figure 1 can determine whether there is mutual consent between a pair of users to allow avatar contact interaction. The determination of whether mutual consent exists is updated each time a user joins or leaves the world, or each time a user in the world changes their avatar settings or contact interaction settings. In some embodiments, the determination of whether mutual consent exists is performed without considering whether an interaction is set up for the avatars. Users can change their avatars at any time, but the consent remains the same until the determination of mutual consent is updated by the user leaving or joining the world.

[0116] The determination of whether mutual consent exists is the product of the combinations of contact settings for the user pair. Figure 6 shows an exemplary method for determining whether mutual consent exists between users in a pair to allow a supported contact interaction. This method first determines in determination block 602 whether the first user in the pair allows contact with the second user in the pair. Next, in determination block 604, the method determines whether the second user in the pair allows contact with the first user. Only if the answers to both determination block 602 and determination block 604 are yes, is the contact interaction allowed in block 606. If the answer to either determination block 602 or determination block 604 is no, the contact interaction is not allowed in block 608. While Figure 6 (and much of the discussion related to Figures 5A, 5B, and 5C) concerns pairs of interacting users, it should be understood that this can be extended to many users who can participate in a particular contact interaction. If any user who is supposed to be part of a contact interaction does not allow contact interaction with the other parties to the interaction, the group of users cannot participate in that contact interaction together.

[0117] In some examples, the method includes determining in the determination block 506 whether either avatar in a pair of avatars is configured with a receiver associated with an avatar contact interaction. For example, the client 104 shown in Figure 1 can determine whether either avatar in a pair of avatars is configured with a receiver associated with an avatar contact interaction. This step is performed by the client 104 for all pairs of avatars in the local world. The purpose of this step is to identify all pairs of avatars that can interact. In some embodiments, for efficiency reasons, this step may be performed only for avatars that are actually rendered by the client 104 in the world instance, since the client 104 does not render animations of avatars in the world that are not rendered in its field of view. In the determination block 506, if it is determined that neither avatar in the pair of avatars has a receiver or part of the avatar configured to show secondary motion, then neither avatar has a way to receive contact interaction, and therefore, in block 508, the client 104 can determine that there is no contact interaction between the pair of avatars.

[0118] In effect, the determination block 506 is used to determine whether one of the avatars in the avatar pair supports touch interaction.

[0119] As described above, with respect to Figure 3, client 104 is responsible for locally detecting and animating avatar interactions. Therefore, client 104 cannot control the inputs it receives in relation to the remote avatar, but it is responsible for determining whether any animation or effect should be played for the remote avatar due to interactions between two remote avatars or between local avatar 118 and remote avatar 126.

[0120] Figure 7 shows exemplary contact settings and an exemplary table indicating whether or not contact interaction is permitted by those settings.

[0121] In line 702, both users have their contact category set to allow all interactions, and therefore both users allow all interactions with others, so it is irrelevant whether that user is considered a friend or not. Contact is permitted.

[0122] In line 704, one user allows contact interactions only with friends, while the other user allows interactions with all users. Since the user is not a friend (for example, not on the user account's friends list), interaction is not allowed. However, in line 706, even with the same user's contact category settings, contact interactions are allowed because the user is a friend.

[0123] In line 708, one of the users has not allowed contact interaction, so the settings of the other users are irrelevant. Contact interaction is not allowed.

[0124] In line 710, the first user allows contact interaction with any user other than the user account associated with the second avatar. Therefore, since the first user does not allow contact interaction with the second user, contact is not permitted.

[0125] In line 712, the first user does not allow contact interaction with any user other than the user account associated with the second avatar. The second avatar allows all interactions. Therefore, since both avatars allow contact interaction with each other, contact is permitted.

[0126] In line 714, the first user does not permit contact interaction with any user other than the user account associated with the second avatar. The second user does not permit contact interaction with any avatar other than the user account associated with the first avatar. Therefore, since both users permit contact interaction with each other, contact is permitted.

[0127] Returning to the discussion in Figure 5A, we have so far described that the determination of whether contact interaction is permitted between specific users is made by client 104. However, in some embodiments, the determination of whether there is mutual consent between a pair of users to permit avatar contact interaction can be made by a network service such as moderation service 142 or another service.

[0128] In some embodiments, when pairs of avatars that do not agree to interact with each other are within a threshold distance of each other, an invisible boundary can be created to ensure that no contact interaction is even attempted. In some embodiments, remote avatars that are not permitted to interact can be removed from the view of the local player in the scene when the remote avatar approaches the threshold distance.

[0129] According to some examples, the method includes storing in block 510 whether contact interaction is permitted between individual pairs of avatars in a world instance. For example, client 104 shown in Figure 1 may store whether contact interaction is permitted between individual pairs of avatars in a world instance. For example, once a determination is made as to whether contact interaction is permitted between any pair of avatars in a world instance, this can be recorded in a table and stored for later determination and use in block 512.

[0130] In some examples, the method includes, in block 512, displaying an indicator associated with at least one remote avatar that indicates the avatar contact interaction status, showing whether avatar contact interaction is permitted between the local avatar and the remote avatar associated with the indicator. For example, client 104 shown in Figure 1 may display an indicator associated with at least one remote avatar that indicates the avatar contact interaction status. In some embodiments, it may be useful for a local avatar 118 to identify a remote avatar 126 that can interact with the user associated with the local avatar. For example, without any indication, a user controlling the local avatar 118 might wander around trying to participate in a contact interaction with a remote avatar that does not support contact interaction or does not allow contact interaction with the local avatar. This could degrade the user experience. Therefore, remote avatars that support contact interaction and allow the local avatar 118 to participate in contact interaction can be identified by the user associated with the local avatar 118. The indicator may be a symbol or color of the nameplate associated with the remote avatar 126. The indicator may highlight or otherwise indicate the position of the receiver on the remote avatar when the remote avatar 126 allows contact interaction with the local avatar 118. In some embodiments, the indicator associated with the remote avatar 126 may also indicate that avatar contact interaction is not permitted.

[0131] In some examples, the method includes detecting a collision between a collider configured on a first avatar and a receiver on a second avatar in block 514. For example, client 104 shown in Figure 1 can detect a collision between a collider configured on a first avatar and a receiver on a second avatar. The collision can be detected by a broadband phase collision detection system 148, similar to the description given for block 302 in Figure 3.

[0132] According to some examples, the method includes reporting detected collisions to the avatar controller in block 516. For example, client 104 shown in Figure 1 can report detected collisions to the avatar controller.

[0133] This method continues in block 518 of Figure 5B.

[0134] According to some examples, the method includes detecting a collision between a collider set on a local avatar and a receiver on a remote avatar in block 522, and then confirming that there is mutual agreement between the user pair. For example, client 104 shown in Figure 1 can detect a collision between a collider set on a local avatar and a receiver on a remote avatar, and then confirm that there is mutual agreement between the user pair. Although mutual agreement has already been determined in determination block 504, in some embodiments, client 104 may confirm that mutual agreement still exists before triggering an action.

[0135] According to some examples, if there is no mutual agreement between the user pair, the method includes terminating the process related to the avatar contact interaction in block 532. For example, client 104 shown in Figure 1 may terminate the process related to the avatar contact interaction.

[0136] In some embodiments, when pairs of avatars that do not agree to interact with each other are within a threshold distance of each other, an invisible boundary can be created to ensure that no contact interaction is even attempted. In some embodiments, remote avatars that are not permitted to interact can be removed from the view of the local player in the scene when the remote avatar approaches the threshold distance.

[0137] In some cases, user settings can also regulate what types of animations a user wishes to engage with. For example, a user might want to interact with other avatars in a touch interaction, but might want to filter out inappropriate or suggestive content. In such embodiments, animations preferred by the recipient may be labeled with a content flag. This is another way to place user rights, privacy, and boundaries under the control of the user receiving the content.

[0138] According to some examples, the method includes determining in block 524 that an animation associated with an avatar contact interaction is labeled with a content flag. For example, client 104, shown in Figure 1, can determine that an animation associated with an avatar contact interaction is labeled with a content flag.

[0139] According to some examples, the method includes determining in block 526 whether the user account associated with the local avatar is associated with a setting that filters content by content flags. For example, client 104 shown in Figure 1 can determine that the user account is associated with a setting that filters content by content flags.

[0140] According to some examples, this method includes terminating the avatar contact interaction in block 528 because it has been labeled with filtered content. For example, client 104, shown in Figure 1, can terminate the avatar contact interaction because it has been labeled with filtered content.

[0141] According to some examples, if touch interaction is permitted and the animation resulting from the touch interaction is not filtered due to the presence of a content flag, the method includes triggering an action in block 530. For example, client 104, shown in Figure 1, may trigger an action by playing an animation preferred by the recipient, or by performing a transform associated with a part of the avatar configured to show secondary motion.

[0142] After receiving the avatar settings in block 502 of Figure 5A, the method proceeds to block 520 and then to Figure 5C, where it shows alternative and / or additional methods for processing content labeled with a content flag.

[0143] According to some examples, the method includes determining in block 534 that the remote avatar associated with the avatar contact interaction is labeled with a content flag. For example, client 104 shown in Figure 1 can determine that the remote avatar associated with the avatar contact interaction is labeled with a content flag.

[0144] According to some examples, the method includes determining in block 536 that the local avatar is associated with a setting that filters content by content flags. For example, client 104 shown in Figure 1 can determine that the local avatar is associated with a setting that filters content by content flags.

[0145] In some examples, the method includes downloading an alternative remote avatar not associated with a content flag in block 538. For example, client 104, shown in Figure 1, can download an alternative remote avatar not associated with a content flag by interacting with the avatar API 136 to request an alternative asset. Alternatively, in some embodiments, certain content within an avatar asset labeled with a content flag may not be downloaded in its entirety, except for the portion associated with the content flag, along with the rest of the remote avatar and its functionality.

[0146] Figure 8 shows a portion of an avatar composed of one or more colliders. This technology includes a software development kit for building avatars in which users can define portions of the avatar as colliders and receivers.

[0147] In some embodiments, several parts of an avatar may be automatically considered colliders. The technology also allows the user to define parts of the avatar as receivers. Any part of an avatar, including parts of humanoid and non-humanoid avatars, can be defined as a collider or a receiver.

[0148] Colliders define the shape of an object for the purpose of physical collision. Colliders, which are generally invisible, do not need to be exactly the same shape as the object; in fact, in gameplay, a rough approximation is often more efficient and indistinguishable. In some cases, colliders do not need to behave as solid objects, but simply allow other colliders to pass through them. A receiver can be a collider composed of triggers that result in an effect. When a collider enters its space, the triggers associated with the receiver call a function that executes a script set up for the receiver. The scripting system or physics engine can detect when a collision occurs between a collider and a receiver and initiate an action. For example, a receiver can trigger an animation, sound, or other effect when it receives contact from a collider.

[0149] In some embodiments, the receiver is associated with a tag that restricts the type of collider or collider that can interact with the receiver. In such embodiments, the animation can only be triggered by contact from a collider that matches the tag specified by the receiver.

[0150] For example, Figure 8 shows an avatar hand with colliders 802a, 802b, 802c, and 802d on the fingers and collider 802e on the palm. The colliders are configured to interact with other parts of the avatar, which are composed of receivers, or secondary motion attributes that respond to forces applied by the colliders.

[0151] Figure 9A shows two avatars involved in a contact interaction. More specifically, the two avatars are high-fiving, with the hand 902 of the first avatar making contact with the hand 904 of the second avatar. Both hands may be composed of colliders, but at least one hand is composed of a receiver.

[0152] Figure 9B shows the moment immediately following a high-five contact interaction. The hand 906 consists of a receiver linked to an effect that draws an animation of a percussive bubble 908 and plays a slap sound.

[0153] Figure 10 shows an avatar having parts configured as colliders and parts configured as secondary motion movements. For example, the avatar has a hand 1020 configured as a collider 1008 and a hand 1022 configured as a collider 1002. The avatar also has ears configured as secondary motion movements. The secondary motion movements are provided by a bone tree, and each bone in the bone tree may be linked to a transform, thus creating a tree of transforms. For example, the avatar as a tree deforms to form its ears. At the root of the transforms is the head 1018, followed by a first bone 1016, a second bone 1014, and a third bone 1012. Each of bones 1016, 1014, and 1012 is composed of one or more transforms that provide the ears with properties that allow them to bend or bend and to respond to forces applied by colliders, inertia, or gravity, etc.

[0154] The ears and hands of the avatar shown in Figure 10 are also composed of attachment points in addition to the transform tree. For example, as shown in Figure 10, hand 1020 has attachment point 1006, hand 1022 has attachment point 1004, and the avatar's right ear has attachment point 1010. Attachment points can be used as positions from which objects can be grasped. In Figure 9, the avatar has a shoe hand 1020 for grasping attachment point 1010.

[0155] The avatar shown in Figure 10 has space between hand 1020 and attachment point 1010, but hand 1020 is grasping the ear via attachment point 1010. This space may be a result of the user manipulating the avatar moving the avatar's hand further than it is set to move. This space may also be a result of animation delay, where the user grasped the ear with the attachment point the moment the hand overlapped the ear, but did not trigger the attachment until the hand had moved some distance.

[0156] Regardless of this description, it may not be necessary for one attachment point to overlap another in order to grasp an object. In some embodiments, attachment between attachment points may be based on relative proximity, and it may not be necessary for a hand, such as hand 920, to be directly above the ear being grasped by attachment point 1010.

[0157] When the ear is grabbed by attachment point 1010, the avatar can use its hands to move the ear into various poses, providing an effect similar to what could happen in real life. Once the avatar has finished manipulating the ear with attachment point 1010, it can open its hands and release the ear, in which case the ear will return to its default position, or the user controlling the avatar can press the trigger button to pin the ear, leaving it in the position it was in just before releasing the grab.

[0158] Figure 10 shows an example of an avatar using its own hands to manipulate its own ears, but this is for illustrative purposes only. It is equally possible for another avatar to use its own avatar's attachment points to attach and grasp the ears at attachment point 1010, as described herein.

[0159] Ears with secondary motion enabled can also be manipulated by pushing or pulling. Avatars can use colliders to apply force to the ears, which react based on attributes associated with the parts of the avatar that are set to exhibit secondary motion. In this way, avatars can move hair, ears, tails, clothing, or the same features of other avatars. Avatars can also comb their own hair or the hair of other avatars.

[0160] Figure 10 shows how the avatar's head (ears) is composed of secondary motion, but this is just one example. Secondary motion can be set for any part. An avatar can contain a complete skeleton of a humanoid or non-humanoid avatar, and various controllers on the user can be mapped to the skeleton of the humanoid or non-humanoid avatar to make the skeleton perform primary motion. Furthermore, secondary motion can be set for any part of the avatar. However, secondary motion is typically provided for the flexible or pliable parts of the avatar, and is not usually used for rigid objects such as the primary skeleton of an avatar, as rigid objects are less likely to respond with perceptible movement in response to small forces such as most contact interactions. Common examples of parts of an avatar configured to exhibit secondary motion include hair, ears, tail, clothing, skin, and accessories such as jewelry.

[0161] Figure 11 shows an example interface for setting secondary motion attributes on a part of an avatar. In this example, the secondary motion is applied to the hair. This interface includes a collapsed transform tree 1102 for the hair. This transform tree has its base on the avatar's head, and any further bones that make up the hair are collapsed under the term "HairBase".

[0162] The menu shown in Figure 11 also allows the user to set parameters related to these forces to define how the bones that make up the hair should react to various forces. For example, a pull force 1104 may be configured to define how the hair should react when pulled from the attachment point. A spring force 1106 defines how quickly the hair should return to its original position after being pulled. The pull could come from the avatar grasping the hair or from another force such as gravity while the avatar is walking. Gravity 1108 defines the effect of how much the hair reacts to gravity. Elastic hair may be slightly less affected by gravity than heavy, long hair. These forces and other forces can be configured and adjusted to provide the desired motion dynamics to mimic real hair.

[0163] Figure 11 shows the secondary motion set for hair, but secondary motion can be set for any part of the avatar.

[0164] While this technology has described contact interactions between avatars, it can also be applied to interactions between avatars and the environment in which they interact. For example, a part of a world, or an object within a world, can be configured using colliders and receivers to exhibit secondary motion. For instance, a user can control an avatar to kick a ball; in this case, the avatar's feet are composed of colliders, and the ball is also composed of colliders and / or receivers. In another example, when a user walks across a grassy field, the grass, configured to exhibit secondary motion, can bend and move in response to the avatar's movements as the avatar walks across the field or wags its tail in the grass. In yet another example, a user could have trackers on each finger of their avatar, allowing for sufficient tracking of individual finger movements, and using individual colliders on the fingers to collide with keys on a virtual keyboard, enabling them to play a keyboard or piano.

[0165] Similar to avatar-to-avatar contact interactions, a world or objects within a world can be configured with interaction permissions so that a user account can interact with the interactable parts of the world or objects within a world only if there is mutual consent for interaction.

[0166] Therefore, although this technology has been primarily described in relation to avatar-to-avatar interaction, it is equally applicable when one or both avatars are replaced by an object or part of the world.

[0167] Figure 12 shows an example of a computing system 1200, which could be any computing device constituting a client device 106, or a web service 110, or any of those components of the system communicating with each other using connection 1202. Connection 1202 can be a physical connection via a bus, or a direct connection to a processor 1204, such as in a chipset architecture. Connection 1202 may also be a virtual connection, a network connection, or a logical connection.

[0168] In some embodiments, the computing system 1200 is a distributed system in which the functions described herein can be distributed across a data center, a plurality of data centers, a peer network, etc. In some embodiments, one or more of the system components described represent a number of such components, each performing some or all of the functions described. In some embodiments, the components may be physical or virtual devices.

[0169] An exemplary computing system 1200 includes at least one processing unit (CPU or processor) 1204 and a connection 1202 that connects various system components to the processor 1204, including system memory 1208 such as read-only memory (ROM) 1210 and random access memory (RAM) 1212. The computing system 1200 may include a cache of high-speed memory 1206 that is directly connected to the processor 1204, connected in close proximity to the processor 1204, or integrated as part of the processor 1204.

[0170] The processor 1204 may include an arbitrary general-purpose processor, hardware or software services such as services 1216, 1218, and 1220 stored in the memory device 1214 and configured to control the processor 1204, and application-specific processors in which software instructions are incorporated into the actual processor design. The processor 1204 may be a fully self-contained computing system that includes multiple cores or processors, buses, memory controllers, caches, etc. The multicore processor may be symmetric or asymmetric.

[0171] To enable interaction with the user, the computing system 1200 includes an input device 1226 which can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, a keyboard, a mouse, motion input, or speech. The computing system 1200 may also include an output device 1222 which may be one or more of a large number of output mechanisms known to those skilled in the art. In some examples, a multimodal system may allow the user to provide multiple types of input / output for communication with the computing system 1200. The computing system 1200 may generally include a communication interface 1224 which can control and manage user inputs and system outputs. There are no restrictions on operating in any particular hardware configuration, and therefore the basic functions here can be easily replaced by improved hardware or firmware configurations as they are developed.

[0172] The storage device 1214 may be a non-volatile memory device, or it may be another type of computer-readable medium capable of storing computer-accessible data, such as a hard disk, magnetic cassette, flash memory card, solid-state memory device, digital versatile disk, cartridge, random access memory (RAM), read-only memory (ROM), and / or some combination of these devices.

[0173] The storage device 1214 may include software services, servers, services, etc., and when code defining such software is executed by the processor 1204, it causes the system to perform functions. In some embodiments, a hardware service that performs a particular function may include software components stored on a computer-readable medium connected to the hardware components necessary to perform that function, such as the processor 1204, connection 1202, output device 1222, etc.

[0174] To clarify the explanation, in some cases, this technology may be presented as including individual functional blocks that include steps or routines in the way they are embodied in devices, components, or software, or functional blocks that include combinations of hardware and software.

[0175] Any of the steps, operations, functions, or processes described herein can be performed or implemented, alone or in combination with other devices, by hardware and software services or combinations of services. In some embodiments, a service may be software that resides in the memory of one or more servers of a client device and / or content management system, and performs one or more functions when a processor runs the software associated with the service. In some embodiments, a service may be a program or collection of programs that performs a particular function. In some embodiments, a service may be considered a server. Memory may be a non-temporary computer-readable medium.

[0176] In some embodiments, computer-readable storage devices, media, and memory may include cable signals or wireless signals, such as bitstreams. However, non-transient computer-readable storage media, as referred to, explicitly exclude media such as energy, carrier signals, electromagnetic waves, and signals themselves.

[0177] The methods described above can be implemented using computer-executable instructions stored from or otherwise available on a computer-readable medium. Such instructions may include, for example, instructions and data that cause a general-purpose computer, a purpose-specific computer, or a purpose-specific processing device to perform or otherwise constitute a particular function or set of functions. Some of the computer resources used may be accessible via a network. Executable computer instructions may be, for example, binaries, intermediate format instructions such as assembly language, firmware, or source code. Examples of computer-readable media that may be used to store instructions, information used, and / or information created in the methods described include magnetic disks or optical disks, solid-state memory devices, flash memory, USB devices with non-volatile memory, and networked storage devices.

[0178] Devices implementing the methods described herein may comprise hardware, firmware, and / or software and may take on any of a variety of form factors. Typical examples of such form factors include servers, laptops, smartphones, small form factor personal computers, and personal digital assistants. The functions described herein may also be embodied in peripherals or add-in cards. Such functions may also, as a further example, be implemented on a circuit board across different chips or different processes running within a single device.

[0179] Instructions, a medium for transmitting such instructions, computing resources for executing them, and other configurations for supporting such computing resources are means for providing the functions described in these disclosures.

[0180] While various examples and other information have been used to illustrate aspects of the appended claims, it should not be suggested that the claims be limited based on specific features or configurations in such examples, as those skilled in the art can derive a wide variety of implementations from these examples. Furthermore, while some subject matter may have been described in language specific to examples of structural features and / or method steps, it should be understood that the subject matter defined in the appended claims is not necessarily limited to these described features or operations. For example, such functions may be distributed or performed differently in components other than those identified herein. Rather, the described features and steps are disclosed as examples of components of the systems and methods of the appended claims.

[0181] Embodiment 1. A method for triggering an action in response to a collision between a first avatar and a second avatar, comprising: detecting a collision between a collider set on the first avatar and a receiver set on the second avatar; reporting the detected collision to an avatar controller; determining an action of the second avatar associated with the receiver; and triggering the action.

[0182] Embodiment 2. The method of Embodiment 1, wherein the collision is detected by a local instance of an application rendering the first avatar and the second avatar, and the action is triggered by the local instance of the application.

[0183] Embodiment 3. The method of any one embodiment from 1 to 2, further comprising determining whether the action relates to a permanent state change of the second avatar, and, if it is determined that the action relates to a permanent state change of the second avatar, sending a state change notification to a remote instance of an application that renders the first avatar and the second avatar.

[0184] Embodiment 4. The method according to any one of embodiments 1 to 3, wherein the second avatar may be a local avatar or a remote avatar.

[0185] Embodiment 5. The method according to any one of Embodiments 1 to 4, wherein the action is to play a sound effect or to render an animation.

[0186] Embodiment 6. The method according to any one of embodiments 1 to 5, wherein detecting the collision between the collider and the receiver further includes determining a physical attribute related to the collision, and the action may depend on the physical attribute.

[0187] Embodiment 7. The method of any one of embodiments 1 to 6, further comprising determining whether there is mutual agreement between the pair of the first avatar and the second avatar to permit the action resulting from the detected collision, before triggering the action.

[0188] Embodiment 8. A method for supporting an interaction that affects secondary motion of a portion of an avatar, comprising: detecting an interaction between a collider and the portion of the avatar, wherein the portion of the avatar is configured to have secondary motion; reporting the detected interaction to an avatar controller; and animating the movement of the portion of the avatar being manipulated by the collider to move according to the configured secondary motion.

[0189] Embodiment 9. The method of Embodiment 8, further comprising loading the parameters of the portion of the avatar and storing the parameters of the portion of the avatar in memory.

[0190] Embodiment 10. The method according to any one of embodiments 8 to 9, wherein the portion of the avatar is defined by a transform tree.

[0191] Embodiment 11. The method of any one of embodiments 8 to 10, further comprising determining that the interaction between the collider and the portion of the avatar triggers a physical simulation of one of the transforms in the transform tree.

[0192] Embodiment 12. The method of any one of embodiments 8 to 11, further comprising: if it is determined that the interaction between the collider and the portion of the avatar triggers a physical simulation of the transform, the rendering engine creates a job which is the physical simulation of the transform, and which is processed in a thread other than the primary thread.

[0193] Embodiment 13. The method according to any one of embodiments 8 to 12, further comprising checking that the rendering engine has completed the job, and if the job has not been completed, instructing the rendering engine to complete the job.

[0194] Embodiment 14. The method according to any one of embodiments 8 to 13, wherein the transform is configured to be compiled at runtime, and the creation of the job includes compiling the transform at runtime for execution on a thread other than the primary thread.

[0195] Embodiment 15. The method of any one of embodiments 8 to 14, further comprising executing the job in a thread other than the main thread to bring about the physical simulation of the movement of the portion of the avatar that is operated to move by the collider according to the set secondary motion.

[0196] Embodiment 16. The method according to any one of Embodiments 8 to 15, wherein the execution of the job utilizes local physics, and the local physics is limited to the interaction between the collider and the characteristics of the transform tree.

[0197] Embodiment 17. The method according to any one of embodiments 8 to 16, wherein the memory includes a memory structure that supports access to data in the memory by jobs running on multiple threads.

[0198] Embodiment 18. The method according to any one of embodiments 8 to 17, wherein the detection of the interaction between the collider and the portion of the avatar is performed frame by frame.

[0199] Embodiment 19. The method of any one of embodiments 8 to 18, further comprising detecting by a first instance of a client application associated with a local avatar that a remote avatar has an active receiver configured to accept contact.

[0200] Embodiment 20. The method according to any one of embodiments 8 to 19, wherein the detected interaction is a grab, and the method further comprises assigning control to the portion of the grabbed avatar, the portion of the grabbed avatar having an attachment point at the location where the portion of the avatar was grabbed.

[0201] Embodiment 21. The method according to any one of embodiments 8 to 20, further comprising determining whether the portion of the avatar is pinned.

[0202] Embodiment 22. The method according to any one of embodiments 8 to 21, further comprising restoring the portion of the avatar to its original state if it is determined that the portion of the avatar is not pinned.

[0203] Embodiment 23. The method according to any one of embodiments 8 to 22, further comprising determining that a pose has been applied to a portion of the avatar by the grab, and sending a state change notification to a remote instance of an application rendering the first and second avatars using information regarding the pinning state of the portion of the avatar.

[0204] Embodiment 24. The method of any one of embodiments 8 to 23, further comprising determining whether there is mutual agreement between the pair of the first and second avatars to allow the animated movement before animating the movement of the portion of the avatar that is operated to move by the collider according to the set secondary motion.

[0205] Embodiment 25. The method according to any one of embodiments 8 to 24, wherein the receiver is configured to receive only interactions from a designated collider.

[0206] Embodiment 26. The method according to any one of embodiments 8 to 25, wherein the designated collider is a class of colliders, such as a finger or hand collider, or the designated collider is on a particular avatar, or the designated collider is on a category of avatars, such as a humanoid avatar.

[0207] Embodiment 27. A method for determining whether avatar contact interaction is permitted, comprising: receiving avatar contact settings for a local avatar and at least one remote avatar in a world instance; determining, for a pair of avatars in the world instance, whether there is mutual agreement between the pair of avatars to permit avatar contact interaction; and displaying an indicator associated with at least one remote avatar that indicates an avatar contact interaction status indicating whether avatar contact interaction is permitted between the local avatar and the remote avatar.

[0208] Embodiment 28. The method of Embodiment 27, wherein the determination of whether there is mutual consent between the pair of avatars to permit avatar contact interaction is performed on an instance of the client application.

[0209] Embodiment 29. The method according to any one of Embodiments 27 to 28, wherein the determination of whether there is mutual consent between the pair of avatars to permit avatar contact interaction is performed by a networked service.

[0210] Embodiment 30. The method according to any one of embodiments 27 to 29, wherein the avatar contact settings include a contact category that allows avatar contact interactions with all avatars, a contact category that allows avatar contact interactions only with avatars in the friends list, and a contact category that does not allow any avatar contact interactions.

[0211] Embodiment 31. The method according to any one of embodiments 27 to 30, wherein the list of specified avatars associated with the setting overrides the contact category.

[0212] Embodiment 32. The method according to any one of embodiments 27 to 31, wherein the avatar contact setting includes a list of designated avatars associated with a setting that allows or disallows avatar contact interaction.

[0213] Embodiment 33. The method of any one of embodiments 27 to 32, further comprising storing in metadata associated with the remote avatar whether there is mutual agreement between the pair of avatars to permit avatar contact interaction for the pair of avatars in the world instance.

[0214] Embodiment 34. The method according to any one of embodiments 27 to 33, further comprising detecting a collision between a collider configured on a local avatar and a receiver on a remote avatar, reporting the detected collision to an avatar controller, determining an action of the remote avatar associated with the receiver if there is mutual agreement between the pair of avatars to permit avatar contact interaction, and triggering the action.

[0215] Embodiment 35. The method of any one of embodiments 27 to 34, further comprising detecting the collision between the collider set on the local avatar and the receiver set on the remote avatar, confirming that there is mutual agreement between the pair of avatars, and triggering the action.

[0216] Embodiment 36. The method of any one of embodiments 27 to 35, further comprising: detecting a collision between a collider set on the local avatar and a receiver on the remote avatar; reporting the detected collision to the avatar controller; and terminating the process related to the avatar contact interaction if there is no mutual agreement between the pair of avatars to permit the avatar contact interaction.

[0217] Embodiment 37. The method according to any one of embodiments 27 to 36, further comprising, in some embodiments, an invisible boundary being created when the pair of avatars that do not agree with each other are within a threshold distance of each other.

[0218] Embodiment 38. The method according to any one of embodiments 27 to 37, further comprising determining that a system safety setting prohibits animation from a remote avatar, detecting a collision between a collider configured on a local avatar and a receiver on a remote avatar, and terminating the avatar contact interaction because the system safety setting prohibits animation resulting from the avatar contact interaction.

[0219] Embodiment 39. The method according to any one of embodiments 27 to 38, further comprising determining that a system safety setting prohibits animation from a remote avatar, wherein an indicator associated with at least one remote avatar indicating avatar contact interaction status indicates that avatar contact interaction is not permitted as a result of the system safety setting.

[0220] Embodiment 40. The method of any one of embodiments 27 to 39, further comprising determining that an animation associated with an avatar contact interaction is content-flagned, determining that a setting is associated with the local avatar to filter content that is content-flagned, and terminating the avatar contact interaction because it contains filtered content.

[0221] Embodiment 41. The method of any one of Embodiments 27 to 40, further comprising determining that a remote avatar associated with an avatar contact interaction is labeled with a content flag, determining that the local avatar is associated with a setting to filter content that has the content flag, and downloading an alternative remote avatar that is not associated with the content flag.

[0222] Embodiment 42. The method of any one of embodiments 27 to 41, further comprising determining whether either avatar in the pair of avatars constitutes a receiver associated with an avatar contact interaction, before determining whether there is mutual agreement between the pair of avatars.

Claims

1. A method for triggering an action in response to a collision between a collider and a portion of an avatar configured to respond to a collision, To detect a collision between the collider and the portion of the avatar configured to respond to the collision, The detected collision is reported to the avatar controller associated with the avatar, To animate the reaction to the aforementioned collision, Methods that include...

2. The method according to claim 1, wherein the portion of the avatar configured to respond to the collision includes a receiver, the receiver is configured to trigger an animation or effect in response to the collision.

3. The method according to claim 1, wherein the collider is located on a first avatar, and the portion of the avatar configured to respond to the collision is located on a second avatar.

4. The method according to claim 1, wherein the portion of the avatar configured to respond to the collision is configured to have secondary motion.

5. Determining whether the aforementioned action is related to a permanent state change to the avatar, If it is determined that the action is related to the persistent state change of the avatar, a state change notification is sent to the remote instance of the application rendering the first avatar and the second avatar. The method according to claim 3, further comprising:

6. Before animating the reaction to the collision, determine whether there is mutual agreement between the first avatar and the second avatar to permit the reaction resulting from the detected collision. The method according to claim 3, further comprising:

7. Furthermore, animating the reaction resulting from the detected collision is possible. This includes animating the motion of the portion of the avatar that is manipulated to move by the collider according to the configured secondary motion, The method according to claim 4.

8. Determining that the collision between the collider and the part of the avatar triggers a physical simulation of one of the transforms in the tree of transforms that constitute the part of the avatar configured by the secondary motion, The method according to claim 4, further comprising:

9. If it is determined that the interaction between the collider and the portion of the avatar triggers the physical simulation of the transform, then information regarding the interaction is passed to a job processed by a thread other than the primary thread, which is the physical simulation of the transform. The method according to claim 8, further comprising:

10. A non-temporary, computer-readable storage medium containing instructions, When the aforementioned instruction is executed by the computer, the computer will: Detecting the collision between the collider and a portion of the avatar configured to respond to the collision, The detected collision is reported to the avatar controller, To animate the reaction to the aforementioned collision, To execute A storage medium that can be read by a computer.

11. The computer-readable storage medium according to claim 10, wherein the portion of the avatar configured to respond to the collision includes a receiver, the receiver configured to trigger an animation or effect in response to the collision.

12. The computer-readable storage medium according to claim 10, wherein the portion of the avatar configured to respond to the collision is configured to have secondary motion.

13. Animating the reaction to the collision arises from the detected collision, and the instruction further causes the computer to A computer-readable storage medium according to claim 12, configured to animate the motion of the portion of the avatar that is operated to move by the collider in accordance with the configured secondary motion.

14. The aforementioned instruction further causes the computer to The system is configured to determine that the collision between the collider and the part of the avatar triggers a physical simulation of one of the transforms in the tree of transforms that constitute the part of the avatar configured by the secondary motion. A computer-readable storage medium as described in claim 12.

15. The aforementioned instruction further causes the computer to If it is determined that the interaction between the collider and the portion of the avatar triggers the physical simulation of the transform, the system is configured to pass information about the interaction to a job processed in a thread other than the primary thread, which is the physical simulation of the transform. A computer-readable storage medium according to claim 14.

16. Processor and A memory for storing instructions, wherein when an instruction is executed by the processor, the system Detecting the collision between the collider and a portion of the avatar configured to respond to the collision, The detected collision is reported to the avatar controller, The system is configured to animate the reaction to the aforementioned collision, A computing system that includes this.

17. The computing system according to claim 16, wherein the portion of the avatar configured to respond to the collision includes a receiver, the receiver configured to trigger an animation or effect in response to the collision.

18. The computing system according to claim 16, wherein the collider is located on a first avatar, and the portion of the avatar configured to respond to the collision is located on a second avatar.

19. The computing system according to claim 16, wherein the portion of the avatar configured to respond to the collision is configured to have secondary motion.

20. Animating the reaction to the collision arises from the detected collision, and the computing system The computing system according to claim 19, configured to animate the motion of the portion of the avatar that is operated to move by the collider in accordance with the configured secondary motion.

Images