TWA 후디니 1 RIGIDBODY_03 : RBD, Bullet Solver 그리고 RIGID BODY SOLVER

https://www.twahoudini.com/course/rigidbody1

HOUDINI1_ RIGIDBODY

 

RigidBody03에서는 처음으로 RigidBody Simulation을 직접 다루어볼 예정이다. 기본적인 Dop Network 세팅도 잡아볼 것이다.

후디니를 공부함에 있어 따라하는데서 그치지 않고 쭉쭉 치고 나가기 위해서 본격적으로 들어가기 전 맥락을 짚어보는 시간을 가져보겠다.

 

앞으로의 강의에서 RigidBody를 배울 순서

1. 가장 기본적인 Rigid Body에 대한 이론설명

2. 새로운 node 배우기

3. 마블영화에 나오는 테서렉트 효과 만들기

 

목차

1. RigidBody Solver의 작동방식과 Solver 관련 Node

2. RigidBody Simulation에서의 메모리 최소화

3. RigidBody Simulation을 위한 Node들

4. 충돌규칙과 엔진에 따른 Simulation 결과

 

 

---

1. RigidBody Solver의 작동방식과 Solver 관련 Node

 

왼쪽은 파티클을 구성해주는 기본 셋업이다. 오른쪽은 연기를 만드는 Smoke Solver의 기본 셋업이다.

이것들의 가장 큰 특징은 Object와 Source가 나뉘어 있다는 것이다.

기본적으로 Particle이나 Smoke는 생성과 소멸을 반복하기 때문에, 마치 땔감을 넣어주듯 Solver 작동을 위해서 Source를 계속 투입시켜주어야한다. Smoke Solver도 마찬가지로 계속 연기를 발생시키고 싶다면, Volume을 Source로 투입시켜주어야 한다. 

 

이제 RigidBody의 가장 기본이 되는 셋업을 보겠다.

Particle과 Smoke의 셋업이 비슷하고, RigidBody와는 다른 것을 볼 수 있다. 가장 큰 차이는 RigidBody에는 Source를 투입하는 내용이 없다. 이는 RigidBody Simulation의 목표를 생각하면 합리적인 구성이라고 이해가 될 것이다.

가장 기본적인 상황에서 RigidBody Simulation의 목표는 Dop Network 밖에서 준비한 물체가 물리법칙에 의해 어떻게 떨어지고, 어떻게 충돌하는지, 그리고 어떤 리액션을 보이는지 보는 것이다.

그렇다면 Solver의 Input1에 들어오는 Object는 어떤 역할을 할까? 지금까지의 내용에서 말하자면 해당 Input1에 들어갈 내용은 Dop Network 밖에서 준비한 물체를 불러오는 역할을 한다.

지금까지의 내용이 가장 기본적인 상황에서의 설명이다. 뒤에 가서는 Solver의 세팅을 바꿔줌에 따라 그 맥락이 조금 바뀌게 될 예정이다.

 

일단은 Input1으로 들어오는 내용이 Box라고 가정하고 다른 상황을 만들어보겠다. Object를 여러개 복사해준 뒤 Merge 해준다. 이때 Geometry 단계에서 A,B,C라는 물체가 준비되어 있다면, 각각의 물체를 Dop Network안에서 대입시켜줄 수 있을 것이다.

이렇게 Object에 물체가 대입되어 있다면, 각각의 A,B,C Box가 어떠한 상호작용을 하는지 RigidBody Solver의 결과로서 보게 될 것이다.

날아오는 속도에 의해 충돌할 수도, 아니면 충돌하지 않고 둥둥 떠 있을 수도 있다.

 

Geometry 단계에서의 셋업을 바꿔보도록 하겠다.

A,B,C Box를 Merge로 한번에 묶은 다음에 multi_box라는 이름으로 통합해주겠다. 해당 multi_box의 내용을 Dop Network 안에서 불러오도록 하겠다.

이렇게 묘사한다면 이전과는 다른 세팅이 된다. 이전에는 각각의 내용물을 서로 다른 Object에 따로따로 불렀었다. 지금은 여러 내용물을 동시에 한 Object에 부른 상태이다.

