2022년 9월 12일 월요일

Unity Webgl 1.0 2.0

 Unity Webgl 1.0 2.0

테스트 환경 Unity 2020.3.35f
 
Webgl 2.0

포스트프로세싱(가능)
IOS 프레임 저하
linear 사용가능(gamma도 가능)
런타임중에 안티앨리어싱 변경가능

Webgl 1.0

포스트프로세싱(불가능)
IOS 프레임 이상없음
linear 사용 불가능(only gamma)
런타임중에 안티앨리어싱 변경불가능

---

Unity Version

2021 부터 astc 텍스처 지원
2020 이하 버전에서는 ios 모바일에서 사용가능한 압축 텍스처없어서
ios는 포기해야함

---

unity 2021 webgl 2.0 ios 프레임은 테스트 예정

---

ios에서만 webgl 2.0이상 프레임이 안나온다.
아직 ios에서 webgl 2.0이 실험적으로만 제공해주는거와 연관이 있어보이기는 하는데
target api 순서로 android 혹은 pc와 다르게 세팅할려고해도 
ios 사파리 세팅에서 webgl 2.0이 디폴트로 되어있어서 사용자한테 끄라고 할 수도 없고
언제나 unity는 ios가 문제다 ios가





2022년 5월 15일 일요일

URP)CameraStackManager

CameraStackManager

 
https://github.com/do-won-kim/CameraStack

unity urp로 넘어오면서 카메라가 제법 많이 변경이 있었는데 그중 눈에 띄는 점은 depth가 사라진 점과 depth only 가 사라진 것이다.

depth는 stack이라는 리스트로 depth only는 overlay camera로 구현이 가능한데 사실 기존에 UI canvas쪽을 screen space - overlay를 사용하던 프로젝트는 카메라를 여러대 쓰는게 아니라서 별로 신경쓸 점이 없다.

하지만 불행이도 우리 프로젝트는 screen space - camera를 사용중이였고 그에따라 ui camera가 따로 존재해서 overlay camera 기능을 사용해주어야 했다.

canvas를 전부 overlay로 바꾸는것은 이펙트 때문에 작업량이 많아져서 불가능 했기 때문에 기존 형태에서 자동으로 씬 이동이나 overlay 카메라가 켜지거나 꺼질때 혹은 base 카메라가 추가되거나 꺼지거나 할때 자동으로 stack 이라는 리스트를 관리해줄 필요성이 있어서 해당 매니저를 제작하게 되었다.


-camera stacking 스크립트-

사용법은 간단하다 CsCameraStacking 스크립트를 카메라에 부착해주고 depth값을 넣어주면된다.
밑에 bool 값은 overlay로 시작하는 카메라가 아니라 basecamera로 시작하는 카메라에 달린 스크립트에 체크 해주면 된다.

만들때 오래걸리지는 않았지만 이 카메라 변경점은 urp로 넘어올 때 많이 당황했던 부분 중 하나였다.


프로파일링 데이터 엑셀 추출 툴

 프로파일링 데이터 엑셀 추출 툴

https://github.com/do-won-kim/Tools/tree/main/Profiling


한창 최적화를 할 때 테스트 데이터를 저장해서 필요한 장소만 수정 할 수 있도록 엑셀 데이터를 뽑는 툴을 만든 적이 있었는데 이 후 다른 작업을 하게되면서 잊고 있었는데 갑자기 생각이 나서 odin 제거하고 기본 유니티에디터 스크립트로 수정한 버전

유니티 에디터에서 촬영하는 버전과 android와 연결해서 촬영하는 버전 두개가 있다.

자세한 사용방법은 깃허브의 리드미로 대체 합니다.

2022년 5월 9일 월요일

Simple)Material Copy Tool

 Material Copy Tool



간단한 툴 요청이 들어와서 만들게 된 텍스처를 제외한 머테리얼 값 카피 툴이다.

사용법은 별거 없다.
GetAllMaterial 버튼을 누르면 assets 폴더 하위의 모든 머테리얼 중 base와 같은 쉐이더를 가진 머테리얼을 Add한다.

ClearMaterial은 수정할 머테리얼 리스트 clear

ImportProperty 버튼은 기준 머테리얼에 있는 값들을 텍스처를 제외하고 리스트에 덮어씌운다음 에셋들을 모두 저장한다.

퇴근 두시간 전쯤에 요청이 들어와 Odin으로 간단하게 만들었다.


