Search Unity

Unity 2019.3 베타에서는 PhysX가 다방면으로 업데이트되어 더욱 정확하고 신속하며 강력한 구현이 가능합니다.

PhysX 라이브러리가 PhysX 3.4에서 PhysX 4.1로 업그레이드되었습니다. 자세한 내용은 NVIDIA의 PhysX 4.1 SDK 가이드에서 ‘Migrating from PhysX SDK 3.4 to 4.0’ 섹션을 참조하시기 바랍니다.

새롭게 추가된 솔버 유형

2019.3에는 Temporal Gauss-Seidel이라는 새로운 솔버 유형이 추가되었습니다. 이 솔버는 Edit > Project Settings의 물리(Physics) 카테고리에서 사용할 수 있으며, 조인트의 오버스트레치 및 글리치에 대한 저항력이 높아집니다

새롭게 추가된 광범위 단계(Broad-phase) 유형

자동 박스 프루닝(Automatic Box Pruning)이라는 광범위 단계 알고리즘도 새롭게 추가되었습니다. 현재 지원되고 있는 멀티박스 프루닝(Multibox Pruning) 알고리즘과 유사하지만 월드 경계와 구획 수를 자동으로 계산합니다. 또한 기존의 그리드 셀 세트를 유지하고 일반적인 스윕 및 프룬(Sweep And Prune)을 통해 중복될 가능성이 있는 콜라이더 페어를 처리합니다. 이러한 기능을 활용하면 단일 스윕 및 프룬으로 다수의 추가적인 1종 오류(false positives)가 발생할 수 있는 대규모 씬에 도움이 될 수 있습니다. 이 모드는 PhysX 4.1의 광범위 단계 기본값이지만, 현재로서는 기본적으로 비활성화되어 있습니다. 자동 박스 프루닝을 사용하려면 Physics설정의 Broadphase Type에서 활성화하시면 됩니다.

새로운 중간 단계(Mid-phase)

중간 단계는 데이터 구조 및 알고리즘 세트입니다. 이러한 알고리즘은 물리 쿼리를 실행할 때마다 또는 콜라이더가 메시 표면에 근접한 경우 교차할 가능성이 있는 소규모 메시 트라이앵글 세트를 선택합니다. 알고리즘을 이렇게 설정한 이유는 하나의 메시에 다수의 트라이앵글이 포함되어 있는 경우 일일이 정밀 점검을 실행할 수 없으므로 가속화 구조를 빌드하여 알고리즘이 점검할 만한 일부 하위 세트만 선택할 수 있도록 하기 위함입니다.

이러한 가속화 구조는 일반적으로 메시 콜라이더 컴포넌트를 인스턴스화하여 sharedMesh 프로퍼티에 할당하는 메시 베이킹 과정에서 빌드됩니다. 이와 같은 구조를 빌드하는 데에는 상당한 시간이 소요되므로 최적화가 필요합니다. 이전 PhysX 버전에서 소요 시간의 대부분을 차지한 과정은 R-트리 구성이었습니다.

PhysX 4.1은 R-트리가 필요 없는 새로운 알고리즘을 사용합니다. 단, 이 알고리즘은 현재 Windows, Mac과 Linux 플랫폼에서만 실행된다는 단점이 있습니다. 이 알고리즘은 데스크톱 플랫폼에서 자동으로 사용되며, Cooking Options 드롭다운 메뉴에서 메시 콜라이더별로 비활성화할 수 있습니다. 지원되지 않는 플랫폼의 경우 이전의 중간 단계 알고리즘이 자동 적용됩니다.

지연 메시 베이킹 멀티 스레드 메시 베이킹

앞에서 언급했듯이, 새로운 메시 콜라이더를 인스턴스화하는 데에는 상당한 시간이 소요되었습니다. 그러나 이제는 Physics.BakeMesh 함수를 이용하여 메시 콜라이더와 함께 사용할 메시 인스턴스를 미리 베이크할 수 있습니다. 복잡한 계산이 요구되는 메시 베이킹 절차를 로딩 화면이나 전환 씬(예: 어드벤처 게임의 대화 씬 또는 컷 씬) 뒤로 숨길 수 있습니다.

특히 이 함수는 추가적으로 메인 스레드 외부에서 호출하여 사용 가능한 모든 코어로 베이킹 로드를 분산하는 흥미로운 효과가 있습니다. 관련 문서에서 이 함수를 C# 잡 시스템과 함께 사용한 예를 살펴보세요.

