오브젝트가 파괴되는 부분에 대한 코드를 만든지 오래되서 기억이 가물하여 한참을 들여다봄. 프로그램팀에서 좀더 효과적으로 코드를 고친거 같음. 이해가 안가는건 물체가 파괴되고 파편이 콜리더가 있어야 부디칠텐데.. 프로그램팀에서 파괴와 동시에 콜리더를 같이 사라지게 만들어놨음...?? 내가 이렇게 설계를 할리 없는데...
Setpass Call 수치가 너무 높아서 계속 추적한 결과.. Gpu instance 때문이었군요. 너무 적은 양의 오브젝트들에 GPU instance가 적용되어 그 적은양의 오브젝트가 Setpass Call에 부담을 주고 있었습니다.
GPU instance 사용함에 있어서 경고가 있는데, 너무 적은 양의 오브젝트에는 사용하지 말라는것인데... 적절한 비율을 잘 맞춰야 하는데... 첫배경에서 너무 잘 사용하면서 이번에도 좋을거라 생각하고 별 생각없이 적용하다보니,Setpass Call 량이 늘어나는 불상사가 일어났음... 뭐든 맹신하면 안된다는...
AD가 왜 게임에서는 우리 일상처럼 그림자가 안에 그림자가 없는지 물어봤습니다. 게임에서는 실시간 난반사가 없기 때문이고 이것을 구현하려면 따로 해야한다고 설명해주었습니다. 게임속에 라이트는 물체와 라이트간의 관계라기 보다는 물체가 독립적으로 빛을 받았느냐로 판단하지 주변 물체에 대해서 인지않기 때문...라이트도 이름이 라이트이지 그냥 여기서 빛을 쏴준다는 개념이라눈... 그래서 우리는 환경광을 사용하기는 하는데 이게 완전하질 않죠...
오브젝트 애니메이션이 이상하게 안나오는 문제가 있었는데, 이벤트처리를 이전 작업자가 해둔걸 못찾았기 때문이었네요. 유니티에서는 정상적으로 보이는데 ,빌드시에 cloth 오브젝트가 사라지는 문제가 발생했는데, 아마도 중력에 의해 바닥으로 떨어진것으로 보입니다. 이전 리소스와 비교해보니, cloth 오브젝트에 리깅이 안되어있었음...해결...(여전히 의문점은... 왜 유니티에서는 정상적으로 보이고 빌드시 문제가 발생하는지 모르겠음.)
다른 스테이지에 비해서 새로 만든 스테이지에 동적인 화면이 아닌데, frame 폭이 너무 많이 나는것이 이상해서 이것저것 테스트했던 결과.. 작업자가 월드 바닥에 바다를 깔아두면서 보이지도 않는 부분에서 전체적으로 드로우가 되면서 포퍼먼스를 잡아먹었던걸로 추정... 바다를 쪼개서 육지쪽 바닥 밑에는 바다를 없앴더니...frame 2~3에서 왔다갔다하는걸 보니 안정화 된거 같군요.
외주에서 만든 shader와 내부 shader를 하나로 만드는 작업을 진행했습니다. 포인트는 기존에 material이 바뀌지 않도록 Boolean(shadergraph에서는 Branch)으로 추가.
움직이고 파괴되는 오브젝트 작업진행.(이건 너무 예전에 구현해서 기억이 가물하다.. 시간이 필요할듯하군요.) 외주업체가 오브젝트를 너무 복잡하게 구조를 만들어놔서 단순화. 오브젝트에 cloth적용작업.
영상을 찍어야 한다고 안티엘리어싱 설정을 할수 없냐고 문의가 왔습니다. 우리는 Deferred라 후처리 기법을 써야해서 camera에 SMAA을 사용하도록 알려줬습니다. 코드는 아래부분인거 같은데, 알려줬으니..프로그램에서 알아서 하겠지.. cameraGameObject.GetComponent PostProcessLayer>().antialiasingMode = PostProcessLayer.Antialiasing.None; 이 코드가 아닌갑다...(레거시에서 했던 설정인가봄.)
계속 build시 gpu instance관련 오브젝트가 안 나오는 문제 발생. shadervariants 설정이 잘못되어서 그런 걸로 추정... 아니었고...scene이 꼬인 상태로 작업이 진행돼서 build시 안 나오는 오브젝트가 발생. 다시 작업. (물체를 복사하거나 이동시키면서 발생된 문제일 거라 추정) 결론은 아트 쪽 문제는 아니었고, Jenkins에서 svn을 revert 시키질 않아서 생긴 문제였다는... 요즘 들어 svn revert 이슈가 많이 일어나고 있었군요.
vertex paint와 texture mask를 이용한 lerp방식에 대한 고민... 결론... vertex painter가 비교적 덜 무거우니...그걸로..
유니티 원문에는 이기능은 scene을 로드하기만해도 자동으로 수집되기 때문에 shadervariant 파일이 있기만 해도 된다는 식으로 써있지만, 이기능을 어떻게 사용하는지 명확한 설명이 없어서 저처럼 헤메는 일이 없도록 공유해봅니다.
우선 중요한 것은 하나의 scene에 사용되는 모든 material을 모아야 합니다. 여러 scene을 돌아가면서 로드해도 되는데,
문제는 그렇게 하려면 게임을 실행시켜서 모든 scene을 돌아가면서 열어야 하는 번거로움이 있습니다.
수동으로 shader를 기능에 등록만 하면 되지 않을까 생각하지만, 이 기능은 material에서 실제 사용되는 옵션을 저장하는 방식을 가지고 있기 때문에 작업자가 이 옵션을 일일히 넣는다는건 유니티에 shader에 대해 완전히 파악한 사람이 아니고서는 솔직히 어려움이 있습니다. 또한, 여러 shader를 만들었다면...생각만해도.. 끔찍...
그래서 저는 일단 모든 material을 하나의 Scene에 모으는 툴을 프로그램머분에게 요청하고, 그리고 이를 Shadervaiant로 저장하는 방법을 택하였습니다. 다음 영상은 Shadervaiant을 생성하는 과정입니다.
(Clear를 누르고 씬을 저장하고 게임실행하고 Save to asset 한번 눌러주고 하면 수치가 일정하게 나오는거 같습니다.
이순서가 중요한거 같네요.)
간혹 숫자가 자꾸 변경이된다면, 이펙트와 같은 렌덤이 있는 오브젝트가 있을수 있으니 이런 부분은 제거하여야 합니다.
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class find : MonoBehaviour
{
// Start is called before the first frame update
void Start()
{
MeshRenderer ms = GetComponent<MeshRenderer>();
ms.renderingLayerMask = 2;
ms.renderingLayerMask = 3;
}
// Update is called once per frame
void Update()
{
}
}
저는 medium을 현시점 많이 사용되는 GTX 1060을 기준으로 잡았습니다. Low는 GTX 970 정도로 High는 3060 정도로...
아래는 제가 개발하던 게임을 각각 하드웨어에서 60fps가 나오도록 체크하면서 세팅한 값입니다. 좋은 기준이 되리라 생각됩니다.(게임 따라 다르겠지만, 비슷하지 않을까 생각됩니다.) 보시면 대략적으로 수치를 낮춘 것이 low이며, High는 높게 설정한 겁니다. 각각의 기능에 대한 내용은 유니티 문서를 참고하시기 바랍니다. (저는 Foward Only로 설정하였습니다만, Raytracing이 효과적인 게임과 많은 수의 실시간 라이팅이 요구되는 게임은 Deferred Only 세팅을 하는 것이 맞으리라 생각됩니다.)
Max shadow resolution을 256 이하로 지나치게 낮추면 오히려 역효과라는 것이 이 부분에서는 중요한 포인트라고 할 수 있습니다.(이유는 모르겠으나 프레임 저하가 더 많이 발생하였습니다.)
Low의 경우 설정만으로 Frame이 나오질 않아서 폴리곤 외에도 카메라의 TAA설정과 포스트 프로세싱 자체를 꺼서 Low에서 원활히 돌아가도록 설정하였습니다.
☆ 추가내용 정확한 원인은 알수는 없었지만 저희게임은 운동장에 디렉션 라이트가 하나만 있는 상황이었는데 gtx 750에서 deferred 가 forward보다 5~10프레임의 이득인 효과를 보았습니다. 원칙적으로 따지면 조명이 하나라서 포워드가 빨라야한다고 생각했지만 디퍼드가 더 효과가 좋았습니다.