지난 영상인 캐릭터 색상 선택 기능 구현하기에서 놓친 버그들을 수정해봅시다.

 

사용 엔진 버전 : 2019.4

 

타임라인

0:00 인트로

0:19 첫 번째 버그 - 설정 창을 띄운 상태로 캐릭터 조작이 가능한 버그

2:08 두 번째 버그 - Customize UI를 켜면 가끔 캐릭터가 달리는 애니메이션이 계속 재생되는 상태로 서있는 버그

3:27 세 번째 버그 - 색상 선택 버튼이 제대로 업데이트되지 않는 버그

6:42 네 번째 버그 - 반대편 의자에서 스폰되는 플레이어가 의자 방향에 맞지 않게 스폰되는 버그

7:58 아웃트로

반응형

Cloth

-

유니티 2019 버전에서의 Cloth 컴포넌트 문제


작성 기준 버전 :: 2019.*


Cloth 컴포넌트는 유니티 엔진에서 지원하는 사실적인 천의 펄럭임을 구현하기 위한 컴포넌트다.


2018 버전의 Cloth

 

Cloth 컴포넌트를 사용하면 위 그림과 같이 메시(Mesh)를 천과 같은 움직임을 보이도록 시뮬레이션 할 수 있다.


다만, 유니티 2019 버전에 들어오면서 이 Cloth 컴포넌트와 관련해서 여러가지 문제점이 제기되고 있다. 제기된 문제의 주된 내용은 다음과 같다.


2019 버전에서 Cloth 컴포넌트를 사용할 때,

2019 버전에서 Cloth 컴포넌트가 부착된 프리팹을 인스턴스화 했을 때,

Cloth 컴포넌트를 사용하던 2018 버전의 프로젝트를 2019 버전으로 마이그레이션 했을 때,


- 초당 1프레임 수준으로 렌더링 속도가 심각하게 저하됨.

- 메시(Mesh)가 심각하게 찌그러짐.

- 자연스러운 움직임이 아닌 이상하게 꿈틀거리는 움직임을 보임.


사실상 2019 버전에서는 Cloth 컴포넌트를 사용하기 힘든 수준의 문제들이 보고되고 있다.


2019 버전의 Cloth

 

유니티 2019에서 Cloth 컴포넌트를 사용해보면 처음에는 정상적으로 동작하는 것으로 보인다.


 

하지만 Cloth 컴포넌트의 Stretching Stifness 값을 변경해보면 문제가 바로 눈에 띈다.

2018 버전의 Cloth2019 버전의 Cloth

 

2018버전에서는 Stretching Stifness 값을 0으로 바꾸면 펄럭일때 주름이더 세밀해지는 정도의 변화를 보이지만, 2019 버전에서는 Stretching Stifness 값을 0으로 변경하면 버텍스가 찢어지면서 형태가 완전히 무너지는 것을 볼 수 있다. 


때문에 2019 버전에서는 이 문제가 완전히 해결되기 전에는 Cloth 컴포넌트를 사용하지 않을 것을 권장한다.




관련 유니티 포럼 글


Cloth physics problems when migrate from Unity 2018 to 2019

[Cloth] [AR] Unity 2019.2.4f1 broke Cloth

[Cloth] Sudden cloth performance issues in AR

Cloth self-collision: Selection not saving / unselects after clicking Play


반응형

Camera.main에서 Null Reference가 발생하는 문제


작성 기준 버전 :: 2018.3.2f1


유니티 스크립트 작업 중에 Camera.main을 호출하면 해당 씬에서의 주 카메라가 반환된다. Camera.main으로 반환받는 주 카메라를 통해서 스크린의 좌표를 월드의 좌표로 변경하거나 월드 좌표를 스크린의 좌표로 변경하는 증의 작업을 주로 하게 된다.


하지만 가끔 이 Camera.main이 제대로된 주 카메라를 반환하지 않고 null 값을 반환하는 문제가 발생하는 경우가 발생한다.


이런 문제는 새로 생성한 씬에 자동으로 들어있는 기본 카메라를 지우고 새 카메라를 만들었을 때 주로 발생한다.



위의 이미지는 새로운 SampleScene을 만들고, 기본적으로 들어 있던 Main Camera를 지우고 New Camera를 만든 상황이다.


public class MainCameraTest : MonoBehaviour
{
    void Start()
    {
        Debug.Log(Camera.main);
    }
}