그래서 우리가 어떤 방식으로 어떤 Node를 쓰느냐에 따라 RigidBody Solver의 결과가 달라질 것이다. 이전처럼 서로 다른 Box 세 개가 충돌하는 Simulation이 될 수도 있고, Geometry 단계에서 묶어준 이유로 마치 하나의 물체처럼 Simulation이 발생할 수도 있다.

여기서 알 수 있는 점은 RigidBody Solver의 Input1에 들어가는 내용이 POP Solver나 Smoke Solver에서와 같이 그릇의 역할을 한다는 것이다. 

 

이제 RigidBody 기본 셋팅에서 조금 발전된 상태를 보도록 하겠다.

방금 전의 기본적인 세팅 방식으로 Box를 불러온다면, 총 세 개의 Box가 등장할 것이다. 이때 3개의 Box는 Object에서의 셋팅을 바꾸지 않는다는 가정하에 Simulation 시작 시점에 동시에 들어오게 될 것이다.

그렇지만 이러한 결과가 아닌, 세 개의 Box가 서로 다른 시점에 발생하기를 원할 수도 있다. 아니면, 3개의 Box가 매 Frame마다 Random하게 생성되길 원할 수도 있다. 이러한 뉘앙스는 POP Solver에서 POP Object라는 내용의 Source를 어떻게 담을지 규칙을 정해주는 내용과 유사하다.

이를 RigidBody에서 해내기 위해서 Sop Solver를 다룰 줄 알아야한다. 해당 내용은 Source와 유사하게 RigidBody Solver의 Input3에 넣어주게 된다.

이제 RigidBody의 구현방식 또한 Particle, Smoke와 유사함이 생겼다. 이를 물체를 담는 그릇과 물체를 올리는 규칙, 파티클을 담는 그릇과 파티클을 생성하는 규칙, 연기를 담는 그릇과 땔감을 넣는 규칙으로 설명할 수 있다.

 

요약하자면 이러하다. RigidBody Simulation은 우리가 그릇에 올린 내용물들이 충돌하고 물리법칙에 따르며 리액션을 보여주기를 원하는 것이다. 이때 그릇에 물체를 올릴 규칙을 Sop Solver로 조절할 수 있다.

 

이제 먼저 Simulation이 시작하자마자 준비한 물체가 등장하고, 추가적인 물체의 등장이 없는 그러한 셋업부터 공부해보려 한다.

앞서 세팅하기에 따라 다르다는 말을 한적이 있다. 그 이유는 RigidBody Simulation을 발생시키는 Solver와 Object가 딱 한개씩 있는게 아니기 때문이다.

이제 가장 기본 세팅을 가지고 RigidBody에서 쓰이는 Object들과 Solver들을 보여주도록 하겠다. 

 

RigidBody의 핵심은 충돌이다. 그래서 이 충돌이 어떠한 조건으로 이루어지는 지에 따라 Solver가 나뉜다.

앞선 Particle과 Smoke에서는 충돌 조건으로 Volume을 이용하였었다. RigidBody에서도 Volume을 기준으로 충돌 Simulation이 가능하다. 이때 사용되는 Solver가 RBD Solver이다.

RBD Solver는 후디니에서의 업데이트 순서를 본다면 가장 먼저 나온 방식이다.

그런데 이 RBD Solver는 모든 물체가 Volume으로 Converting되어야 하고, 그 Volume의 정보량의 사이즈에 따라 Simulation 속도에 영향을 많이 끼친다는 약점이 있다. 충돌조건이 SDF이기에 해상도가 높아질수록 용량이 커져 느려지게 된다.

 

그래서 그 대안으로 나온 Solver가 Bullet Solver이다. Bullet Solver는 물체를 다른 Geometry로 계산해서 쉽게 계산해준다.

그런데 이때 대체해주는 Geometry의 모양에 따라 결과가 부정확할 수도 있다는 약점이 존재한다.

 

둘은 원리 자체가 달라서 둘 중 무엇이 더 좋다고 할 수는 없다. 이때 우리가 신경써줘야할 것은 RBD Solver를 사용할 때는 Volume data를 준비하거나 Volume의 해상도를 얼마나 줄지를 고민해야하며, Bullet Solver를 사용할 때는 그릇에 올린 물체가 어떤 Geometry로 대체되어 Simulation이 발생될지를 고민해주어야 한다.

