어영부영TA (AI신과함께)

Unity 프로파일러의 타임라인에서 각 컬러는 특정 작업 또는 작업 범주를 나타냅니다. 주어진 이미지에 기반하여, 컬러별로 주요 작업을 나열하면 다음과 같습니다:

초록색: 렌더링 (Rendering)

하늘색: 스크립트 (Scripts)

주황색: 물리 (Physics)

연한 청록색: 애니메이션 관련 작업 (Animation)

올리브색: 가비지(Garbage Collector)
노란색: VSync

붉은색: 글로벌 (Global Illumination)
보라색: UI 작업 (UI)

올리브색(?): 기타(Others)

전체적으로 해석하자면, 스크립트 > 기타 > 애니메이션 >= 랜더링 순으로 비중이 높은걸 알수 있습니다.

애니메이터분들이 아웃게임 파트의 애니메이션을 볼 만한 적당한 기능이 없어 작업을 추가하였습니다.

문제는 기존 애니메이션 툴이 인게임 전용으로 만들어져 있다 보니, 약간에 고민이 되었습니다.

하여, 아웃게임 애니메이션을 확인할때는 인게임이 작동하지 않는 구조로 구성하였습니다.

(말은 거창하지만 그냥 온/오프)

그래서 버튼이 비활성화되는 구조의 스크립트를 추가하였습니다.

#if UNITY_EDITOR // 빌드시 영향이 없게 유니티에서만 돌아가게 하면 좋다.

public class PlayAnimation : MonoBehaviour
{
    private Animator animator;
    public Button[] targetButtons;  // 여러 버튼을 이 배열에 연결

    private void Awake()
    {
        animator = FindObjectOfType<Animator>();
    }

    private void Start()
    {
        // 시작할 때 MainTest 오브젝트가 존재하는지 확인
        if (GameObject.Find("MainTest") != null)
        {
            // MainTest 오브젝트가 존재하면 모든 버튼을 비활성화
            foreach (Button btn in targetButtons)
            {
                btn.gameObject.SetActive(false);
            }
        }
    }
    