22-05-09 기준 Odin으로 작성된 버전만 커밋되어 있다. 추후 유니티 기본 에디터로 수정 예정
22-05-23 유니티 에디터 코드로만 작성된 버전 업로드

2022년 5월 2일 월요일

Custom Shader GUI Basic Frame

 Custom Shader GUI Basic Frame


유니티에서 쉐이더를 만들게 되면 프로퍼티에 따라서 GUI도 알아서 자동으로 나온다.
하지만 보통 사용하게 되는 그래픽팀에서는 작업을 위해서 여러 수정을 요청 할때가 많고 그럴때는 shadergui 라는 스크립트를 상속받아 프로그래머가 직접 커스텀을 해줘야한다.

                                -URP 기본쉐이더인 Lit shader의 custom gui-

지금까지는 baseshadergui 라는 스크립트를 상속받아 적당히 만들었지만 이번에 몇개의 큰쉐이더들의 gui를 크게 바꿔야 할 때가 오자 상당히 코드도 난잡해져있고 수정하기 복잡해져서 갈아엎고 새로 만들었다.

-ShaderGUI를 상속받은 CustomShaderGUI-

심플하게 필요한 기능과 필수로 구현해야할 부분만 따로 빼서 만들었다.
간단하게 설명하자면 MakeFoldoutHeaderGroup은 foldout 형식의 gui를 만들게 해준다.
header의 이름과 짤렸지만 안쪽에 들어갈 함수를 넣으면 아래와 같은 형식의 gui가 만들어진다.

DoPopup은 이름 그대로 팝업 형식을 만들때 쓴다 유용하기 때문에 baseshadergui에 있는 것을 그대로 가져왔다.

쉐이더에서 사용할 모든 프로퍼티들은 FindProperties에 넣으면되고 MaterialChanged에서는 주로 쉐이더 키워드들을 컨트롤 할때 사용하고 DrawSurceinputs에 원하는 순서로 프로퍼티들을 정렬하면된다.

실제 사용 gui 스크립트는 최상단의 링크에 있는 LitSpecularWithMaskGUI.cs를 참고

아무튼 gui 스크립트들이 대부분 좀 난잡했는데 깔끔해지니 기분이 좋다.







2022년 2월 16일 수요일

URP 7.6.3 -> 10.8.1 Specular가 미묘하게 달라져있다.

 URP 7.6.3 -> 10.8.1 Specular가 미묘하게 달라져있다.

Unity 버전을 2019에서 2020으로 올리게 되면서 URP 버전을 강제적으로 올리게 되었는데 몇몇 프랍들이 색이 좀 달라져서 수정하게 되었다.

#1
inline void InitializeBRDFData(half3 albedo, half metallic, half3 specular, half smoothness, inout half alpha, out BRDFData outBRDFData)
{
#ifdef _SPECULAR_SETUP
    half reflectivity = ReflectivitySpecular(specular);
    half oneMinusReflectivity = 1.0 - reflectivity;
    //half3 brdfDiffuse = albedo * (half3(1.0h, 1.0h, 1.0h) - specular);
    half3 brdfDiffuse = albedo * oneMinusReflectivity;
    half3 brdfSpecular = specular;
#else
    half oneMinusReflectivity = OneMinusReflectivityMetallic(metallic);
    half reflectivity = 1.0 - oneMinusReflectivity;
    half3 brdfDiffuse = albedo * oneMinusReflectivity;
    half3 brdfSpecular = lerp(kDieletricSpec.rgb, albedo, metallic);
#endif

    InitializeBRDFDataDirect(brdfDiffuse, brdfSpecular, reflectivity, oneMinusReflectivity, smoothness, alpha, outBRDFData);
}

#2
half3 EnvironmentBRDFSpecular(BRDFData brdfData, half fresnelTerm)
{
    float surfaceReduction = 1.0 / (brdfData.roughness2 + 1.0);
    //float c = surfaceReduction * lerp(brdfData.specular, brdfData.grazingTerm, fresnelTerm);
    float3 c = surfaceReduction * lerp(brdfData.specular, brdfData.grazingTerm, fresnelTerm);

    return c;
}

1번은 그렇다치고 2번은 half3의 specular을 lerp해서 float 값으로 반환해서 색이 이상하게 나오는 문제인데 의도한거 같지는 않고 버그가 아닐까 생각한다.