또 새로운 Node로 Rigid Body Solver가 있다. 두 Solver를 왔다갔다하며 비교할 때의 번거러움을 줄이기 위해서 둘을 묶어두고 골라서 쓸 수 있게 해주는 Node이다.

 

앞으로의 RigidBody 강의에서는 RBD보다는 Bullet을 더 많이 사용할 예정이다. 그 이유는 Constraint 때문이다.

Constraint를 간단하게 설명하자면, 물체가 연결된 관계라고 표현할 수 있겠다.

두 물체가 고정되어 있을 때 딱딱하게 두 물체가 고정되어 있을 수도 있고, 말랑말랑하게 위치와 각도가 고정되어 있을 수도 있다. 아니면, 두 물체가 마치 딱풀로 붙인 것처럼 접착되어 있다가, 충격에 의해 떨어질 수도 있다. 이러한 연결 관계를 Constraint라 할 수 있겠다. 이러한 Contraint를 얼마나 잘 다루느냐에 따라 RigidBody Simulation의 퀄리티가 크게 달라질 것이다. 얼마나 더 자연스러운지, 얼마나 더 흥미로운 결과를 만들어내는지가 Constraint에 달려 있다.

이때 Constraint 작업이 Bullet Solver에서 수행해야 올바르게 적용이 된다.

RigidBody Solver에 대한 이야기는 마무리 되었으니, 이제 그릇(Object)에 대한 이야기로 넘어가보겠다.

 

 

---

2. RigidBody Simulation에서의 메모리 최소화

 

이제 Geometry 단계에서 준비한 Object가 Solver에 들어가면서 어떻게 인식이 될 지를 보도록 하겠다.

RigidBody Simulation은 두 가지 방식으로 작동한다. 하나는 Volume에 의해, 다른 하나는 Geometry에 의해서이다.

이 각각의 방식에 맞게 주어진 물체가 충돌 조건으로 치환이 되어야 한다. RBD에서는 어떻게 치환이 되고, Bullet에서는 어떻게 치환이 되는지 비교해보는 시간을 가지겠다.

그리고 이 과정에서 충돌조건의 메모리를 보면, 대략적인 Simulation 속도도 짐작할 수 있을 것이다.

 

Rubbertoy와 Tommy를 꺼내준다. Null을 달아 둘의 연결을 바꿔가며 볼 예정이다.

먼저 Volume에 대해 이야기해보도록 하겠다. 만약 우리가 RBD solver나 RDB 엔진으로 RigidBody Simulation을 작동시킨다면, SDF 정보가 필요할 것이다. 그리고 이 SDF를 Dop Network 안에서 볼 때는 Geometry로 변환해서 보이게 될 것이다.

Object에 Iso Offset을 달아 SDF Volume으로 변환해준다. 지금의 SDF 상태가 RDB 정보로서 RigidBody Simulation에 쓰이게 될 것이다.

그런데 이 SDF 정보가 Dop Network 안에서는 IsoSurface 정보로 보여지게 된다.

IsoOffset node를 복사해 IsoSurface로 바꿔준다. 지금 Viewport에 보여지는 형태로 충돌 조건을 체크하면서 RBD로 작업하게 되는 것이다.

 

지금의 과정에서 Uniform Sampling Divsion을 조절해줌에 따라 충돌조건의 해상도를 높여줄 수 있다.

SDF 정보와 IsoSurface의 해상도를 동일하게 높여준다.

이제 두 해상도의 충돌 조건이 얼마만큼의 메모리를 할당하는지 확인해보겠다. 이때 Dop Network 안에서 실제로 이용될 정보인 SDF의 메모리 용량을 보아야 한다.

확실히 해상도를 높였을 때 메모리가 크게 증가하는 것을 볼 수 있다.

 

지금의 방법 이외에 직접 Proxy Volume을 만들어주는 방법도 존재한다.

VDB from Polygons로 SDF VDB 정보를 만들어준다. Convert VDB로 만든 Polygons를 IsoSurface의 역할로 보겠다.

이때 voxel size를 조절해줌으로써 충돌 조건의 해상도를 높여줄 수 있다.

Proxy_sdf의 메모리를 보면 확실히 앞선 SDF 정보들보다 큰 메모리를 가지고 있는 것을 볼 수 있다.

 

이제 Rubbertoy의 사이즈를 Transform으로 키워보려한다. 이때의 각각의 메모리 변화를 관찰해보도록 하자.

