Unifying Collision Shapes for Character Accessories

Unifying Collision Shapes for Character Accessories I am pleased to begin the session on Unifying Collision Shapes for Character Accessories. -------Copyright (c) .NET Foundation and Contributors Released under the MIT License: https://opensource.org/license/mit/ ©CAPCOM 1

Agenda "Yuremono" (constraint-based physics objects) Character structure Common collision system for "yuremono" character accessories Duplicate collision problems and solutions Summary This is the agenda. This session will begin with a description of "yuremono“ used with characters and the problems involved. 1 Next, the common collision system introduced as a solution will be presented. ©CAPCOM 2

Yuremono First, let me talk about "yuremono." 2 ©CAPCOM 3

What are “Yuremono"? Soft bodies (string, cloth, etc.,) that work with physics simulation In RE ENGINE, two types are available: Chain and Cloth In the Japanese game industry, "yuremono" generally refers to 1D and 2D soft bodies. RE ENGINE has two types of yuremono: one-dimensional "Chain" and two-dimensional "Cloth." 3 Chain and Cloth are used in a wide range of situations, often for interactive backgrounds such as curtains and chains hanging from the ceiling, not to mention clothing. In this article, we will focus mainly on yuremono being used in a character's clothing, hair, etc. ©CAPCOM 4

Use of Yuremono Runtime performance - Chain > Cloth Behavior believability - Cloth > Chain Chain Cloth Hair, equipment accessories, etc. Robes, skirts, etc. Next, I will discuss the use of yuremono in RE ENGINE. Chain optimizes processing by limiting simulation to 1D shapes. It can also simulate 2D shapes in a pseudo way, but it is a little simpler. 4 Cloth simulates 2D shapes and provides a richer representation than Chain, but its processing load is higher. In actual titles, Chain is mainly used for the character's hair and equipment accessories. Cloth is used for character clothing such as robes and skirts, where cloth-like behavior is important. In our game development, we use a combination of the two, taking into account their merits and demerits. ©CAPCOM 5

Yuremono Collision Previously, each yuremono asset had a collision shape Set up collisions Next, I will discuss the relationship between yuremono and collisions. When using shaking objects for equipment, etc., it is necessary to set up a collision shape for each yuremono asset. 5 For performance reasons, we have a special collision shape for this purpose, in addition to the collision shape for general hit detection. For example, in the image on the left, the Cloth asset is a dress, and the collision is set for the legs so that they do not stick to the character. When you actually run the Cloth, you can see that the yuremono collides with the collision shape. In the past, collision shapes were set for each asset as shown here. ©CAPCOM 6

Collision Shape Duplication Problem Collision shape overlap between Chain and Cloth assets Chain Cloth The problem here was that there were many cases where the same collision shape was set up for both Chain and Cloth assets. Not only was this a waste of time and effort, but it also created the risk of accidentally editing only one of the collision shapes if the 6 character's shape was changed later. Thus, yuremono collisions presented an unavoidable workflow problem. ©CAPCOM 7

Character Structure In addition, there were other problems with yuremono collision shapes besides duplication. The problems stemmed from the structure of characters that we often use. 7 We will discuss this character structure next. ©CAPCOM 8

Character Structure at Capcom Parent-child structure of game objects Example Base Head Replace "Tops" to change equipment Hair Helm Tops Pants Mantle Sword In many cases, we use a parent-child structure, as shown on the left, as the structure of a character's game object. The structure is such that game objects like equipment and weapons are set up as children of the base character game object. 8 The main reason for this structure is to support equipment switching. By expressing equipment as a combination of game objects, equipment switching can be easily accomplished. ©CAPCOM 9

Intra-asset Collision Issues Base Tops The shape of the leg collision shape is uncertain at the stage of creating yuremono Pants … The problem with this structure is that the collision shape must be changed depending on the combination of equipment. For example, consider equipment with a front hanging like in the "Tops“ image. 9 The front part of the drooping part is set up as a yuremono. Since this drooping part may come in contact with the character’s legs, the leg collision shape must be set up for the swinging assets. You may have noticed that the leg collision shape varies depending on the leg equipment. However, when the asset is created, it is not known which leg equipment can be used with the asset, so the collision cannot be set. In the past, this problem was solved by matching the appearance of the leg equipment to some extent and using the same collision shape. However, this method inevitably limits the appearance of the leg equipment. ©CAPCOM 10