이 상황에서 위와 같이 Start() 시점에 Camera.main을 호출하는 스크립트를 만들고 게임 오브젝트에 이 스크립트를 컴포넌트로 붙여서 실행해보자.


 

그렇게 하면 위 이미지처럼 Camera.main이 null 값을 반환하는 것을 확인할 수 있다.


 

이런 문제가 발생하는 이유는 스크립트에서 Camera.main을 호출해서 메인 카메라를 찾아낼 때, "MainCamera" 태그가 붙어있는 카메라를 찾아내는 방식을 사용하기 때문이다. 그렇기 때문에 기존에 있는 메인 카메라를 지우고 새로운 카메라를 만들었다면 새로 만든 카메라의 Tag를 "MainCamera"로 바꿔줘야 한다.


새로 만들어진 카메라에 MainCamera 태그를 달고 다시 플레이를 해보면 새로 만든 카메라가 Camera.main으로 반환되는 것을 확인할 수 있다.


카메라에 메인 카메라 태그를 붙일 때도 주의해야 하는 점은, 만약 여러 개의 카메라에 메인 카메라 태그를 붙이면 Camera.main으로 호출했을 때 어떤 카메라가 반환될지 확정할 수 없기 때문에 문제가 발생할 수 있다는 점이다.

반응형

유니티 개발 중 Access Violation 충돌로 인한 에디터 종료 문제(5.6 Kinect 개발 중에 발생한 문제)


5.6.0f3 버전의 유니티 엔진에서 키넥트 V2(Kinect V2 이하 키넥트)를 이용해서 개발하는 도중에 유니티 에디터 상에서 게임 테스트를 하기 위해서 플레이 버튼을 눌렀을 때 유니티 엔진이 Unity Bug Reporter 창을 띄우고 뻗어버리는 일이 발생했다.



다음의 내용이 개발하기 위해 세팅되어 있는 것들이었다.


Unity 5.6.0f3

Microsoft Kinect SDK 2.0

Visual Studio Community 2017

Kinect Examples with MS-SDK v2


버그 발생하기 이전에 수정한 사항은 많지 않았기 때문에 갑자기 발생한 버그라서 버그의 원인을 짐작하기가 쉽지 않았다.



유니티 엔진은 crash.dmp 파일과 error.log 파일 하나만 남겨놓고 뻗은 상태였고, 로그 내용을 기반으로 구글링도 해보았으나 외국의 개발자들 역시 Access Violation 문제로 고통받고 있을뿐 별다른 해결책은 찾을 수 없었다(그리고 Access Violation 문제라는 것만 같고 개발 세팅이나 문제가 발생하는 시점 역시 달라서 크게 참고가 되지 않았다). 외국 개발자들의 이야기 중에 그나마 도움이 되었던 것은 이 문제가 유니티 에디터에서만 발생하고 빌드한 실행 파일에서는 발생하지 않는다는 것이었다.



Unity Editor [version: Unity 5.6.0f3_497a0f351392]

mono.dll caused an Access Violation (0xc0000005)
  in module mono.dll at 0033:abc51985.

Error occurred at 2017-06-14_092816.
C:\Program Files\Unity\Editor\Unity.exe, run by PC.
44% memory in use.
8114 MB physical memory [4468 MB free].
14258 MB paging file [9523 MB free].
134217728 MB user address space [134214674 MB free].
Read from location 320f7000 caused an access violation.

Context:
RDI:    0x00000000  RSI: 0x3209d87b  RAX:   0x00000001
RBX:    0x0002cbc2  RCX: 0x00000000  RDX:   0x0392dc0d
RIP:    0xabc51985  RBP: 0x00000000  SegCs: 0x00000033
EFlags: 0x00010202  RSP: 0x005fcb70  SegSs: 0x0000002b
R8:     0x00054d0d  R9:  0x00000000  R10:   0x0002cbc2
R11:    0x00000000  R12: 0x00000000  R13:   0x00000080
R14:    0x000003ff  R15: 0x00002400

Bytes at CS:EIP:
66 46 39 2c 56 73 9f 41 ff c0 ff c3 49 ff c2 eb

Stack:
0x005fcb70: 0000000b 00000000 3989ae80 00000000 ...........9....

.

.

.

0x005feb60: 00000000 ffffffff 00000042 00007fff ........B.......