RBD_high_data의 용량을 보면 2.82MB인 것을 볼 수 있다. 이때 사이즈가 다시 줄어들어도 용량에 큰 차이가 없는 것을 볼 수 있다.

하지만 구체적인 값으로서 voxel size를 정해준 Proxy_sdf는 Object의 사이즈가 커짐에 따라 그에 맞게 메모리도 커지는 것을 볼 수 있다.

이렇게 차이가 나는 이유는 SDF을 구하는 방식이 달라서이다. IsoOffset에서 몇 개로 쪼개는가는 사이즈에 상관없이 쪼갤 양이 정해져 있다. 그래서 크기에 관계 없이 정보량이 같다. 그러나 VDB from Polygons에서 voxel size를 쪼갤 길이를 정하는 경우엔 크기가 바뀌면 용량도 바뀌게 된다.

이 사실에서 유추할 수 있는 건, Volume으로 작업을 할 때에 크기가 다른 물체를 다룸에 있어 사이즈의 차이가 많이 난다면, 충돌 조건의 해상도를 잘 정해주어야 한다는 것이다.

사이즈가 크면 울퉁불퉁한 디테일이 많은 면일 때, IsoOffset은 디테일을 많이 잃을 것이다. 그러나 VDB from Polygons를 썼을 때는 용량이 너무 클 수도 있다.

사이즈가 작은 물체에서도 IsoOffset의 경우 사이즈가 작은데 너무 잘게 쪼개게 되면 불필요하게 용량이 커질 수 있다. 

 

지금까지는 RDB에서 쓰일 정보에 대해 설명하였다. 이번에는 Bullet에서 쓰이게 될 정보를 만들어보겠다.

Bullet에서는 Volume으로 변하는 과정이 필요 없다. Geometry 그 자체로써 충돌을 발생시킬 수 있기 때문이다.

만약에 Rubbertoy가 가진 모든 Detail을 살려서 작업하고 싶다면, 그냥 원본을 그대로 사용하여도 좋다. 이때 이렇게 원본을 바로 사용하는 경우를 Concave라고 부른다.

Concave는 쉽게 이용할 수 있지만 그만큼 용량이 크기 때문에 빠른 속도가 나오지 않는다는 단점을 가지고 있다.

Bullet Solver가 빠른 이유는 Geometry의 충돌 조건을 표현하기 쉬운 가벼운 물질으로 전환해서 Simulation하기 때문이다. Concave 과정에서와 같이 쉬운 물질로 바꿔주는 과정이 없다면, Bullet Solver의 장점을 활용하지 못한다.

 

이제 Bullet Solver가 어떠한 방식으로 물체를 가벼운 충돌조건으로 변환시키는지 알아보도록 하겠다.

새롭게 Convex Hull node를 이용해주겠다. Convex Hull에서의 결과가 Bullet Solver에서의 충돌 조건이 될 것이다.

Viewport를 보면 Rubbertoy의 가장 튀어나온 부분을 기준으로 면으로 랩핑 되어 있는 것을 볼 수 있다. 해당 결과가 Rubbertoy를 대신하게 되는 것이다.

Convex Hull에서의 메모리를 보면, Concave에 비해 매우 적은 용량을 가지고 있는 것을 볼 수 있다.

그런데 Convex Hull에는 치명적인 단점이 있다. 해당 물체가 단독으로 지면과 충돌할 때는 문제가 없지만, 다른 물체와 상호작용이 발생할 때 Convex Hull의 특징 때문에 Simulation의 정확도가 떨어지게 된다.

랩핑 되어 있는 부분이 벽이 되어 그 안쪽 부분은 절대로 다른 물체와 충돌할 수가 없다. 이러한 약점을 보완하는 방법은 이후에 따로 설명하도록 하겠다.

 

만약 Convex Hull보다 더욱 Simulation을 가볍게 만들기를 원한다면 충돌 조건을 더 단순하게 만들어주면 해결될 것이다.

Bound node를 활용해 해당 Geometry의 Bounding Box를 충돌 조건으로 설정해줄 수 있다.

하지만 이러한 방식의 충돌 조건은 Simulation의 정확도를 더욱 더 떨어뜨리게 될 것이다.