터레인 콜라이더 두께 통합 하이트맵 설정 제거

Unity 2018.3에서는 터레인 콜라이더(TerrainCollider)를 위한 더욱 강력한 컨택트(contacts) 생성 경로를 포함하고 컨택트 생성 알고리즘을 변경하는 등의 업데이트가 있었습니다. 새로운 알고리즘은 하이트맵 지오메트리를 처리하기 위한 별도의 경로를 사용하는 대신 접촉한 하이트맵의 일부를 메시로 취급하여 일반 메시 컨택트 생성 코드를 활용합니다. 단, 이전 코드는 계속 유지되어 물리 설정에서 Enable Unified Heightmaps 옵션을 통해 사용할 수 있었습니다.

PhysX 4.1에서는 Enable Unified Heightmaps 옵션이 제거되었습니다. 또한 터레인 컴포넌트 프로퍼티에서 사용할 수 있었던 두께 설정도 제거되었습니다. 터레인 두께는 빠르게 이동하는 오브젝트가 감지되지 않은 상태로 터레인 표면을 통과하는 터널링 효과를 해결하기 위한 기능이었습니다. 이제 터레인 두께 설정 대신 연속 충돌 검사를 사용하시면 됩니다.

키네마틱 재삽입

이제 키네마틱 리지드바디가 비키네마틱(non-kinematic) 리지드바디로 전환되면 물리 엔진이 해당 리지드바디를 광범위 단계(Broad-phase) 구조로 재삽입하여 충돌 검사를 실시하며, 이로 인해 추가적인 OnTriggerEnter 이벤트가 발생합니다.

 

이번 업데이트는 Unity에 PhysX를 안정적이고 완성도 높게 통합하기 위해 실시되었으며 이제 보다 정밀하고 개선된 성능의 Unity를 사용하실 수 있습니다. Unity 2019.3 베타를 사용해보고 포럼에 의견을 남겨주세요

29 replies on “Unity 2019.3 물리 업데이트”

IN unity 2015 version there is option called tear option for cloth behavior i am not able to find that option in any other version’s unity. i think unity removed that tear able option. if any one find that option please let me know in new version of unity.

Still no access to shiftOrigin, so… no truly open world? :( Floating origin miss this to move all colliders at once without breaking the user experience…

Any news regarding concave objects with rigidbodies and more than 255 polygons like it is at the moment ?
In my company, since we really need concave objects without approximations, we are currently bypassing this limitation by cutting our objects in sub-objects, which really is a pain.

When will the basic feature of having the contacts BEFORE resolved available? Why would anybody want to get the contacts after they are resolved? Any info (penetration distance, speed, etc) is not useful afterwards. We want to anticipate the resolution stage, just as PhysX lets us, so we can CHANGE what it will do. Add additional impulses, forces, changes, or even avoid the contact by chaning the other collider.

Cool stuff. But, with Havok coming to Unity I’d really like to know what’s the main reason I’d pick one physics engine over the other. Can you guys make an article comparing between PhysX and Havok? Like a pros and cons?

PhysX is the physics engine used for games when the game code is written with GameObjects / MonoBehaviours.
Havok or Unity.Physics is used when the game code is written in Unity.Entities.

Generally speaking Havok is significantly faster and has significantly better simulation stability. But of course given that DOTS and the packages surrounding it are in preview, the choice is really less about do you want to use physx vs havok but rather about do you want to use DOTS for your game code or stay with a stable proven game object / monobehaviour based solution.

Joachim, will game object / monobehaviour eventually be phased out in the future after DOTS become stable or you will keep advancing both?

I think many Unity developers have this same question. I think it would be really clear to anyone if they would say if Dots will replace GameObjects one day or just be another solution to choose from. I have the same concerns back then when Flash was going to die but everyone was about talking around it. We all know what happened, so I think being more clear about Dots and MonoBehaviour situation would help a lot. =)

“This will cause an extra OnTriggerEnter event”

This is very dirty, was this necessary? I can’t imagine a case where this does not introduce unwanted behaviour.

And you’ll be lucky if you remember having read this blog post to understand where the unwanted behavior is coming from.

Its really not that difficult to catch the first event and ignore the second, it really shouldnt impact you.

By the way what happened to the manual update of the Physics simulation?
Has it ever be implemented?

Nice Update.
I’m a bit worried about this:
“This will cause an extra OnTriggerEnter event.”
Isn’t this breaking backward compatibility?

Comments are closed.