    #endif

High Definition RP version 12.1.7 에는 alpha 버그가 있습니다.

Shader Graph로 제작할 때 처음 알파값에 0 이하값이 들어가면 Shader가 무슨 이유인지 그 뒤로 알파가 안 되는 버그를 가지고 있습니다.

그래서 처음에 커스텀 셰이더를 제작 시에 알파부터 0 이하로 세팅이 되지 않도록 세팅을 하고 저장을 하면 그 뒤로 0을 넣어도 문제가 안 생깁니다.

알고 있던 버그인데 까먹어서 다시 한참을 헤매었네요.

이번에 캐릭터에 있는 투명 파이프를 표현하기 위해서 셰이더를 제작하였습니다.

헌데, 빌드전에는 에러가 없었는데, 화면에 그림은 제대로 그리면서 빌드하면 셰이더가 에러가 납니다.

빌드시 나는 에러는 대략 _MainTex가 없다는 메세지 였습니다.

_MainTex가 필요 없어서 만들지 않고 컬러만으로 조정해야하는 셰이더인데... 이게 왜 빌드시 문제가 되는지...

그래서 별 쓸모는 없지만, _MainTex관련 노드를 추가하였더니, 에러가 사라졌군요.

유니티 버전 2021.3.5f1을 사용하는데 _MainTex가 대부분 셰이더에 들어가서 몰랐는데, 없으면 에러가 나는 버그가 있군요.

더보기

Depth Write를 이용하면 버블이 카메라 위치에 따라 생겼다가 없어졌다 하는 효과가 있습니다.

캐릭터의 땀을 표현하는 노드를 구성중입니다.

문제는 이미 상당히 많은 캐릭터가 만들어져 있고, 캐릭터 얼굴의 UV 위치가 서로 다르기 때문에 캐릭터마다 텍스쳐를 한 장씩 추가한다는 건 좀 무리일 수 있습니다.

그러면, 어떻게 하면 한장의 텍스쳐로 처리할 수 있을까? 고민을 하였습니다.

그러다가 문득 생각이 들었습니다. 땀을 이루는 텍스쳐는 어차피 smoothness를 lerp처리할 것인데 캐릭터의 바디의 위치에 맞춰 텍스쳐의 Offset을 이동하여 조종하면 어떤가라는 생각이 들었습니다.

이 방법이 맞았습니다. 물론 UV에 따라 크고 작고 그런점이 있긴 하지만, 대략적으로 맞출 수 있을듯하네요.

시간에 따라 땀이 점점 발생하도록 구성하였습니다.

초기 HDRP 테스트했을 때 나라카가 DLSS을 사용하여 효과를 냈다는 글을 보고 저사양에서 테스트했었는데, 프레임 효과는 있지만, 품질이 좋지 않아서 포기했었습니다.

근데, 최고사양에서 최고 퀄리티인데 특정 맵에서 해상도가 2048로 플레이하면 프레임이 50 프레임대로 떨어진다고 하여 이 문제를 DLSS로 해결하는 게 어떤가라는 생각이 들어 테스트해보았습니다.

사실, DLSS은 오늘 3.5버전을 발표하였습니다. 이걸 보고 다시 한번 테스트하게 된 것인데 결론은.. 실패...

DLSS는 쉽게 이야기하면 원래 해상도가 2048인 모드에서 1024 이미지를 2048로 기술적으로 뻥튀기시키서 2048로 만들어서 포퍼먼스를 개선시키는 기능입니다.
업스케일이라고도 하는데 NVIDIA만 되는 AI 기술(?)이라고 합니다.

하여간... 테스트 하였는데, 숲이라 알파가 많은 오브젝트에서는 번짐 현상이 심하고 지글거림이 발생하여 포퍼먼스가 문제가 아니라 퀄리티가 떨어져서 다시 보류하였습니다. 제가 잘 몰라서 이런 결과가 나온 건지는 모르겠습니다만... 아직은 범용적인 기술도 아니라서 일단은 보류하기로...

애니메이션이 너무 빨라 리깅에 문제가 있는지 알수가 없는경우가 있어서 애니메이션 테스트 툴에 속도를 조종하는 스크립트를 추가하였습니다. (과거에는 이거 하나 넣는데 엄청난 시간을 들였을건데... GPT형이 너무 고마워...)

using UnityEngine;
using UnityEngine.UI;

public class TimeScaleHandler : MonoBehaviour
{
    // 게임 속도를 변경하려는 원하는 값으로 설정
    public float desiredTimeScale = 0.5f;
    public Slider timeScaleSlider; // UI 슬라이더 참조

    private void Start()
    {
        // 시작할 때, 원하는 시간 흐름 속도로 변경
        Time.timeScale = desiredTimeScale;
        timeScaleSlider.value = desiredTimeScale; // 슬라이더 초기값 설정

        // 슬라이더의 값을 변경할 때 발생하는 이벤트를 연결
        timeScaleSlider.onValueChanged.AddListener(OnTimeScaleChanged);
    }