그럼에도 불구하고 이러한 방식이 더 효율적인 순간들이 존재한다. 예를 들면, 1000개의 Rubbertoy가 충돌하며 떨어지는 모습을 포착하는 경우 Detail한 충돌 묘사보다는 빠르게 Simulation이 되는 것이 더 중요할 것이다.

또한 원하는 느낌에 맞춰 Bouding Type을 변경해줄 수도 있다.

Bound에서의 메모리를 확인해보면 Convex Hull 보다도 극단적으로 적은 메모리 양을 관찰할 수 있다.

 

이제 Convex Hull의 약점을 보완하는 방법에 대해 이야기해보도록 하겠다. Tommy를 Object로 사용하겠다.

Viewport를 보면 Convex Hull에 의해 Tommy의 팔과 몸통, 다리와 다리 사이의 공간이 막혀 있는 것이 아쉽다.

해결 방법은 간단하다. Voronoi Fracture로 Scatter로 뿌린 점의 갯수 만큼 Tomm

y를 쪼갠 뒤 Assemble로 Piece끼리 Pack해준다. 그 다음 For-each Primitives안에서 Piece들을 각각 Unpack 해준 뒤, Convexhull로 랩핑해주는 과정을 반복해준다. 여러번의 반복에 의해서 랩핑된 조각들이 모두 모여 Tommy의 원본의 형태와 유사한 모습을 갖추게 된다.

이때 결과의 Detail을 높이고 싶다면 Scatter에서 뿌려주는 점의 갯수를 늘려주면 된다.

 

또 Convex Hull을 사용하지 않는 또 다른 방법도 존재한다. 바로 Object를 전부 작은 Sphere들로 대체하는 방법이다.

IsoOffset으로 Tommy를 Fog Volume으로 변환해준다. Scatter로 점을 뿌려준 뒤 Copy to Points를 통해 해당 점들을 Sphere(primitive)로 전환시킨다.

Tommy가 전부 Sphere로 덮힌 것을 볼 수 있다. 이때 좀 더 Detail한 결과를 얻고 싶다면, Sphere의 Size를 낮추고 Scatter로 더 많은 점을 뿌려주면 된다.

 

 

---

3. RigidBody Simulation을 위한 Node들

 

먼저 Box와 Rubbertoy를 Dop Network에 불러서 물리 법칙이 적용될 수 있도록 해주겠다.

Transform node로 둘의 위치를 y축 방향으로 올려준다.

각각 Null node를 달아 이름을 정해주겠다. Box는 prep_box, Rubbertoy는 prep_toy로 해준다. 이때 prep은 preparation으로 준비라는 뜻이다.

 

이제 Dop Network를 생성해 그 안에서 RigidBody Solver에 대해 알아보겠다.

먼저 RigidBody Simulation을 작동시키기 위한 Solver를 전부 꺼내주겠다. RBD Solver, Bullet Solver, Rigid Body Solver가 있다.

그 다음으로는 Geometry 단계에서의 물체를 Dop Network 안으로 들여오려 한다. 이때 사용되는 Node로는 Static Object, RBD Object, RBD Packed Object, RBD Fractured Object가 있다. 한번 해당 Node들의 특징을 간단하게 짚어보겠다.

1.Static Object : Dop Network 안에서 다른 물체들의 충돌 조건이 되어 준다. 그런데 이때 충돌 조건이 된 물체는 충돌이나 중력의 영향을 받지 않는다.

2. RBD Object : RigidBody Simulation을 위한 node들 중에서 가장 대중적이고 범용적이다.

3. RBD Packed Object : Pack된 자료를 넣어줄 때 사용하는 node이다.

4. RBD Fractured Object : 조각이 나있는 물체를 넣어줄 때 사용해준다.

 

이제 해당 Node들의 파라미터를 보면서 비교해보겠다. 비교를 한 뒤에는 Static Object, RBD Object, RBD Fractured Object와 RBD Packed Object가 다르다고 느낄 수 있을 것이다.

먼저 Static Object의 Parameter를 보겠다. 이때 우리가 중요하게 보아야하는 부분은 Collisions 탭이다.

Collisions 탭이 RBD Solver와 Bullet Data 두 개로 나뉘어 있다.

RBD Solver에서는 Volume으로써 충돌 조건을 만들어주게 되고, Bullet Data에서는 불러온 물체를 어떤 다른 Geometry로 변환해서 충돌 조건으로 쓴다.