Summary of Yuremono Problems Problems 1. Collision shape duplication in Chain and Cloth 2. Collision shapes of other equipment are not available Here is a summary of the problems with using yuremono on characters. First, collision shapes are likely to be duplicated in the Chain and Cloth assets, which may lead to waste and risk of mistakes 10 in the workflow. Also, due to the structure of the character, there may be cases that cannot be handled only by collision shapes set manually, such as collisions with other equipment. As a solution to these problems, we have introduced a common character collision system. ©CAPCOM 11

Common Collision System for Yuremono Objects Now, with that background, let me introduce the common yuremono collision system that we have implemented. 11 ©CAPCOM 12

Common Collision Shapes for Yuremono ① Manage collision shapes on a per game object basis • Set common collision assets in dedicated components • Unified collision data for yuremono Set assets in dedicated components Create common collision assets The common collision system has two major features as a solution to the problems I discussed earlier. The first feature is the way collision information is managed. 12 Instead of managing collision shapes within each asset, they are now managed on a component-by-component basis. This can also be said to be done on a per game object basis. Collision shapes are created separately as common collision assets independent of yuremono, and set in dedicated components. When a yuremono uses a collision shape, it refers to the common collision shape via this component. This allows us to unify collision shapes used by yuremono. ©CAPCOM 13

Common Collision Shapes for Yuremono ② Collision shapes from parents and siblings can also be used Can use collision shape from equipment on different parts of the body Base Note: To be specific, collision shapes from all connected components are available Tops Pants Collision data is shared The second feature is collision shape sharing. It allows the use of not just one's own collision shapes, but those of one's parents and siblings, too. This means we can use collision shapes of other parts of the body as well. 13 For example, think about the waist equipment with the front droop as in the previous example. Now that the parent-sibling collision shapes are also available, the leg collision shape appropriate for the current leg equipment can be used. Note that actual characters do not have a simple parent-child structure, but often have a hierarchy of grandchildren and greatgrandchildren. Therefore, the exact specification is to share collision shapes within a connected component formed by dedicated components. ©CAPCOM 14

Multiple Equipment Collision Shapes: Problems and Solutions Next, I would like to discuss the challenges we faced in implementing the common collision shape system and how we solved them. 14 ©CAPCOM 15

Common Collision Shape Problems Multiple collision shapes in the same area Base Collision shapes of the lower back and legs are overlapped in Base and Pants Tops or Pants -> A system to determine priority needs to be provided There was one issue with the common collision feature allowing the use of parent-sibling collisions shapes. For example, in the case of the equipment combination shown in the previous example, there are duplicate collision shapes 15 for the legs and hips. Duplicate collisions in the same area would not only cause unnecessary processing, but could also destabilize the simulation of the yuremono. Therefore, in such a case, we need to prioritize collision shapes to eliminate the unnecessary ones. The Tag and Priority mechanism was introduced as a solution to this problem. ©CAPCOM 16

Tags Mechanism for specifying a location for each collision shape Head L_Arm_Upper Spine_1 Hip Tag for each collision shape Create asset that defines how to divide the parts First, let me explain Tags. Tags are a mechanism for specifying which part of the character each collision shape is associated with. 16 First, we create a Tag asset that defines how tags are divided, and set this to the common collision asset to enable setting of tags for each shape. Tags may be created and used not only for body parts, but also for weapons and terrain. ©CAPCOM 17

Priority Mechanism for determining shape priority Set by game object (component) This means all shapes in the set asset are treated as Priority=6 Next, we will discuss Priority. Priority is a mechanism to exclude unnecessary shapes when there are overlapping collision shapes. 17 Priority is set per component. When collecting geometry, all geometry in the asset assigned to the component is treated as having that Priority. ©CAPCOM 18