#3
float DistanceAttenuation(float distanceSqr, half2 distanceAttenuation)
{
    // We use a shared distance attenuation for additional directional and puctual lights
    // for directional lights attenuation will be 1
    float lightAtten = rcp(distanceSqr);

//#if SHADER_HINT_NICE_QUALITY
    // Use the smoothing factor also used in the Unity lightmapper.
    half factor = distanceSqr * distanceAttenuation.x;
    half smoothFactor = saturate(1.0h - factor * factor);
    smoothFactor = smoothFactor * smoothFactor;
//#else
    // We need to smoothly fade attenuation to light range. We start fading linearly at 80% of light range
    // Therefore:
    // fadeDistance = (0.8 * 0.8 * lightRangeSq)
    // smoothFactor = (lightRangeSqr - distanceSqr) / (lightRangeSqr - fadeDistance)
    // We can rewrite that to fit a MAD by doing
    // distanceSqr * (1.0 / (fadeDistanceSqr - lightRangeSqr)) + (-lightRangeSqr / (fadeDistanceSqr - lightRangeSqr)
    // distanceSqr *        distanceAttenuation.y            +             distanceAttenuation.z
    half smoothFactor = saturate(distanceSqr * distanceAttenuation.x + distanceAttenuation.y);
//#endif
    return lightAtten * smoothFactor;
}

3번은 색이 이상하게 나오는 수준이 아니라 아예 깨져서 나왔는데 원래 2019에서 모바일과 에디터 환경에서 색이 다르게 나오는게 문제가 있어서 분기문을 지우고 SHADER_HINT_NICE_QUALITY 쪽 코드를 사용 했는데 2020에서는 오히려 파랑색쪽 코드를 사용하니깐 기존 색이 유지되고 이상하게 색이 깨지는 문제도 발생하지 않아서 수정했다.

일단 정상적으로 플레이 가능하도록 수정하는 작업이 끝나면 원인도 찾아봐야겠다.

2021년 12월 15일 수요일

Coroutine과 Task를 사용할 때 DeadLock

Coroutine과 Task를 사용할 때 DeadLock


버그 리포트를 처리 하던 중 처음 보는 유형의 버그를 처리해서 기록하려한다.

버그의 내용은 아래와 같다.

1.아이폰7에서 플레이를 했다.
2.게임에 들어간 직후 자동사냥을 한다.
3.게임이 멈춘 후 시간이 지난 후에 크래쉬가 난다.

시트의 내용을 처음 봤을 때 오래 걸릴 것이라고 바로 생각했다.

지금까지 경험으로 봤을 때 특정 기종 + 크래쉬 조합은 찾기가 제법 까다로웠기 때문이다.

직접 테스트 결과 100% 발생하는 것은 아니고 간혈적으로 일어 난다는 것을 깨닫았다.
혹시 다른 기종도 문제일까 ipad 12.9 5th로 여러 차례 테스트를 해봤지만 재현이 되지 않았다.
Android도 갤럭시 노트 10+로 테스트를 여러 차례 해보았지만 재현이 되지 않았다.

특정 기종 + 간혈적 + 크래쉬라는 3중고에 빠져서 잠시 패닉이 왔지만
기적적으로 몇일 전에 테스트 했을 때가 기억이 났다.

이 문제를 해결하기 전에 나는 메모리를 최대한 줄일 수 있는 것들을 테스트 하고 있었고 그 중에 이펙트 풀을 하 옵션에서는 로드를 안하는 것을 테스트를 했었는데, 단순히 미리 로드만 안하도록 막자 유니티에서 게임이 멈추는 것을 경험했었다.

다만 이 때는 멀쩡한 코드를 내가 잘못 수정했기 때문에 발생한 현상이라고 생각했고, 나에게 메모리를 줄일 수 있는 시간이 넉넉하지 않아서 로드 뿐만 아니라 호출하는 부분도 모두 막아서 테스트를 했었다.

아무튼 결과 적으로 이 과정에서 프리징을 겪었던게 큰 도움이 됐다. 그렇지 않았으면 아마 나는 이 문제에 더 많은 시간을 투자했어야 했을 테니깐

해당 스크립트로 찾아가 게임이 멈출만한 코드를 모두 찾은 후에 소거법으로 현상을 재현하는 것에 성공했다. 사실상 여기서 문제 해결은 90% 끝난 것이다.