만약 Static Object를 RBD Solver node에 연결해준다면, Static Object의 Collisions 탭에서 RBD Solver를 신경써야할 것이다. 또한 Bullet Data는 Bullet Solver에 연결되었을 때 신경써주면 될 것이다. Stataic Object가 Rigid Body Solver에 연결되어 있다면 어떠한 엔진으로 사용되는지에 맞춰 Collisions 탭에서의 내용을 신경쓰면 될 것이다.

Static Object, RBD Object, RBD Fractured Object는 Collisions에 대한 세팅이 똑같이 되어 있기에 똑같은 방식으로 신경써주면 될 것이다.

그러나 RBD Packed Object는 Collisions 탭이 없고 바로 Bullet Data 탭이 있는 것을 볼 수 있다. 이에 따라 RBD Packed Object는 Bullet Solver나 Bullet 엔진만을 이용할 수 있다.

지금까지의 내용을 바탕으로 어떤 Node를 어떠한

Solver에 넣어야하는지 알고 있다는 것이 작업에서의 시간을 절약해줄 것이다.

 

 

---

4. 충돌규칙과 엔진에 따른 Simulation 결과

 

이제 Object를 Dop Network 안으로 불러오는 작업을 해보려한다. 우리가 오늘 사용할 Object는 Pack과 Fracture와는 무관하기 때문에 RBD Fractured Object와 RBD Packed Object를 지워주고 Static Object, RBD Object만을 이용해주도록 하겠다.

Static Object의 Sop Path에 prep_box의 경로를 입력해 Box Object를 불러온다.

일단은 먼저 RBD Solver에서의 결과를 보기위해서 Static Object를 RBD Solver에 연결해준다.

Gravity node를 달아 Simulation 안에서 중력이 작동하도록 해준다.

Simulation을 작동해보면 공중에 떠 있는 Box를 볼 수 있다. 그 이유는 Static Object로 불러들인 물체가 중력과 충돌에 의한 영향을 받지 않기 때문이다.

RBD Solver node를 쓰고 있을 때 Object의 충돌 조건을 확인하고 싶다면, Static Object의 Collisions 탭의 RBD Solver 부분을 확인하면 될 것이다.

 

이때 RBD Solver에서 충돌 조건을 준비해주었더라도, Static Object의 연결을 Bullet Solver로 바꿔준다면 Bullet Data에서의 충돌 조건이 이용될 것이다.

Guide를 켜보면 Volume 결과가 아닌, 있는 그대로의 Geometry가 충돌 조건으로써 들어온 것을 볼 수 있다.

불러올 Geometry를 prep_toy로 변경해준다면 이전에 보았던 랩핑된 Object가 충돌 조건으로써 들어온 것을 볼 수 있다.

 

이제 고정된 Static Object가 아닌 움직임을 보기 위해서 RBD Object를 이용해주도록 하겠다. Ground Plane을 달아 바닥에 충돌할 수 있도록 해준다.

RBD Solver의 Guide를 켜고 RBD Solver node에 연결해 Simulation을 돌려보면, 기대했던 대로 중력에 의해 떨어지는 Rubbertoy를 볼 수 있다.

이번에는 Bullet Data에 연결해 결과를 보겠다.

충돌 방식과 Solver가 바꼈기 때문에 동일한 위치에서 떨어지더라도 Simulation 결과가 달라지는 것을 볼 수 있다.

Ground Plane과 충돌이 일어난 순간을 보면, RBD Solver에 의한 결과에서는 Rubbertoy의 머리가 앞으로 고꾸라지지만 Bullet Solver에 의한 결과에서는 모서리에 의한 충돌의 영향을 덜 받는 것을 볼 수 있다.

 

다음은 Geometry 단계에서 물체의 위치를 바꿔주어 두 물체가 충돌할 수 있도록 세팅해주겠다.

먼저 RBD 엔진으로 결과를 보면, 기대했던대로 충돌 Simulation이 잘 작동하고 있는 것을 볼 수 있다.

Bullet 엔진으로된 결과를 보면, Box가 Rubbertoy의 등과 충돌하지 않고 공중에서 보이지 않는 벽에 부딪히고 있는 것을 볼 수 있다. Guide로 결과를 보면 Bullet Data가 제공해준 Geometry의 모습을 확인할 수 있다.