    // 이벤트가 발생 했을 때 호출되는 이벤트 핸들러
    private void OnTimeScaleChanged(float value)
    {
        Time.timeScale = value;
    }
}

젠킨스를 다른 컴퓨터에 새로 추가하는 작업을 하였는데, 여러 문제가 발생해서 기록해 둡니다.

우선 젠킨스 사이트에서 다운로드 https://www.jenkins.io/  

바로 다운받고, 설치를 하시면 됩니다. (이 과정도 복잡한데.. 인터넷에 많이 있어서.. 생략...)

젠킨스를 설치하시고 난 뒤에 반드시 해야 할 유니티 관련 세팅이 있습니다.

이것들을 안 하면 빌드가 제대로 안됩니다. 이번 포스팅은 이것 때문에 작성한 것입니다.

Visual Studio와 C++ 빌드 도구 및 Windows 10 SDK가 설치되어야 합니다.

빌드는 실패는 했는데, 너무 많은 메시지가 있어서 뭐가 잘못되었지 한참을 찾아봤었네요.

svn 주소가 변경이 되어서 젠킨스도 마찬가지로 주소를 변경하였는데...

에러가남.. 

svn: E170013: Unable to connect to a repository at URL 'https://xxx.xxx.xxx:xxxx/svn/Project'
svn: E215004: No more credentials or we tried too many times.

젠킨스 컴퓨터에서 svn 업데이트도 잘되고 주소도 잘 변경되었는데...

계속 문제가 발생....

인터넷에서 좀 찾아보니...인증에 문제일수 있다는 내용을 찾았습니다.

탐색기 창에 %APPDATA%\Subversion\auth 을 넣고 Enter를 치면 아래 폴더가 나옵니다.

svn.simple과 svn.ssl.server 폴더 안에 내용을 모두 삭제

그리고 다시 인증을 하니 젠킨스 빌드가 정상적으로 됩니다.

꼭 빌드 마감날에....이런일이 발생한다눈...

우리게임에 향상을 위해서 Vulkan에 대해서 다시 한번 조사를 해보았습니다. 그리고 테스트도 진행중입니다.

Vulkan API는 2016년 초반에 출시되었으며, 이 시점부터 그래픽 카드 제조사들은 대부분의 현대 하드웨어에 Vulkan 지원을 도입하기 시작했습니다. 각 GPU 제조사(NVIDIA, AMD, Intel)별로 최초로 Vulkan을 지원하는 그래픽 카드는 다음과 같습니다.

- NVIDIA: GeForce GTX 600 시리즈부터 (Kepler 아키텍처 기반) Vulkan 지원이 도입되었습니다. 예를 들면, GeForce GTX 680이 이에 해당합니다.
- AMD: AMD의 경우, Radeon HD 7000 시리즈부터 (GCN 아키텍처 기반) Vulkan 지원이 도입되었습니다. Radeon HD 7970 등이 이에 해당합니다.
- Intel: 6th Generation Intel Core 프로세서 (Skylake 아키텍처)부터 Vulkan을 지원하는 내장 GPU를 제공하였습니다. 예를 들면, Intel HD Graphics 520이 이에 해당합니다.

위의 그래픽 카드 및 프로세서는 Vulkan 지원의 시작이나 최소 요구 사항에 해당하는 것으로, 최신 Vulkan 기능을 모두 지원하지는 않을 수 있습니다. 최신 기능을 완전히 활용하려면 업데이트된 그래픽 카드 및 드라이버를 사용해야 합니다.


Vulkan을 사용하면 일부 게임에서 Direct3D11보다 FPS가 효과적으로 향상될 수 있다고 합니다.

1. 저수준 제어: Vulkan은 저수준 그래픽 API로서 개발자가 GPU 작업에 대한 세밀한 제어를 할 수 있게 해줍니다. 이를 통해 자원 관리와 성능 최적화를 개선할 수 있습니다.

2. 멀티스레딩 최적화: Vulkan은 실행 시에 멀티 스레딩에 적합한 향상된 지원을 제공합니다. 이를 통해 멀티 코어 프로세서의 성능을 최대한 활용하여 더 나은 성능을 제공할 수 있습니다.

3. 드라이버 오버헤드 축소: Vulkan은 그래픽 드라이버의 오버헤드를 최소화하기 위해 설계되었습니다. 이를 통해 안정적이 건 효율적인 그래픽 처리 성능이 개선됩니다.

4. 더 작은 API: Direct3D보다 Vulkan은 더 작은 API입니다. 이것은 API 호출 및 오버헤드를 줄임으로써 빠른 렌더링을 가능하게 합니다.

5. 안정성: Vulkan은 안정성 면에서 DirectX보다 더 나은 성능을 제공합니다. 이는 Vulkan API의 명시성 및 안정성과 관련이 있습니다.

그러나 Vulkan이 무조건 모든 경우에서 Direct3D11보다 우수한 성능을 제공한다고 단정짓긴 어렵습니다. 성능 향상은 게임 개발자가 얼마나 Vulkan을 최적화하여 사용하는지, 그리고 실행되는 플랫폼 및 하드웨어가 어떤지에 따라 다릅니다. 적절한 호환성 및 성능을 위해 일부 게임 개발자들은 여전히 Vulkan과 Direct3D11을 동시에 지원하는 게임을 개발합니다.

결론적으로, Vulkan을 사용하면 게임에서 Direct3D11보다 FPS가 효과적으로 향상될 수 있지만, 성능에 영향을 미치는 여러 요인을 고려해야 합니다. 게임 개발자는 하드웨어 및 플랫폼, 그러한 기술의 최적화 수준을 고려하여 최상의 그래픽 API를 선택해야 합니다.

Vulkan은 Windows 10 이상, Linux 4.5 이상, iOS 11 이상, Android 7.0 이상에서 지원됩니다.