Module 1
C:\Program Files\Unity\Editor\OpenRL_pthread.dll
Image Base: 0x80000000  Image Size: 0x0000f000
File Size:  50200       File Time:  2017-03-30_143322
Version:
   Company:    Open Source Software community LGPL
   Product:    POSIX Threads for Windows LPGL
   FileDesc:   MS C 32 bit
   FileVer:    2.9.0.0
   ProdVer:    2.9.0.0

Module 2
C:\Program Files\Unity\Editor\OpenRL.dll
Image Base: 0x80000000  Image Size: 0x00c28000
File Size:  12627992    File Time:  2017-03-30_143322
Version:
   Company:    Imagination Technologies, Inc.
   Product:    OpenRL™
   FileDesc:   OpenRL™ Library
   FileVer:    1.5.100.10
   ProdVer:    1.5.100.10

Module 3
C:\WINDOWS\SYSTEM32\MSVCR100.dll
Image Base: 0x53a80000  Image Size: 0x000d2000
File Size:  829264      File Time:  2011-02-19_005232
Version:
   Company:    Microsoft Corporation
   Product:    Microsoft® Visual Studio® 2010
   FileDesc:   Microsoft® C Runtime Library
   FileVer:    10.0.40219.1
   ProdVer:    10.0.40219.1

Module 4
C:\WINDOWS\SYSTEM32\MSVCP100.dll
Image Base: 0x53b60000  Image Size: 0x00098000
File Size:  608080      File Time:  2011-02-19_225156
Version:
   Company:    Microsoft Corporation
   Product:    Microsoft® Visual Studio® 2010
   FileDesc:   Microsoft® C Runtime Library
   FileVer:    10.0.40219.1
   ProdVer:    10.0.40219.1


== [end of error.log] ==


에러 로그나 Dump 파일을 봤을 때, 문제는 mono.dll에서 발생하는 것으로 보였다. 하지만 당장 개발이 급했기 때문에 덤프 파일을 분석하지는 못했고 당장의 문제의 원인을 파악하고, 문제를 배제한 뒤에 개발을 다시 시작하기 위해서 프로젝트를 새로 만들어서 리소스와 스크립트를 옮기는 작업을 했다. 하지만 프로젝트를 새로 만들어서 내용물을 옮기는 것만으로는 문제가 해결되지 않았고, 결국 문제가 발생하는 지점을 찾기 위해서 오브젝트에 붙은 컴포넌트를 하나씩 꺼보고 스크립트를 블럭 단위로 주석 처리하는 방식으로 문제 지점을 찾기 위해 작업했다.


이 작업을 진행하는 도중의 대부분은 오브젝트에 붙은 컴포넌트를 제거하거나 스크립트를 주석처리하고 플레이해 본뒤에 충돌이 발생하는지 확인하는 것이었다. 그러던 중에 발견한 사항은 다음과 같았다.


1. Kinect Examples with MS-SDK v2 에셋에서 제공하는 스크립트를 오브젝트에 붙인 컴포넌트를 게임 씬에서 모두 제거하면 충돌이 발생하지 않는다.

2. Kinect Examples with MS-SDK v2 에셋에서 제공하는 스크립트를 오브젝트에 붙인 컴포넌트를 제거하지 않더라도 내가 작성한 스크립트 중에서 특정 블럭을 주석 처리하면 충돌이 발생하지 않는다.


키넥트 개발을 계속해야하기 때문에 1번은 전혀 해결책이 될 수가 없었고 2번의 방법으로 주석 처리했을 때, 충돌이 발생하지 않는 부분을 찾기 위해 해당 코드 블럭을 한줄한줄씩 주석 처리해보면서 플레이 버튼을 눌러보는 수 밖에 없었다.


그러던 도중에 단 한 줄을 주석 처리했을 때, 충돌이 발생하지 않는다는 것을 발견할 수 있었다.



그 문제의 원인은 어이없게도 Debug.Log("업"); 이라는 코드였다. 이 한 줄을 주석 처리하면 더 이상 문제는 발생하지 않았다. 그리고 "업"이 아니라 다른 글자를 사용해도 문제가 해결되었고, 가끔은 다른 로그 내용도 문제를 발생시키기도 했으며, 혹은 Debug.Log("업");이라고 해도 또 다른 특정한 위치에서는 문제가 없이 작동했다.


키넥트가 필요하지 않은 테스트일 때는 Kinect Manager 스크립트를 제외하고, 키넥트가 필요한 시점에는 Log를 주의해서 사용해야 했다.


