유니티 스크립트 작업 중에 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 문제라는 것만 같고 개발 세팅이나 문제가 발생하는 시점 역시 달라서 크게 참고가 되지 않았다). 외국 개발자들의 이야기 중에 그나마 도움이 되었던 것은 이 문제가 유니티 에디터에서만 발생하고 빌드한 실행 파일에서는 발생하지 않는다는 것이었다.
에러 로그나 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에는 고질적인 버그가 하나 있다. 유니티 에디터에서 게임 테스트를 위해서 플레이 버튼을 눌러서 플레이할 때 다른 씬으로 이동하면 라이트가 어둡게 보이는 문제가 바로 그것이다.
의도한 씬의 밝기는 첫 번째 그림과 같지만 유니티 에디터에서 플레이 버튼을 눌러서 게임을 실행한 뒤에 플레이 도중에 씬을 넘어가면 라이트의 밝기가 두 번째 그림처럼 어두워 진다. 이러한 현상은 게임을 빌드해서 실행했을 경우에는 발생하지 않지만, 라이팅 테스트 하나만을 위해 매번 게임을 새로 빌드해서 실행하는 것은 매우 번거로운 일이다.
이 문제를 해결하는 방법은 다음과 같다.
상단 메뉴에서 Window > Lighting > Setting 을 선택하면 라이팅 세팅을 할 수 있는 창이 열린다.
열린 Lighting Setting 창의 가장 아래쪽에서 Auto Generate가 체크되어 있는 것을 볼 수 있는데 이 체크를 해제하면 옆의 Generate Lighting 버튼이 활성화된다. 이 버튼을 클릭하면 유니티 에디터에서 테스트를 진행할 때에도 빛이 제대로 들어오는 것을 확인할 수 있다.
[유니티 어필리에이트 프로그램]
아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.