Collecting Shapes by Tag and Priority Base Tops Pants There are multiple collision shapes with the 'Leg' tag! I will now explain how Tag and Priority are used to select collision shapes, using the character in the previous example. First, a tag is set for each collision shape. 18 In reality, the tags are more detailed, but for the sake of explanation, let's assume that they are roughly divided into four categories: head, body, arms, and legs. Pink represents the head, blue the arms, green the body, and red the legs. The Tops equipment yuremono is going to interfere with the collision shape set in the Legs Tag. If you pay attention to the red collision shape here, there are two leg Tag’d collision shapes: one for the Base and one for the Pants equipment. As it is, the leg Tag collision shapes overlap, so we need to set the priority and select the collision shapes appropriately. ©CAPCOM 19

Collecting Collision Shapes by Tag and Priority Tops Base Priority=0 Select collision shape depending on the Priority Pants Priority=1 In this system, the specification is to collect only the shape with the highest Priority for each Tag. Suppose that Priority=0 is set for Base and Priority=1 for Pants. 19 Since only the collision shape with the highest Priority is available for each Tag, the Pants shape is given priority in this case, and the Base leg shape is excluded. The final selected collision shape shows that the legs are using the shape from the leg equipment. In this way, we envision the use of setting the Priority of each piece of equipment to a higher value than the base parent. By setting the Tag of each equipment collision shape to the Tag of the parent you wish to exclude, you can choose whether or not to keep that collision shape. ©CAPCOM 20

Collision Filtering on the Yuremono Side Basically filtered by Tag • (e.g.) Cloak -> Set Tag for waist and arms • Filtering settings are set up on the yuremono asset If you add a Tag later... • All yuremono assets need to be edited! -> Implemented a mechanism called TagGroup Finally, I will talk about collision filtering on the Chain and Cloth side. On the yuremono side, collision filtering is based on Tags. For example: You have a cloak, you want it to collide with the upper body, so you set tags for the waist and arms. 20 However, specifying the Tag directly may cause a little trouble. Suppose we decide to add a Tag later. In this case, you willhave to edit the tag settings of all the yuremono assets. Since there can be as many as 600 yuremono assets in totalfor a single title, this can be a very difficult task. In order to reduce this workload, we have introduced a system called TagGroup. ©CAPCOM 21

TagGroup On the yuremono asset side specify a TagGroup instead of a Tag Define a TagGroup that groups Tags A TagGroup is simply a grouping of multiple Tags with a name. For example, a TagGroup named UpperBody, which represents the upper body, contains Tags such as L_Arm_Upper and 21Head. When specifying a Tag from the yuremono asset side, instead of specifying the Tag directly, the Tag is specified indirectly by specifying the TagGroup. This way, if a tag is added later, it is only necessary to edit the TagGroup asset. Suppose that two new tags, "right shoulder" and "left shoulder," are added. In this case, simply edit the TagGroup asset and add the new tags to the "upper body“ group, and the shoulders will collide with any yuremono with the "upper body" group set. At this time, there is no need to make any changes to the yuremono assets. Only the TagGroup asset needs to be modified. ©CAPCOM 22

Summary Problems with yuremono on characters • Collision shape duplication in Chain and Cloth • Collision shape of other equipment is not available Common collision system • Common collision assets • Collision management is centralized in a dedicated component • Collision shapes of other equipment now available Tag, Priority • Organize priority of overlapping collision shapes in the same area • Use TagGroup to streamline tag-based filtering Here is a summary of this session. First, there were two problems with yuremono assets used on characters. 22 Collision shapes were duplicated between different yuremono assets, and collision data from other pieces of equipment were not available. To solve these problems, we introduced a common collision system. This system solved the duplication problem by centralizing the management of collision shapes using common collision assets and dedicated components. This also made it possible to collect collision shapes from components that are related to each other in the hierarchy, making collision shapes from other equipment available. The Tag and Priority concepts were added to address the problem of collecting multiple shapes from the same area. Also, TagGroups are used to make it easier to add tags. That concludes this session. Thank you very much for your attention. ©CAPCOM 23