다만 왜 게임이 프리징이 걸리는지 생각하는데 좀 더 많은 시간이 걸렸을 뿐

자세한 설명은 뒤에 더 하겠지만 요약하자면 'Unity에서만 작업을 하면서 비동기적인 작업을 할 때 Coroutine밖에 사용할 일이 거의 없다보니 Task가 어떻게 동작하는지 알지 못했기 때문이다' 

뒤를 돌아보니 인터넷에 자주 나오는 케이스이며 매우 쉬운 문제였다.
아래는 문제가 일어났던 코드를 간단히 요약한 코드이다.

    //이펙트 풀링
    Dictionary<int,GameObject> dic;

    //특정 상황에 사용하는 오브젝트
    GameObject go;

    //게임에 들어갈때 이펙트들을 비동기로 풀링한다.
    public void Init()
    {
        StartCoroutine(LoadObject());
    }
    IEnumerator LoadObject()
    {
        for (int i = 0; i < 100;++i)
        {
            var v = Addressables.LoadAssetAsync<GameObject>(i);
            yield return v;
            dic.Add(i,v.Result);        
        }
    }

 // 이펙트를 가져오는 코드 풀링이 이미 되어 있으면 오브젝트를 바로 가져오고 없으면 생성
 // 필자가 만든 코드는 아니지만 추측해보건데 IEnumerator를 사용 못하는 코드에서도 간단히 사용 할 수 있어서 이런식으로 작성한 것으로 보인다.

    async Task<GameObject> Load(int id)
    {
        if (!dic.ContainsKey(id))
        {
            var v = await Addressables.LoadAssetAsync<GameObject>(id).Task;
            dic.Add(id, v);
        }

        if (dic.ContainsKey(id))
        {
            return dic[id];
        }

        return null;
    }

  // 게임을 멈추는 코드
    IEnumerator Set(int id)
    {
        var task = Load(id);
        yield return task;

        //프리징
        go = task.Result;
    }



결론부터 이야기 하면 예를 들어 유니티에서 자주 사용하는 Coroutine에서 yield return Addressables.LoadAssetAsync를 하면 해당 구문은 load가 끝날 때까지 기다리고 완료가 되면 return되서 넘어간다.

하지만 Task의 경우(위 코드의 async Task<GameObject> Load) 해당 코드안에 Task는 작업이 완료가 되지 않아도 완료가 되지 않았다는 내용의 Task가 return된다.

그럼 결국 yield return task; 구문은 아무런 영향이 없이 task.Result를 실행하게 되고 비완료된 Task에서 Result를 실행할 경우 컨텍스트를 동기적으로 차단하게 되고 결국 그 후에 
Task Load가 완료 되더라도 이것이 컨텍스트가 이용가능 할 때까지 기다리기 때문에 교착상태 즉 deadlock이 발생해서 유니티의 메인쓰레드가 멈춰버린것이였다....

그럼 다시 처음으로 돌아가서 왜 지금까지 재현이 되지 않다가 아이폰7에서 재현이 되었나?
- 게임에 들어가서 Load함수를 호출 할 때 이미 로드가 된 상태면 바로 반환을 해주기 때문에 task.Result를 사용해도 아무런 이상이 없다. 즉 휴대폰에 성능이 좋은 폰이거나 게임에 들어가서 바로 혹은 빠르게 함수를 사용 하는 케이스가 아니면 보기 힘든 문제였다는 것이다.

간혈적으로 일어난 이유
- 해당 함수는 몬스터가 죽고 드랍아이템이 나올 때만 호출되는데 게임에 접속 후 빠르게 사냥을 했을 해도 드랍아이템이 나오는 것은 확률적이였기 때문

크래쉬가 난 이유
- 오래 동안 멈춰있어서 OS에서 앱을 죽였다.

그럼 해결을 어떻게 하면 되느냐 Set 함수가 async 였다면 await로 끝날 일이지만 Coroutine으로 되어 있었기 때문에 아래처럼 코드를 수정했다.

    IEnumerator Set(int id)
    {
        var task = Load(id);
        yield return new WaitUntil(() => task.IsCompleted);
        go = task.Result;
    }


간단하다 task가 완료 될 때까지 정상적으로 기다리게 수정해주면 해결이 된다.

게임이 바로 크래쉬가 나는건 여러번 경험해봤지만 오버플로를 제외하고는 멈추는것은 보지 못했는데 빨리 찾아서 다행인 버그였다.