VRChat Phys Bone 설명 및 소감

Phys Bone 설명

Root Transforms - Phys bone 가 적용될 hierarchy중 최상단 본
Ignore Transforms - 하위 본들 중 Phys bone 적용 제외할 부분
Endpoint Position - 기존 Dynamic bone에서 본 길이 연장하는 기능과 동일

Multi child Type

본 하위에 여러 종류의 child가 있을 경우의 옵션, Ignore는 child 무시, First는 처음 child만 적용, Average는 child 간 평균 적용

Forces
Pull, Momentum - 본의 움직임 정도를 결정하는 정도. Pull은 본의 이동속도와 관련이 있으며 momentum은 관성과 관련이 있음.

Stiffness - 본의 경직성과 관련있는 변수, 변화속도가 느려지게 되나 적절하게 세팅할 경우 본 움직임이 부드러워지기도 합니다.

Immobile - 본의 결속력을 정하는 부분, 높을수록 본이 안 움직이게 됩니다.

Gravity - 중력 설정, 중력 적용을 안 받으려면 0으로 설정해야 합니다.

Limits

None - 움직임 각도에 제한이 없음 = Angle 180과 동일 
Angle - 본으로부터 원뿔형으로 움직임 각도 제한 설정. 180도면 none와 동일하며 치마는 30 이하를 추천드립니다.

Hinge - 본의 움직임 중 종방향으로만 움직이도록 제약합니다. 0~180도 가능
Polar - hinge의 상위호환으로 종방향과 횡방향 양쪽으로 움직임 각도를 설정할 수 있습니다. 


Collision - 충돌 판정과 관련된 부분, dynamic bone에서의 콜라이더 상호작용과 관련된 부분이나, Phys bone 이후로는 손과의 상호작용(Grab)등에도 영향이 있습니다.

Colliders - 콜라이더 사이즈를 결정하는 부분, 0으로 설정할 경우 collider 및 Grab의 영향을 받지 않게 됩니다.

Allow Collision - 컴포넌트에 등록되지 않은 콜라이더와 상호작용(현재는 손)하는 옵션


Allow Grabbing/Posing - grab부분은 본인 혹은 다른 유저의 grab에 영향을 받지 않게 되며, posing 옵션을 끌 경우 본인 혹은 다른 유저가 본 모양을 변경하거나 위치고정하는 것을 방지할 수 있습니다.

Allow Collision + Allow Grabbing + Allow Posing 전부 해제 시 다이나믹본과 비슷하게 상호작용을 끌 수 있습니다.

Parameter/IsAnimated - FX에서 parameter 제어(animation)를 하는데 필요한 부분입니다. 끌 경우 성능은 향상되나 parameter 제어는 불가능해집니다.

Phys bone 소감

제 개인적인 생각으로는, 이번에 VRChat이 역대급으로 망한 패치(삽질)을 했다고 보는데요. 이유는 기존 Dynamic bone 기반 아바타들과 호환성이 나쁘면서도, 성능향상 부분에서 유저들이 기대하는 만큼 절대로 향상되지 않아서요.

VRChat렉(병목현상)의 실제 주범은 쉐이더와 이펙트, 아바타와 월드의 다중 material call인데요. 이들이 VRChat 성능상 주요 병목현상을 일으키며, dynamic bone의 경우 off시 전체 프레임 중 20% 정도만 영향이 있습니다.(18명 Kor Tuto 맵 기준)

따라서 Phys bone이 설령 성능상 dynamic bone 성능의 2배라고 해도 프레임(성능)상 gain은 10% 정도에 불과하고 여전히 걸릴 렉은 걸리는 것이죠. 이처럼 성능상 이득은 미미하면서도 기존 컴포넌트들과 하위호환성이 극히 나쁘기 때문에 최악의 업데이트라고 볼 수밖에 없습니다.
솔직히 VRChat 개발자들이 장점이라고 주장하는 성능상 gain조차 본이 부드럽지 않은 거 보면 refresh rate를 30Hz나 그 이하로 깎아서 성능올린게 아닌가 하는 생각도 있네요.

그 외에 잡다하게 있는 grab, posing등의 기능... 솔직히 사이버 성추행 외에는 그닥 쓸모가 있을 것 같지 않은데요. 그저 삽질기능인듯...


어쩌면 Phys bone의 최적화라는 것도 실제로는...

1. 연산갱신속도를 dynamic bone의 60hz에서 30~24hz로 줄여서 연산하고(= 기술적으로 가장 쉬운 최적화 방법) 다이나믹본과 다르게 피직스본에는 refresh rate 옵션이 없는 것에서 대강 짐작 가능.

2. 가까운 본은 움직임이 구현되지 않는다고 하는데, 이게 실제로는 float연산단위를 줄여서 연산량 절감하는게 아닌가 생각되네요. 이 경우 연산최적화는 되나(두번째로 쉬운 최적화 방법) 정밀성이 좀 떨어지게 되겠죠.

1 + 2 하면 기존(dynamic bone)의 20~50% 수준으로 연산량을 줄이는 건 쉽지만, 그 댓가로 물리 연산이 중간중간 부드럽지 않게 보이거나, 혹은 가까운 본의 움직임은 나타나지 않게 되는데요. 지금 이 모든 현상이 다 일어나고 있는....

잘 모르는 애들은 멀티코어니 최적화 5배니 하는데... 연산량 측면에 대해 기술적으로 따져보자면 실제로는 Tupper의 날치기 수법에 가깝고. Unity 기반의 다중물리연산 동기화에 멀티코어를 브챗이? 아예 안된다고 할 수는 없지만 난이도가 높은 작업이고, 브챗 개발진 수준에 무난하게 가능했을 것 같진 않네요.