임시방편으로 문제를 우회해서 지나가는 방법은 발견했으나 근본적인 해결책을 찾지 못했다. 추측해보건데 로그를 남기는 작업은 파일에 관여하는데 그 작업 중 어느 부분이 Kinect Examples with MS-SDK가 제공하는 Kinect Manager 스크립트가 처리하는 부분과 충돌이 발생하는 것으로 보인다.



주변 분들이 원인으로 추정되는 몇가지를 이야기 해주었는데, 하나는 키넥트 스레드가 처리하는 부분에서 메인 스레드와 충돌을 일으킨 것이 아닌가 하는 것이고 다른 하나는 특정 문자열에서만 이 현상을 일으키기 때문에 문자열 인코딩 방식이 이런 문제를 발생시킬 수도 있다는 것이었다.

반응형

유니티 에디터에서 플레이 중에 씬 전환시 다음 씬에서 라이트가 어두워지는 버그(5.6)


유니티 5에는 고질적인 버그가 하나 있다. 유니티 에디터에서 게임 테스트를 위해서 플레이 버튼을 눌러서 플레이할 때 다른 씬으로 이동하면 라이트가 어둡게 보이는 문제가 바로 그것이다.



의도한 씬의 밝기는 첫 번째 그림과 같지만 유니티 에디터에서 플레이 버튼을 눌러서 게임을 실행한 뒤에 플레이 도중에 씬을 넘어가면 라이트의 밝기가 두 번째 그림처럼 어두워 진다. 이러한 현상은 게임을 빌드해서 실행했을 경우에는 발생하지 않지만, 라이팅 테스트 하나만을 위해 매번 게임을 새로 빌드해서 실행하는 것은 매우 번거로운 일이다.


이 문제를 해결하는 방법은 다음과 같다.



상단 메뉴에서 Window > Lighting > Setting 을 선택하면 라이팅 세팅을 할 수 있는 창이 열린다.




열린 Lighting Setting 창의 가장 아래쪽에서 Auto Generate가 체크되어 있는 것을 볼 수 있는데 이 체크를 해제하면 옆의 Generate Lighting 버튼이 활성화된다. 이 버튼을 클릭하면 유니티 에디터에서 테스트를 진행할 때에도 빛이 제대로 들어오는 것을 확인할 수 있다.


반응형

Unity Collaborate를 사용하면서 지속적으로 사용자에게 불편함을 주는 문제점이 발견되었다.

 

Collarborate를 사용하다보면 어느 순간에 Inspector 창과 Services 창이 검게 변하면서 먹통이 되는 버그가 발생한다. 위에 있는 Collab 버튼을 눌렀을 때 나오는 Publish & Update 메뉴 역시 검은 색으로 먹통이 된다(아직 다른 사람들이 부르는 용어를 들어본 적이 없으니 Inspector blackout이라고 부르자).

 

이 문제는 다른 해결책은 딱히 없으며 유니티를 재시작하는 방법이 그나마 나은 방법이고 유니티를 종료하면 버그 리포트를 보내라는 창이 뜬다. 조금 심각하게 여겨질 수 있는 부분은 이 버그의 발생 빈도가 생각보다 높다는 것이다. 스크립트 작업은 문제가 없지만, 유니티상의 대부분의 작업은 에디터에서 이루어 진다는 것을 볼 때 이 버그가 생각보다 자주 일어난다는 것 만으로도 작업 효율이 상당히 저하될 수가 있다. 더더욱 최악인 점은, 이 버그가 있는 Collaborate를 대신할 만한 SVN을 찾아서 설정하는 일은 굉장히 복잡한 일이라는 것이다.

 

현재로서 사용자가 할 수 있는 일은 Inspector 창이 blackout될 때마다 짜증을 내며 유니티를 재실행하고 유니티 측에서 빨리 이 버그를 해결해주기를 기도하는 수 밖에 없다.



ps. 유니티를 재실행하는 것 말고도 다른 해결책이 있다. Inspector 창을 껐다가 켜는 것이다. 하지만 이것 역시 유니티를 재실행하는 것과 비슷한 수준의 귀찮음을 프로그래머에게 가져다 준다.


ps2. 또 다른 해결책으로는 작업하는 도중에는 Collaborate를 끄고, 업데이트나 퍼블리쉬를 할때만 켜서

반응형

+ Recent posts