[UE4] 언리얼 엔진에 오신 것을 환영합니다

• 언리얼 엔진에 오신 것을 환영합니다.

• 언리얼 공식 동영상 튜토리얼의 내용을 정리한 문서.

언리얼 엔진4와의 첫시간

머티리얼

• 메시의 외관에 영향을 주는것.

• 머티리얼은 라이팅에 반응항다.

• 뭔가를 보려면 라이트가 있어야한다.

Directional Light

• 태양을 시뮬레이션하는 아이템

디폴트 캐릭터

• 어딘가에 스폰된다.

• 플레이어 스타트나 카메라 위치(뷰포트의)에 스폰된다.

• 액터배치-> 기본 -> 플레이어 스타트

• 플레이어 스타트의 파란색 화살표가 정면을 뜻함.

• 플레이어 스타트의 위치를 조정할 때 플레이어가 바닥과 겹치면 BAD SIZE가 표시됨.

스카이 애트머스피어

• 월드의 가장 윗부분이나 대기를 나타냄

• 디렉셔널 라이트에서 애트머스피어의 작동방식을 결정해야함.

  • sun light 설정: 디렉셔널 라이트가 애트머스피어와 상호작용할 수 있게 해줌
  • 태양이 디렉셔널 라이트에 따라 회전한다.

light

• 디렉셔널 라이트 -> intensity 조절하여 밝기 설정
• 이미시브 라이팅 사용 => self-lit : lighting 영향 받지 않음, 전체적인 광원이 없어도 보임.
• sky light => 앰비언트 라이트: 어두운곳의 밝기, 그림자 속 라이트, 어떤 것 뒤의 라이트
• 그림자 속 라이팅 : 앰비언트, 바운스 라이팅처럼 어디든 있는 라이팅
  • 이 밝기는 장소에 따라 밝기가 달라짐, 자동노출(auto exposure)이나 시각 순응(eye adaptation)
  • 어두운곳에 가면 이 라이트는 밝아짐, 밝은 곳으로 가면 어두워짐
• PostProcessVolume: Lens의 Exposure 에서 최소 최대 밝기. -> 범위== 이펙트의 차이
  • 1로 최대최소 설정해주면 어두운부분이 약간 어두워지고, 밝은곳은 더 어두워지지않음
• 라이트 블룸, 오클루전 라이트 새프트
  • 라이트 새프트: 디렉셔널 라이트에서 shaft occlusion, shaft bloom 설정하면 빛줄기가 생김. tint를 설정하여 푸른 안개 효과 낼 수 있음

모빌리티 세팅

• 씬에서 라이팅이 어떻게 쓰이는지를 결정한다.
• movable: 완전히 동적이라는 뜻, 모든것에 새도우, 실시간으로 라이팅이 적용됨, 퍼포먼스 가장 많이 소비
  • 모든 프레임이 정보를 하나하나 계산한다.
• static: 프로젝트가 돌아가기 전부터 모든게 미리 결정, 프레임마다 계산할 필요가 없음. 퍼포머스 가장 적음.
  • 라이트 맵을 사용한다거나, 굽는다고 함.
  • 이 세팅을 키면 화면 위에 라이팅을 다시 빌드해야 뜸.

• stationary: 두 옵션을 섞은것

• 프리뷰가 그림자에 나타나면 -> 빌드 -> 라이팅 빌드

블루프린트

• 블루프틴트는 요소의 모음, mesh일 수 도 있다.(Viewport)

• 뷰포트에서 구체는 콜리전, 플레이어가 밟으면 이벤트 발생

• 뭔가를 재사용하기 좋다.

• 에딧 -> 프로젝트 세팅
  • 맵&모드와 입력이 중요
  • 맵모드: 일부 게임 프레임워크나 언리얼 엔진의 유용한 기능을 설정한다.
    • 디폴트 폰 또는 디폴트 플레이어, 화면 뒤의 사람을 나타내는 디폴트 대상이 뭔지 등에 대해, HUD가 있는지, 컨트롤러 클래스가 뭔지(캐릭터에 대한 입력을 모방)
  • 입력: 입력세팅=> 커스텀 캐릭의 세팅과 기본 세팅과 일치하게 해야한다.
    • 동일한 키와 입력에 여러 입력을 매핑할 수 있다.
• 캐릭터 컴포넌트 -> 여러 변수 설정 가능(점프 최대 높이 등)

월드 아웃라이너

• 월드를 구성하는 모든 액터가 포함되어있는 패널
• 폴더생성가능 (폴더 삭제시 계층 구조의 루트로 다시 돌아감.)
• 부모-자손관계를 사용할 수 있음
  • 라이트를 블루프린트로 드래그하여 자손으로 종속시키면, 함께이동
• 한번에 여러 항목 영향: 전부 선택 -> 우클릭, 그룹선택 or 컨트롤 G

디테일 패널

• 현재 선택된 항목과 컴포넌트, 그리고 그 프로퍼티를 표시
• 프로퍼티 값을 변경하고, 컴포넌트를 추가하고, 선택된 항목을 블루프린트로 변환

• 다수의 디테일 패널을 사용하여 항목간의 프로퍼티를 서로 맞춤.

• Show hidden properties while playing: 플레이 도중 숨겨진 프로퍼티 표시
• 한 아이템의 프로퍼티를 다른 프로퍼티로 복사
  • 에디터에는 프로퍼티 매트릭스가 있음. (눈동자 모양 옆에 있는 프로퍼티 매트릭스-> 선택 열기)
  • 선택한 아이템과 공통 프로퍼티가 표시 -> 한번에 모두 같이 변경 가능
• 두 개의 다른 아이템 옵션 비교
  • window->details 에서 디테일 패널을 4개 까지 열 수 있음.
  • 디데일창의 락버튼을 사용하여 비교
• 오브젝트 프로퍼티와 옵션이 표시, 런타임이나 에디터에서 확인하거나 변경 가능.

문제1

1. 씬에 게임 안에서 볼 때만 실행되는 파티클 이펙트가 있습니다. 파티클 이펙트 실행을 확인하는 가장 빠른 방법은 무엇일까요?
   • G키 게임뷰

언리얼 엔진 소개

모드 패널

• 왼상단
• 윈도우 -> 모드
• 모드 설정 -> 랜드스케이프, 폴리지 시 아웃라이너, 뷰포트 설정 못함
  • 적절한 모드 사용, 실수할 가능성 높음

콘텐츠 브라우저

• 저장장치, 파일구조
• 프로젝트에 포함된 파일들
• 윈도우 -> 콘텐츠 브라우저: 창을 4개까지 추가 가능
• 폴더에 우클릭, 색변경가능.
• view type-show
  • developer content: 나만의 전용 콘텐츠로 임시 영역과 같다.
    • 프로젝트에 문제가 발생하길 원하지 않을 경우
  • 엔진 콘텐츠: 엔진에서 제공되는 콘텐츠.
    • 간편하게 바로 쓸 수 있는 콘텐츠가 많음.
• 컬렉션
  • 정적: 구성 가능한 항목에 대한 바로가기 옵션
  • 동적: 검색

메인툴바

• 프로젝트 작업시 사용함
• 아이템생성, 월드 생성
• 소스콘트롤: git
• 세팅: 프로젝트, 에디터, 플러그인
  • 기본적으로 반투명 아이템은 선택 불가능 (마티리얼이 반투명), 세팅에서 허용 설정(allow translucent selection), T키
  • 엔진 퀄리티 세팅: 변경내용은 에디터에만 영향, 최종 제품에 영향 x(머티리얼 퀄리티 또한 마찬가지)
  • 사운드 조절(게임 플레이시 제외한 사운드 크기)
• 레벨 블루포인트: 레벨에서 직접 액터와 같은 오브젝트를 참조, 연속된 블루프린트를 트리거링 또는 시네마틱 기능에 사용.
• play->시뮬레이션: 씬에서 시뮬레이션 설정을 킨다.
  • 뷰포트에서 시뮬레이션 보기 가능(실행중인 피직스나 파티클 )

세팅

에디터 개인설정 창

• 에디터가 작업을 수행하고 작동하는 방식에 대한 개인 설정, 세팅, 옵션을 변경할 때
• 편집-> 개인설정-> 에디터 개인설정

프로젝트 세팅

• 게임 모드를 오버라이드하여 전체 프로젝트에 적용가능
• 편집-> 프로젝트 세팅 or 툴바 -> 세팅->프로젝트 세팅
• 게임
  • 게임전용프레임워크 세팅
• 엔진
  • 프로젝트에 대해 엔진이 어떻게 설정되었는지
  • 입력이나 렌더링 설정방식
• 에디터
  • 프로젝트에서 에디터 각 부분을 처리하는 방식
• 플랫폼
  • 모든 플랫폼마다 고유의 아이템이 있음.
• 플러그인
  • 플러그인별로 프로젝트 고유의 세팅을 조정

프로젝트

• 프로젝트 이름, 퍼블리셔, 관련 정보들
• 맵모드
  • 멀티플레이어가 분할화면을 사용하는지 등.
  • Game Instance class
• 패키징
• 플랫폼 지원 설정

엔진

• 콜리전
  • 피직스를 사용할 때 아이템이 서로 상호작용할 때 사용됨.
  • 특정 아이템만 충돌하게 할 경우, 기본 콜리전은 제대로 작동하지 않을 수 있다.
• 인풋
  • 점프 이동 마우스 등 세팅
  • 마우스로 터치 시뮬, 기본 가상 조이스틱(모바일)
• 렌더링
  • default setting : 기본적으로 Bloom 활성화, Ambient Occlusion 활성화, Auto Exposure, Motion Blur 세팅
  • 포스트 프로세서 이펙트를 사용하거나, 카메라나 다른 세팅을 직접 조정하는것 대신 가능

에디터

• 레벨 시퀀스 세팅

플랫폼

• 플랫폼별 세팅 가능
  • direct, opengl, vulkan 설정

월드 세팅

• 현재 작업중인 레벨 고유의 세팅을 조정하거나, 오버라이드할 수 있다.
• 윈도우-> 월드 세팅, 툴바 -> 세팅 -> 월드 세팅

월드

• Kill Z 조정
  • 세로축, 액터가 이 기준 이하면 사라짐

게임모드

• 기본 게임 모드를 오버라이드
• 메인 메뉴가 있지만 일반게임모드에서 모든 기능이 다 필요하지는 않을 경우
  • 새로운 게임 모드를 만들고, GameMode Override를 해당 레벨에만 설정하는 것.

Lightmass

• 라이트매스 시스템은 양질의 결과를 제공할 수 있도록 설정되어있음.
• 라이트매스 시스템은 정적인 빌드된 라이팅.
• 라이팅을 빌드하고 굽는데 이 시스템이 사용된다.

• 이 세팅을 오버라이드하여 라이팅 퀄리티 개선,

• 구워진 라이팅을 사용하고 있지 않으면, 이 섹션은 걱정하지 않아도 된다.
• 대안은 Lightmaps => Force No Precomputed Light => 리빌드
• 이렇게하면 공간에 약간의 여유가 생긴다.(빌드된 라이트맵이 삭제되기 때문.)

Physics

• 기본 중력값 설정(오버라이드) 가능
  • water world를 설정할 경우 이 레벨의 중력값을 변경하려면, 이 설정을 변경하면됨.

VR시스템옵션

• World to Meters 월드 스케일 같은 기본설정을 변경할 수 있다.

Tick

• 레벨기준으로 설정
• 이 레벨에서는 틱속도를 조정할 수 있다.
• Mini/Max Global Time Dilation을 설정, Allow Tick Before Begin을 설정하면 시작전 틱을 허용할 수 있음.

• 이 설정은 월드 세팅에서 오버라이드할 수 있다.

  • 월드세팅은 작업중인 레벨 고유의 세팅창으로 여기에서 레벨 전용 세팅을 오버라이드하고 조정할 수 있다.

문제2

1. 프로젝트에 독립 게임 모드가 필요한 메뉴에 쓸 레벨이 있습니다. 에디터 어디서 이 게임 모드를 설정할까요?

   • 월드 세팅

2. 에디터 실행 -> 기본으로 어떤 맵파일을 로드하도록 : 맵 모드 세팅

프로젝트 및 파일 구조 이해

.uproject

• 이 프로젝트가 엔진과 상호작용하는 방식에 대한 기본 설정을 포함
  • 버전, 플러그인, c++용 모듈, 플랫폼 등
• 게임을 실행할 수 있음.
  • 명령줄에 의해 실행되는 것으로 에디터에서 실행되는것과 동일
• 엔진 버전 변경가능
  • 에셋은 이전 버전과 호환되지 않음(주의)
• 소스cpp => vs 프로젝트 생성 가능
  • .uproject에 모듈이 생겨남. => 이 프로젝트와 연관시킬 코드
  • 모든 모듈 및 타깃, 프로젝트와 연관된 모든 소스코드를 찾아냄
  • 무언가를 활성화 하거나 비활성화 할 경우에만 편집
  • 플러그인 활성화 여부 확인 가능

프로젝트 폴더 구조

기본 구조

• CONFIG: 프로젝트별로 제어할 수 있는 설정
• CONTENT: 프로젝트의 모든 콘텐츠가 들어있다.
  • collections, developers (콘텐츠 브라우저의 컬렉션 표시등): 바로가기나 스크래치 파일
• SAVED: Intermediate폴더와 비슷, 확실한 경우가 아니면 제거x, 일단 삭제하면 그 안에 있던 내용물 재생성 불가, 게임의 실행 로그등,
  • 장애가 발생할 경우 엔진은 이 폴더를 살펴봄, 파일 및 폴더 복구를 시도.
• SOURCE: C++소스, 이 폴더가 없다면 프로젝트가 제대로 컴파일 x
  • 일부 코드가 제대로 작동 x, 뭔가 변경, 프로젝트 리셋 => 이 폴더를 삭제하는 방법(.uproject에서 모듈제거 ) => 블루프린트만 있는 프로젝트로 리셋 (비권장)

삭제 가능한 파일 및 폴더

• INTERMEDIATE: 프로젝트를 작성하고 엔진을 사용하는 중간단계에 사용하는 임시파일과 폴더를 보관 (삭제하면 프로젝트를 다시열 때 시간이 더 걸림, 매번 재생성, 교체 )
• vs 솔루션 파일(모듈감지, 다시 생성됨)
• .vs 폴더 (자동완성을 위한 임시 데이터, 기타 VS기능들)
• Binaries는 임시폴더.
  • 컴파일된 바이너리 코드, C++ 소스 모듈과 dll 파일
  • 프로젝트를 컴파일할 때 생성.
  • 프로젝트가 제대로 패키징되지 않는 문제 -> 이 폴더를 삭제하면 해결될 수 있음.(프로젝트 리셋)

캐시에 저장된 다운로드

• 프로젝트를 만들거나, 엔진에 아이템을 설치해야 아이템이 다운로드됨
• 런처 설정-> edit vault cache location : 기본 캐시 폴더

DDC 폴더

• 파생 데이터 캐시: 타깃 플랫폼에 대해 UE가 사용하는 특정 포맷, 에셋의 버전을 저장하는 캐시.
• 프로젝트 시작시간을 단축시켜줌
• Appdata>local>unrealengine

• 프로젝트 재실행시 셰이더를 다시 컴파일할 필요가 없음

• 각 버전에 대한 디렉터리, common 디렉터리
• DDC는 자체적으로 재생성, 필요에 따라 최신상태를 유지
• 필수는 아님, 재생성됨
• 폴더로 구성할 수 있으므로 공유할 수 있음(프로젝트 작업에 참여하는 사람들 모두가 같은 ddc사용 ) => 필요한 시간 단축

더 나은 파이프라인 구축

---

• 총 4가지 주제
  • Working with Others
  • Building Better 3D Meshes & Textures
  • Creating Materials & Material Instances
  • Performance & Optimization

소스컨트롤

---

• 대부분 Perforce 와 Subversion을 사용한다.
  • 데이터 동기화, push, pull, revert, add, remove data
• 반드시 최종 애셋만을 임포트해야함
  • 같은 메시의 다른 버전을 임포트하지말아야함.

더 나은 3D 메시와 텍스처1

---

• 명명 규칙, 알파 정보와 RGB 마스크 패킹, 처리하는 방법 등.
• UE4로 임포트할 수 있는 다양한 텍스처 자장 포맷에 대해
• 밉맵, 임포트, 텍스처 그룹의 용도
• 텍스처 압축

Naming Conventions

• SM_Rock_00 : 스태틱 메시, 00 버전
  • 좋은 명명 규칙=> 파싱 가능, 어떤 파이프라인에 연결하여 정보 추출가능

• T_Rock_00_BC: Base Color Texture

• SKM_RockBunch_00: Skeletal Mesh

텍스쳐 제작

• 텍스처는 항상 2의 제곱이어야함(x와 y축이)
  • 16x256 등
  • 이 텍스처가 마지막에 메모리로 패킹되는 방식과 밉맵이나 텍스처 스트리밍 같은 언리얼의 내장 최적화에서 활용되는 방식이기 때문
  • 언리얼의 스트리밍 시스템에 사용되기 위해, 밉햅을 사용하기 위해 => 퍼포먼스 좋음.(거리에 따라 적절한 크기의 텍스처 생성 가능)

알파 정보 처리방법

• 두 가지 방법

  • 삽입된 알파(Embed Alpha) : 독립된 알파보다 비용이 두배
    • 해당 텍스처에 저장된 정보인 알파 채널이 압축되지 않은 채 언리얼로 들어오기 때문.
    • 임포트될싶대 전체 해상도를 얻게됨: 해당 텍스처의 비용이 두 배라는 것.
  • 독립된 알파(Separate Alpha):
    • 베이스 컬러 사이즈로부터 알파 채널 사이즈를 독립적으로 제어할 수 있다는 점.
• 프로젝트 실행을 좀 빠르게 하고 싶을 경우
  • 모든 알파맵의 사이즈를 줄임
    • 삽입된 알파 => LOD 바이어스 5 => 알파의 크기가 작아짐 => 원하는대로 리소스 사이즈가 줄어든다. => 하지만 외형은 박살(베이스 컬러 역시 픽셀화됨)
    • 독립된 알파 => 조금 픽셀화 => 베이스 컬러는 거의 유지 => 알파 채널 정보를 정말 저렴하게 만들면서, 베이스 컬러 정보는 정확히 동일하게 유지
• 두 방법을 선택하는 것은 프로젝트와 워크플로에 달려있음.
  • 처음부터 독립된 알파를 사용하면 기존의 것 수정할 필요 없이, 퍼포먼스 문제를 확실하게 해결

RGB 마스크 패킹

프로젝트 전체에 사용되는 텍스처의 양과 메모리를 줄이는 방법.

• 다양한 텍스처들 => RGB와 가끔은 텍스처의 알파 채널로 저장
  • Texture Sample 채널의 핀에서 이런 다양한 정보를 얻을 수 있음.
• 주로 VFX나 정말 높은 수준의 표면 디테일이 필요할 때, 그리고 일부 캐릭터 모델에 사용함
• 주의: 현재 사용하고 있는 채널의 흑백 정보만을 얻는다는점
  • 컬러정보를 얻으려면 이 결과에 특정 유형의 컬러 파라미터를 곱해 주어야하나.
• 참고: 텍스처 프로퍼티 자체에서 sRGB를 반드시 비활성화 해야한다.
  • 이걸 머티리얼에서 사용할 때는 sampler type이 masks로 설정되어야한다.
  • 이유: sRGB를 비활성화하면, 해당 텍스처의 감마 보정도 비활성화 되기 때문
    • 마스크 텍스처는 픽셀의 표시 여부를 정의하고 있기 때문에 감마보정이 되어서는 안됨.(이 정보가 단순히 렌더러에게 뭔가 표시될지의 여부만을 알려주기 때문.)

Saving Textures

UE4에서 지원하는 다양한 텍스처 포맷

• BMP
• FLOAT
• PCX
• IPG
• EXR
• DDS - cubemap Texture(32 bits/channel 8.8.8 ARGB32bpp, unsigned)
• HDR - Cubemap Texture(longlat unwrap) => 2의 제곱 규칙을 따를 필요가 없음.
• embed alpha 지원
  • PNG
  • PSD
  • TGA

Mip Mapping

• 프로젝트가 작동되는 데 중대한 역할.

• 텍스처의 레벨 오브 디테일

• 밉맵생성 == 텍스처를 UE4로 임포트할 때 발생

  • 특별한 경우가 아니라면 신경 쓸 필요 없다.
• 밉체인: 언리얼로 텍스처를 임포트할 때 자동생성
  • 프로젝트를 볼 때 대부분 이 체인에서 2단계나 3단계 쯤의 밉맵을 보게됨

• 텍스처가 화면에서 이 텍스처를 전체 해상도로 보여줄 필요가 없음

  • 거리가 먼 경우, 메모리는 여전히 텍스처를 크게 보여줄 때와 똑같은 비용이 들게됨.
• 밉맵 필터링 == Level of Detail 의 Mip Gen Setting에서, 밉맵이 생성될 때 날카롭게 보이거나, 흐리게 보이도록 할 수 있음.
  • 밉맵이 일종의 일렁거림을 일으킬 수 있음.
    • 쇠사슬로 연결된 울타리나 전선 메시처럼 작은 선을 가진 애셋에서 보이는 현상
    • 멀리 있는 텍스처 => 계단 현상 or 일렁임 형상 => Mip Gen Setting을 Sharpen 이나 Blur로 바꿔야함.
    • 프로젝트마다 해결할 수도 없을 수도 있다. (계속 세팅을 바꿔보면서 확인해야함)

Importing Textures

• 윈도우 탐색기 => 콘텐츠 브라우저에 드래그 드랍

• import 버튼 => 탐색기 => 선택 => 열기

• 언리얼엔진은 파일의 특정 값을 보고 노말맵인지 뭔지 알아서 처리
  • 어떤 유형의 텍스처를 임포트하든 언리얼은 특정한 텍스처에 특정한 프로퍼티가 적용되어 있어야 한다는 걸 잘안다.
  • 임포트되는 노멀맵 : 노멀맵으로 자동 구성

Texture Groups

• 텍스처가 프로젝트에서 사용되고 표시되는 방식을 관리하는데 도움.

• 어떤 유형의 텍스처를 사용하든 그 텍스처의 텍스처 그룹이 있음
  • 항상 프로젝트의 텍스처들이 올바른 텍스처 그룹에 있는지 확실하게 확인해야 할 것이다.
  • 실제로 그룹 안의 텍스처가 프로젝트에서 그려질 크기를 제어하기 때문.
• 텍스처를 축소하고 확대하는 정도 제어

• GPU를 통해서 텍스처에 적용할 필터링 종류도 제어

• Level of Detail에서 결정됨

• 최소 사이즈와 최대 사이즈를 제어할 수 있다.

• 프로젝트에서 텍스처 메모리가 바닥이 나면
  • 텍스처 메모리를 좀 되돌릴 수 있을지 실험을 해 봐야한다고 가정
  • 텍스처 그룹은 이처럼 리소스와 관련된 대규모의 실험을 비파괴적으로 할 수 있는 좋은 수단.
  • 이 system settings 로 모든 TEXTUREGROUP _World 노멀맵에 접근할 수 있으며, LOD 바이어스를 변경하여 이걸 2나 3으로 설정해 밉맵 체인의 2나 3번째의 LOD를 취하게, 그 LOD가 주로 사용되도록 만들 수 있다.
  • 대략 2048쯤 되는 텍스처를 취해서 1024나 512 정도로 줄임 => 줄어든 텍스처로 프로젝트 실행가능 => 자신이 원했던 퍼포먼스 상 효과를 얻음 => 원하는거 얻지 못했으면 다시 되돌리기
    • 텍스처를 빼고 사이즈를 줄인 후 리임포트하는것보단 싸다

[SystemSettings]
TEXTUREGROUP _World = (MinLOdSize = 1, MaxLOdSize = 8192, LODBias = 0, MinMagFilter = aniso, MipFilter = point)

텍스처 압축

• 텍스처 더블클릭 => 압축 세팅 => 설정

• UI, 최대 해상도 필요할 경우 => UI or Vector Displacement
  • 전혀 압축되지 않은 텍스처
• srgb: 활성화된 텍스처에 감마보정
  • 하지만 노멀맵, 마스크 텍스처 같은 애셋은 텍스처 정보가 아니라 활용할 렌더러 정보를 포함하기에 이 텍스처에 포함된 정보는 어떤 방법, 형태, 형식으로든 절대 조정되지 않고, 지정된 방식을 정확히 그대로 고수해야함.

더 나은 3D 메시와 텍스처2: 스태틱 메시

---

• System Units
• Lightmap UV’s
• Triangle Counts
• Collision Meshes
• Material ID’s
• What Are LOD’s
• Pivot Points
• Creating LOD’s
• What Are Lightmaps
• Limiting Overdraw

시스템 단위(system units)

• 어떤 DDC앱을 사용하든 아이템 제작을 시작하기 전에 우선 시스템 단위를 확실하게 구성해야함.
  • (이 강의에선 3d studio max를 사용하지만 모두 적용되는것)
  • 우선 시스템단위가 센티미터로 설정됐는지 확인.
  • UE4의 기본 측정단위가 센티미터임.(1 언리얼 유닛 == 1 센티미터)
  • 몰입감때문에 이를 언리얼엔진과 DDC앱의 유닛 단위를 맞춰줘야함.

Triangle Counts

• 트라이앵글 수: 퍼포먼스와 연관
• DDC에서 삼각형 수를 확인하며 작업해야함.
• 너트볼트와 같은 수준까지 디테일을 신경쓰지 않아도 됨.
  • 작은 디테일 => 플레이어도 모름 지나친 폴리곤 낭비

Material ID’s

• 모든 머티리얼은 하나 이상의 ID를 가진다.
• 어떤 폴리곤 면에 어떤 머티리얼이 적용되는지를 결정
  • ID가 5개면 렌더링이 5번되어야만 최종적으로 한번 더 렌더링 된 후 표시됨
• 머티리얼 유형: MultiSub-Object Material == 오브젝트에 다수의 머티리얼을 할당할 때
• ID가 많으면, 렌더링 비용도 증가

피벗 포인트

• 올바른 피벗포인트를 설정해야함
  • 오브젝트의 피벗 포인트 위치 잡아야 원하는 곳에 배치 가능
  • DDC에서 잘 설정하고 작업해야함
  • 스케일을 조정할 때 거리또한 스케일됨, 틀어지면 모든 작업이 힘들어짐.

What Are Lightmap

• 라이트맵: 텍스처의 복잡한 빛과 그림자의 정보를 저장하는 데 사용

  • 텍스처가 이러한 유형의 데이터를 저장하는 데 저렴하고 좋음
  • 복잡한 라이팅 계산을 텍스처에 저장하면, 런타임에 이 정보를 거의 비용없이 얻을 수 있다.

• 좋게보이도록, 퍼포먼스 높게 유지하도록, 균형을 맞추게해줌

• 라이트맵/ 섀도맵

  • 라이트맵: 일반적인 텍스처와 다르게 생김. 라이트맵의 RGB채널에 다양한 값들이 저장되었기 때문
    • 다양한 영역의 라이팅 정보가 모두 서로 다른 R,G,B 채널로 패킹된것
  • 섀도맵: 섀도 데이터를 R, G, B채널에 저장한 것

Lightmap UV’s

• 라이트맵 제작과 주의할 점

• 라이트맵은 오브젝트의 모든 면이 0-1 공간에 고유하게 배치되어야함
  • 각 면은 고유하게 배치되어야함. UV 아틀라스에서 각자 고유한 공간을 차지해야함.
  • 0-1 space: UV 정보 주변에 위치한 정사각형. 모든 UV가 스페이스에 있음.
  • 라이트맵을 렌더링할 때 라이트매스가 실제로 신경쓰는 데이터: 0-1 공간안에 있는것뿐, 그 외부 공간의 데이터는 잘라냄
  • 0-1공간에서 UV내 각 오브젝트에 각자의 공간을 확보해야함.
  • UV채널 = 2: 라이트맵 UV가 메시의 두 번째 채널에 저장되어야함을 의미 (3DMAX의 채널2는 UE4의 채널1, 언리얼은 0부터 채널 수를 셈)
  • 라이트맵이 언리얼로 임포트 될 때 자동으로 언팩됨
• 스태틱 메시 설정 아래에 라이트맵 해상도, 라이트맵 좌표 인덱스가 있음
  • 해상도: 메시 선택 => 디테일 패널 => Lighting => Overridden Light Map Res 에서 오버라이드 가능

Collision Meshes

• 두 가지 방법으로 만들 수 있음.

• 자신이 사용하는 DCC에서 콜리전을 만든 다음 지오메트리와 함께 임포트

  • 콜리전 메시의 구체적인 식별자가 있는 이름을 지어줘야함.
    • UCX_(메시 이름)_(콜리전 번호)

• 언리얼엔진에서 콜리전을 만들 수 있음

  • 상단 메뉴바 => 콜리전 => 콜리전 메시
  • 컨벡스 분해(convex decompos): 콜리전을 만들기 어려운 유기적인 메시에 쓸 복잡한 콜리전을 만들 수 있는 기능
    • 윈도우 => 컨벡스 분해 선택 => 적용
    • 이 기능의 역할: 메시를 복셀화, 그 복셀을 기반으로 콜리전 파라미터를 생성하는 것

Limiting Overdraw

• 오버드로는 투명 혹은 오파시티를 다룰 때 나타남
  • 이 현상은 GPU가 텍스처 곳곳에 다수의 투명을만들거나 여기저기가 뚫려 보이게 해서 유용한 정보를 표시하지 않게한다.
  • 오버드로는 다수의 평면을 겹쳐서 실제 나무, 덤불, 잔디 등과 같은 모습을 보여야 하는 폴리지 메시에서 자주 나타남
• 버텍스를 약간 더 사용하거나 평면의 실제 형태를 조정하여 오버드로의 발생량을 줄일 수 있다.
  • 버텍스를 몇 개 더 렌더링하는게 엄청난 수의 픽셀을 렌더링 한 다음 버리는 것보다는 싸다.(매프레임마다 하는 작업이므로)
• 오버드로 확인 : UE4의 툴 ‘셰이더 복잡도’라는 모드
  • 뷰포트의 Lit => Optimization Viewmodes => shader complexity
    • 하얀색을 최대한 많이 없애야함.

What are LOD’s

• Level of Detail
• 메시와 같지만 트라이 앵글 수가 더 적고 가끔 머티리얼 인스트럭션 수도 더 적은 사본
• 윤곽선이 같지만 해상도는 낮게
• 일정한 유형의 LOD가 있어야함.
• LOD 메시는 많이 있어도 되지만. 너무 많아서 프로젝트가 해가되는 시점이 올 수 있음
• 보통 75%, 35%, 12% 까지 메시를 줄임
  • 이런 수치는 정해진것은 아니지만, 차이가 나도록 설정해야함.
    • 메모리를 아낀다는 목적달성하기 위해

Creating LODS

• (3DMax에서)
• 기존 메시 복붙, Modifier 목록에서 Pro-Optimizer를 추가, Caculate 클릭
  • 폴리 수 줄이기: Optimization level 에서 vertex% 50%로 설정

• 모든 작업 후에 서로 겹침. => 모두 선택한 후 => 메뉴바에서 Group => Group => 이름 LOD => Utilities Panel 탭에서 more.. => LOD 선택 => Create new set 클릭 => File 에서 Export

• (언리얼에서)
• 임포트 => 고급옵션 보기 => 임포트 옵션 => 메시 LOD 임포트의 박스 => 라이트맵 UV 생성은 끔 => DDC에서 만든 라이트맵 UV 사용
  • 메시 LOD임포트를 켜지 않은 상태 => LOD가 없는 기본 메시만 얻음
• 생성 => LOD 세팅 => LOD 그룹 => LargeProp => LOD 다수를 자동생성

애샛 임포트 익스포트

• 스태틱 매시 익스포트
• 스켈레탈 메시 익스포트 + 옵션
• 애셋 리임포트
• 자동 리임포트: 폴더를 수신대기 설정 => 애셋이 변경되면 자동 리임포트
• FBX 를 통한 씬 전체의 임포트
• 수정할 애셋을 UE4에서 임포트

스태틱 매시 익스포트

• UE4는 스태틱과 스케레탈 메시 모두에 FBX 포맷 사용 (애니메이션 포함)

• FBX: 기본 머티리얼 데이터, 스태틱 메시 데이터 , 기본 머티리얼 데이터와 함께 스킨을 입힌 메시 데이터, LOD, 본 기반 애니메이션 데이터

• 스태틱 메시에 선택해야할 FBX 익스포터
  • 지오메트리: Smoothing Groups, Triangulate, Preserve Edge Orientation
  • 애니메이션이 있거나 Skeletal mesh에는 animation에 클릭해야함
  • 실수로 다른것도 익스포트하지 않도록 주의

스케레탈 메시 익스포트

• 지오메트리: Smoothing Groups, Triangulate, Preserve Edge Orientation

• 애니메이션: animation

• Deformation (Morph 타겟을 익스포트한다면): Deformations, Skins

3D Mesh 임포트

• 드래그 드랍, 임포트 버튼

3D Mesh 임포트 옵션

• 대부분은 기본설정으로 충분.
• 콜리전 자동생성: 해당 메시의 콜리전 자동생성
• 라이트맵 UV 생성: 라이트맵 UV 생성, 최고가 아닌 경우가 많음. (강의하는 사람은 비활성화하는 편 ==> DDC에서 모든걸 직접 구성할 경우)
• 버텍스 절대치로 변환: 이 옵션이 꺼지면 콜리전 메시의 피벗 포인트가 전부 0이되어 스태틱 메시 중앙에 놓이게됨
• 머티리얼 임포트, 텍스처 임포트: 보통 비활성화 == 메시 작업 완료와 동시에 임포트와 구성이 될것이기 대문. 테스트 애셋 이 임포트될 수 있음.
• 스켈레톤 메시 에니메이션 임포트: 메시 옵션
• 스켈레톤 메시 활성화, 기존의 스켈레톤을 찾아서 그 애니메이션을 임포트할지 말지 선택
• 나중에 머티리얼과 텍스처를 직접세팅하고 싶기 때문에 머티리얼, 텍스처 임포트 옵션 끔

애셋 리임포트

• 가장 간단하고 빠른 방법: 드래그 드랍 => 자동으로 업데이트
• 우클릭 => 리임포트
• 소스파일 경로 => 리임포트할 때 자동으로 이 경로 팡일로부터 리임포트
• 텍스처 더블클릭 => 리임포트 => 파일 탐색기(경로에 해당파일이 없을 경우) => 설정

자동 리임포트 구성

• 에디터 설정 => General => Loading & Saving => Auto reImport => 폴더 모니터

• 업데이트가 저장될 폴더 수신대기 => 자동으로 업데이트 가능.

• 이 방법은 소스 컨트롤 없이 작업할 때 사용하기 좋음.
• 협업할 경우 프로젝트에 최신 변경사항을 확실하게 반영시키고 싶을 때 사용하기 좋음.

Full Scene Import

• FBX 파일의 전체 씬 임포트
• 건축 시각화와 같은 프로젝트 => 모든 애셋을 가져와서 일일이 정확한 위치에 배치하는 것은 불필요 작업
• 스태틱메시 + 스켈레탈 메시 + 애니메이션 + 머티리얼 + 텍스처 + 리지드 바디 + 모프타깃 + 카메라 + 라이팅 모두 지원
• 머티리얼과 카메라는 일정한 제한이 있음.
  • 머티리얼: 디퓨즈와 노멀맵만 가져옴
  • 카메라: 애니메이션은 가질 수 없음, UE4에서 구성해야함.
• 3dmax에서 전체 선택 => 익스포트
• 임포트하면, 전체 씬을 재구성해 블루프린트에 배치해 주어서 씬의 모든 메시를 쉽고 빠르게 업데이트 할 수 있게 해 줌.

UE4로부터의 애셋 익스포트

• 애셋이주: UE4 외부에서 콘텐츠를 가져오는 또 다른 방법, 모든 내부 연결을 유지해줌.
  • 구 버전의 UE4를 사용했을 때 아주 좋은 방법
  • 새 프로젝트에서 열면 텍스처, 머티리얼, 메시 모두의 내부 연결이 유지.
  • Content 폴더에 배치해야함.(안그러면 모든 연결이 망가질 가능성이 큼)
• 애셋 익스포트: 소스 콘텐츠에 접근할 수 없을 경우, 애셋에 아주 미세한 조정만 하고 싶을 경우

머티리얼과 머티리얼 인스턴스

What is PBR

• Physically Based Rendering: 빛의 실제 작용을 추정하는 것.
  • 더 정확, 더 자연스러운 라이팅
  • 모든 라이팅 시나리오에서 똑같이 잘 작동함.
  • 시나리오별로 다양한 버전의 라이팅을 만들 필요 없음
• 머티리얼도 평소처럼 복잡해질 필요가 없음.
  • 원래 필요했던 머티리얼 인스트럭션 수를 많이 간소화할 수 있다.

• 머티리얼 값 훨씬 덜 복잡, 덜 상호의존적/ 더 직관적으로 조정가능

• 단순히 극 사실적인 렌더링을 돕거나 사실적인 이미지에만 사용할 수 있는 것이 아님.

  • 만화 기반의 이미지에도 적용 가능
• 아트 프록덕션 파이프라인의 통일에 도움이됨.
  • PBR은 애셋 하나만 있어도 어떤 유형의 라이팅을 받든 정확히 똑같은 방식으로 라이팅에 반응함
  • 라이팅 유형 별로 다수의 머티리얼이나 텍스처를 만들필요가 없게됨

머티리얼 도메인

• 각 머티리얼은 도메인과 블렌드 모드 또는 셰이딩 모델만 바꿔서 다양한 필요를 충족시킬 수 있다.
  • 이에 따라 일부 기능을 활성화하거나 비활성화해야함.
    • 주요 셰이더 노드의 각각 다른 출력에 영향이감.
• 머티리얼 도메인: 머티리얼 어트리뷰트가 평가되는 방식
• 블렌드 모드: 머티리얼 색과 배경과 블렌딩되는 방식을 결정

• 셰이딩 모델: 입력이 합쳐져 머티리얼의 최종 색을 만드는 방식을 결정

• ex. 유리: 블랜드= Transparent, 셰이딩= Unlit or Default Lit => 유리의 빛에 대한 반응 방식을 바꿀 수 있음.

• 여러 조합으로 필요를 만족시켜야함.

• 이들은 런타임에 변경할 수 없다.

머티리얼

• 머티리얼은 UE4가 오브젝트 상 텍스처의 표시 방식을 돕거나 조작하는 수단.
• 머티리얼은 HLSL코드의 작은 블록들로 구성됨.
• 작은 블록들은 온갖 다양한 역할을 수행함.
  • 그 중에는 텍스처의 색상대로 색조를 더하거나 두 텍스처의 블렌딩을 돕는다.
  • 사실상 HLSL 함수를다루는것.
• 머티리얼은 먼저 컴파일되어야함.
  • 컴파일: 미리보기 뷰포트 위의 적용 클릭
  • 컴파일 == 스태틱 == 프로젝트 실행 중에는 변경불가
• 머티리얼로 프로젝트 전체의 온갖 다양한 머티리얼에 적용할 수 있는 기능이 있음.

머티리얼 인스턴스

• 머티리얼은 런타임에 변경 불가

  • 색상, 텍스처 등
• 머티리얼 인스턴스는 머티리얼의 특별한 버전
  • 머티리얼을 리컴파일 할 필요 없이 머티리얼에 포함된 값과 텍스처를 런타임에도 바꿀 수 있게 해준다.
  • 덕분에 머티리얼 인스턴스는 반복처리를 정말 빠르게 해줌.
  • 변화가 거의 실시간.
  • 타임라인과 블루프린트로부터 머티리얼 인스턴스와 상호작용해 다양하고 멋진 애니메이션 효과 얻음.
• 퍼포먼스 이점
  • 유연성: 다양하고 수많은 파라미터 사용 => 마스터 머티리얼을 구성 => 복잡한 셰이더 코드를 다수 개발할 필요 없음. 미세 조정 가능

마스터 머티리얼

• 많은 구성을 할 수 있는 머티리얼
  • 수 많은 파라미터 노드 사용
• Base Color라는 백터 파라미터 => 색선택
• 텍스처 파라미터=> 무엇이든 보충할 수 있게, 외형을 완전히 변경 가능
• 스칼라 파라미터 => 스칼라 변수 제어 = 특정 이펙트를 늘리거나 줄일 수 있음.

마스터 머티리얼 주의점

• 가능한것

  • 다수의 마스터 머티리얼 사용

• 해서는 안됨

  • 모든 오브젝트에 작용하는 단 하나의 마스터 머티리얼을 만드는것은 하면안됨 => 성능에 문제 생김

    • 캐릭용 , 아이템용, 불투명한것, 투명한것.. 등등 따로 따로

  • 지레짐작하지말아야함(불필요한 파라미터 삽입금지)

마스터 머티리얼 개념

• 머티리얼 => 좋은 퍼포먼스 + 자신이 목표로한 모든 플랫폼에서의 작동을 보장해야함
• 머티리얼 함수: 머티리얼 그래프 일부를 공유하고 재활용할 수 있게 해줌
  • 수많은 내장 함수들: 오브젝트의 월드 위치 결정, 화면상 마우스의 좌표 위치 파악까지 모든 것을 해냄
  • 머티리얼 라이브러리로 코드 공유 가능
  • 유지보수 간소화
• RGB 마스크 패킹
  • 텍스처의 사용 방식을 지정할 수 있다.
  • R, G, B, A 채널에 다른 텍스처를 저장하게 두는 것 => 메모리에서 텍스처 양을 줄일 수 있는 방법
• 스태틱 스위치(static switches)
  • 머티리얼의 전체 경로를 활성화 또는 비활성화
  • ex. 패럴랙스 오클루전 노멀 매핑을 켜고 끄는 스위치를 만들면 노멀 맵에 굉장히 비용이 높고 사실적으로 보이는 디테일을 구현할 수 있다.
    • 비용이 높아 씬의 머티리얼 다수에 사용할 수 없음 => 스위치로 필요한 메시에만 활성화
• 피처 레벨 스위치
  • 어떤 목표 기기에서든 머티리얼이 실행될 수 있게 해줌.
  • 다양한 플랫폼에 사용할 서로 다른 복잡도 수준에 따라 서로 다른 버전의 머티리얼을 연결
    • ex. 셰이더 모델 5(SM5)을 사용해 거의 무한한 디테일과 아름다움을 얻고 싶으면 => 높은 디테일의 셰이더가 됨.
    • ex. ES2에서 실행되는 것 => 안드로이드 모바일 프리뷰어, 그냥 실행만될 뿐, 부가기능많이 없음

마스터 머티리얼 제작

• 배경 오브젝트에 사용할 마스터 오브젝트 구성 방법
• 배경 오브젝트용 마스터 머티리얼을 유리가 있는 오브젝트용 마스터 머티리얼로 변환
• 머티리얼 함수 만들고 사용

마스터 머티리얼 생성

• 파일 -> 새 레벨 => 새 default 레벨 => 마스터 머티리얼 폴더 => 콘텐츠 브라우저 우클릭 => 새 마티리얼 =>더블클릭

• 색추가
  • 머티리얼 인스턴스 => 벡처 파라미터 노드 추가(BaseColor로 그룹)
  • 머티리얼 에디터 우클릭 => Vector 검색 => 베이스컬러와 연결 (키보드에서 v누르고 에디터 클릭)

• 텍스처 추가

  • T Key를 사용해 머티리얼 내에 배치 (콘텐츠 브라우저에서 우클릭후 텍스처 선택 => 머티리얼 에디터에서 t 누르고 에디터 클릭 or 드래그 드랍)
  • 텍스처를 텍스처 오브젝트로 변환해 설정할 것임.
  • 노드를 바로 BaseColor에 연결하면, 머티리얼을 컴파일하고 머티리얼 인스턴스에서 사용하려고하면 텍스처 샘플을 조정할 수 없게됨
  • Texture Sample 노드에 우클릭 후, 파라미터로 변환해야함. (Base_Color_Texture로 이름 설정, 그룹을 BaseColor)
• 스태틱 스위치 추가(텍스처나 더 저렴한 비용의 벡터 컬러 파라미터의 사용여부를 결정)
  • 머티리얼 에디터 => 우클릭 => ‘Switch Parameter’ => ‘Default Value’를 true로 (bUseBaseColorTexture로 이름 설정, 그룹을 BaseColor)

• 상수 값 추가

  • 키보드 1 키 + 좌클릭 => 노드 우클릭 파라미터 변환 (Metallic으로 설정, 그룹도 Metallic)
• 러프니스 구성
  • 약간의 제어를 위해 Lerp Parameter 를 사용하여 러프니스 값을 높이거나 낮출것임.
  • 텍스처를 하나 더 추가 => 텍스처의 RGB 채널에 패킹된 러프니스 맵을 사용할 수 있도록 러프니스를 구성할것임
    • 이 텍스처에서 샘플 타입을 Masks로 설정해야함 => 마스크 파라미터 구해야함(RGB -> static mask param) => 머티리얼 인스턴스에서 텍스처의 다양한 R, G, V 채널을 선택 가능 (RoughnessMasks라고 이름 지음. Roughness 그룹에 넣음)
    • Texture Sample 우클릭 => 파라미터로 변환 => Roughness_Texture 라고 이름지음 => 그룹을 Roughness
  • 키보드 L 을 누르면서 클릭 => Lerp 노드를 생성 => Lerp의 Alpha와 마스크 연결 => A, B에는 스칼라(상수) 값 추가
  • 러프를 Roughness(러프니스)와 연결

    컨트롤 쉬프트 왼클릭 => 노드 다중 선택

• 노멀맵 추가

  • 텍스처 샘플러 추가 => 우클릭 => 노멀맵과 연결 => 샘플 타입 노멀로 설정 => 파라미터로 변환 (Normal_Map으로 이름 변경)
• 적용과 저장 버튼 => 마스터 배경(environment) 머티리얼 제작 끝

유리 머티리얼 제작

• 위에서 만든 머티리얼 복붙, 이름 변경, => 오파시티나 오파시티 마스크 사용 (디테일 패널 => Materials 섹션 => Blend Mode)
  • BlendMode: Masked(렌더러에게 이 픽셀을 통과해서 볼 수 있는지 없는지 알려줌)or Translucent(통과해 볼 수 있는 정도를 어느정도 조절)
    • Translucency가 0.1 => 거의 다 통과 => 표면이 살짝 더럽거나 하는 경우를 만들 수 있음.
    • 오파시티 or Translucency : 오파시티 마스크보다 비용이 더 많이 든다.(속도를 원한다면 마스크 사용, 퀄리티 => 오파시티)
  • Opacity 상수 만들어 연결(opacity에)
• Shading Model을 Glass로 변경하여 씬의 라이팅과 더 나은 상호작용하도록 해야함
  • Transluncy 섹션 => Lighting Mode => Surface Forward Shading : 최고의 라이팅과 반투명 상호작용을 보여줌 + 비용이 가장 비싸기도함.
    • 컴파일 오래걺림

머티리얼 함수 제작

• 서로 다른 머티리얼 간에 셰이더 코드를 공유할 수 있게 해주는 머티리얼 함수 제작

• 머티리얼 함수: 머티리얼 간의 셰이더 코드 공유하는 수단

• ex.

  • ‘MF_Tile’이름의 머티리얼 펑션 생성
  • 간단한 텍스처 타일링: 타일링을 동일하게 유지시켜야하기 때문에 만든다. 각각 다른 셰이더에 사용하는 타일링 방식이 다를 필요가 없기 때문(일원화 작업)
  • 텍스처 좌표 추가(Texture Coordinate)
  • FunctionInput 추가 => Texture_Scale로 이름 변경 => Input Type을 인풋 스칼라로 (텍스처 좌표에 값을 곱할 것임) => preview Value의 x를 1로 설정
  • => M키 랑 왼클 => Multiply 노드 생성 => 좌표를 A, Scale 스칼라를 B, 그리고 Multiply 노드를 타일 아웃풋에 연결 => 적용
  • 아웃풋에 우클릭 => 미리보기 중지 => 다시 미리보기 시작

• 머티리얼 함수를 머티리얼 에디터에 드래그 드랍하여 배치 가능

• 머티리얼간에 일관성이 있어야함 => 변수명 등

머티리얼 인스턴스 사용

부모 자손 관계

• 부모 인스턴스 머티리얼 관계
• 부모들이 그 색깔에 대한 액세스할 수 없기에 자손도 액세스할 수 없다.
• 부모가 할 수 있으면, 자손 역시 부모가 할 수 있는 모든 것에 액세스할 수 있다.

• 부모가 할 수 없으면, 자손 역시 할 수 없다.

• ex.
  • MAT_ENV_Master 와 MAT_Glass_Master가 있다.
  • MAT_ENV_Master => 세가지 외형의 머티리얼 인스턴스를 만들 수 있다.(타일링 변경, 색변경, 텍스처 변경)
    • 인스턴스에서 완전히 다른 외형의 머티리얼을 구성할 수 있다.(하지만 통과해서 볼 수 없음.)
  • MATGlass_Master는 통과해서 볼 수있는 머티리얼.(이 마스터의 자손인 인스턴스들은 ENV처럼 변경할 수 없다 => 부모가 접근을허용하지 않음)

머티리얼 인스턴스 생성

• 머티리얼 선택 => 인스턴스 생성

• or 콘텐츠 브라우저에서 우클릭 후 머티리얼 & 텍스처에서 만들 수 있음.

• 머티리얼 인스턴스 클릭 => 인스턴스 에디터

  • BaseColor에서 텍스처 변경 가능 => 빠르게 변경됨(컴파일 시간 없이)
  • Metallic 등 을 오버라이드 가능 => Slider min ~ max 설정가능
  • 이러한 설정들은 인스턴스 생성시 만든 그룹으로 묶임
  • 부모 머티리얼 또한 변경 가능.
• 머티리얼 더블클릭 => 디테일
  • Material Property Override: 부모 머티리얼의 함수 기능을 오버라이드
    • TwoSided: 안쪽도 렌더링하는지
    • 블렌딩 모드 변경, 디더링된 LOD 전환의 변경 등
    • 이는 부모 머티리얼 시스템의 목적을 무산시킴(보통 머티리얼을 새로 만듬)
    • 검증용도로 사용하면 좋다.

Vertex Animation

• 미묘한 움직임을 저렴한 비용으로 전달
• 물, 풀, 천 또는 역동적으로 움직여야하는 물건들
• GPU에서 진행되기에 매 프레임의 렌더링 비용이 저렴함.
• 주어진 메시에서의 기존 버텍스 위치를 오프셋하기만 하면 되기 때문
• 저렴함 + 쉬운 활용 => 약간의 비용(상호작용성)
  • 모든 콜리전과 비슷한 것을 전부 처리하는 CPU는 GPU의 메시와 버텍스에 적용된 오프셋에 대해 알지 못함.
  • 그저 부가적인 장식이나 씬과 경험에 재미나 실감을 더해주는 용도
  • 게임플레이에 영향을 주지못함. (상호작용하는데 사용못함)

퍼포먼스와 최적화: Texture Streaming

Texture Streaming

• 많은 양의 텍스처를 다룰 때 => 텍스처가 흐려질 수 있음.
  • 디테일이 제대로 표시되지 않을 수 있음.(스트리밍이 제대로 이루어지지 않음.)
  • 스트리밍: 기본적으로 텍스처가 얼마나 크거나 작게 보일지 처리한다
• Lod or 밉맵: 텍스처와 정확히 똑같은 버전이지만 크기만 다른걸 보여줌(리소스 비용이 적음)
• 스트리밍: 레벨의 오브젝트와 카메라의 거리에 따라 서로 다른 LOD를 스트리밍하는것을 도와줌.

건축 시각화나 엄청나게 높은 텍스처 디테일이 필요한 경우 종종 경고를 받음(풀의크기가 부족하다는)

• 텍스처 스트리밍에 PoolSize라는 것이 있음.

  • 텍스처 밉맵으로 채울 수 있는 특정 메모리 셋을 말함.
  • 텍스처가 카메라에서 멀 수록. 점점 작아지다 메모리 풀에서 차지하는 크기 또한 작아짐, 결국 메모리에 없어짐.
  • 오브젝트에 가까이 가면 갈 수록, 텍스처는 이 스트리밍 풀을 점점 더 많이 차지하게됨.

• 풀크기 키우기 : ‘`’ or ‘~’ 키를 눌러서 UE4 콘솔창 => r.Streaming.PoolSize = 5000 이런식으로 설정하면 됨.(메가바이트 단위)

  • 아니면 DefaultEngine.ini에서 설정

Forcing Textures to never stream

• 텍스처 스트리밍 안함 옵션: 언제나 가장 높은 해상도 버전의 텍스처가 표시되도록 만드는 것.
  • 프로젝트의 모든 텍스처를 가장 높은 해상도로 설정하면 안됨.
  • 보통 UI옵션, 텍스트 등 유저에 가깝게 뭔가 표시하는 텍스처에 스트리밍 안함.
  • Texture => Never Stream
  • 퀄리티는 높지만 비용이 비쌈.

LOD & 스태틱 메시 병합

• LOD: 거리가 멀리 떨어졌을 때 사용하려고 더 적은 버텍스로 렌더링한 다양한 버전의 메시

UE4 Automatic LOD Creation Tools & Manual LOD Setup

• DCC에서 생성할 수 없거나 시간이 없을 경우

• 자동: 스태틱 메시 에디터의 LOD 세팅

  • LOD 그룹 => 그룹 선택 => 자동 LOD 생성 툴이 BaseEngine.ini를 확인해 얼마나 많은 LOD 레벨이 적용되어야 하는지 알아낸다. (또한 메시 디테일 패널에 있는 다양한 세팅들도 확인, LOD0 세팅)
  • 메시의 LOD 세팅 => LOD 그룹 LevelArchitecture => LOD를 거쳐서 Reduction setting을 각각 설정
  • LOD 그룹에서 설정

• 수동

  • LOD 세팅에서 LOD의 개수를 설정할 수 있고 각각의 LOD에서 Reduction setting에 있는 percent triangles 로 폴리곤 개수를 설정 가능.
  • 보통 삼각형 개수를 75%, 25%, 12%로 맞춤 (사람의 눈은 윤곽선에서 얻는 정보가 더 큼)

Adjusting/ Tweaking LODs

• LOD 변경사항에서 거리를 조정하거나 미세 조정해야한다면 => 현재 화면 크기 사용
• LOD 세팅에서 Auto Compute LOD Distances 세팅 해제
• 스태틱 메시 에디터 => 트랜지션화면 크기를 설정 => Current Screen Size 를 보고 설정
• LOD 강제 렌더링 가능 => Forced Lod Model
  • 액터 => 디테일 패널 => LOD => Forced Lod Model
  • 배경 오브젝트가 많은 경우 메시가 항상 LOD4가 되게 설정 가능.
  • Min LOD: 마지막 LOD가 나올 때까지 계속 그 LOD 시스템을 쓰는것

Merge Actor Tool

• 드로콜과 머티리얼 수를 줄여주는 배경 오브젝트 그룹 작업 가능
• 스태틱 매시나 머티리얼 수가 많은 것. => 하나의 머티리얼, 스태틱 매시(삼각형의 개수는 같음)
  • 전체 렌더링 크기를 줄임.
• 하나의 머티리얼, 하나의 메시, 하나의 텍스처
• Window => DeveloperTools => Merge Actors
  • Pivot Point at Zero: 단점이 있긴하지만 새 메시의 배치를 쉽게한다.
  • Merge Physics Data: 모든 피직스 데이터를 한데 병합.
  • LODSelection Type
    • Use all LOD Levels: 새 머티리얼의 생성 방식을 선택이나 조정할 수 없게 하기 때문. (현재 상황 전부 취해 거대한 메시를 만든 후 그 LOD 를 모두 사용한다.)
    • Use specific LOD Levels: LOD 0으로 설정(2나 3 등의 레벨이 없는 것이 있을 수 있음), 새로 병합된 메시가 그 LOD 레벨을 신뢰할 수 없음. (LOD == 0일시 LOD Maker와 같은 내장 최적화 툴도 사용하여 메시를 더욱 최적화 가능 )
  • Material Setting
    • Merge Materials
    • all LOD Levels => 다양한 머티리얼 세팅 불가능
    • Use Specific LOD => Material Settings를 수정할 수 있다.(Normal map이나 Metallic Map을 수정할 수 있음)
    • Texture Sizing Type: 선택한 옵션이 자신의 콘텐츠에 최적하지 않을 수 있음. (모듈화 중점 => Input Texture의 Texture Size에 따라 자동 편향된 텍스처 크기를 사용할 수 있음.
  • Landscape Culling: 랜드스케이프와 교차하는 모든 메시에 교차 부위를 마치 잘린것처럼 만들어줌. 랜드스케이프 액터에 배치된 매시를 크게 최적화함.

계층형 LOD

• 액터병합: 성능은 좋지만 파괴적
• 계층형 시스템: 레벨에서 다수의 액터를 생성하거나 병합할 수 있게 해주며, 프로그래밍적으로 수행한다.
  • HLOD 툴을 삭제하거나 재실행하여, 레벨에 완전히 새로운 메시를 만들 수 있음.
  • 비파괴적

• HLOD: 메시들을 모두 취해 하나의 텍스처와 하나의 머티리얼을 가진 단일 메시로 변환함

  • window => world settings => LODSystem => HLOD 활성화
  • window => HLOD Outliner => Generate Clusters => Cluster generation setting
    • 기본적으로 HLOD 시스템 전반을 거쳐 볼륨을 상당히 낮춰줌.
    • 그 볼륨에 포함된 모든 액터는 새로 생성된 메시, 새 LOD 메시를 얻어서 멀리서 사용할 수 있게해줌.
    • 일정 거리만큼 떨어지면 HLOD 가 메시를 그룹으로 묶어 2~3개의 메시로 바꾸면서도 완전히 동일한 디테일한 레벨을 보여줌(메시도 2~3개, 머티리얼도 2~3개, 텍스처도 2~3개)
    • 카메라에서 멀리 있을 경우, 정확히 똑같은 오브젝트를 훨씬 절감된 비용으로 렌더링 가능
  • 모든것을 구성하거나 알맞은 클러스터에 두었다면, Generate Proxy Meshes 누름.

• 레벨을 렌더링하는데 드는 메모리와 GPU 비용을 줄임.

• 주의: 레벨이 크면 클수록, 혹은 오브젝트 밀도가 높으면 높을수록, 프록시 메시 생성에 드는 시간은 더 길어진다.

라이팅, 섀도잉, 포스트 프로세스

• 모두 서로 비슷, 모두 서로 상호작용
• 여기에서 대부분의 퍼포먼스 문제가 발생함

라이팅

• 다양한 라이팅 Mobility 타입

  • 라이팅의 퍼포먼스 비용 면에서 서로 다른 기능이 있다.
  • Static: 가장 저렴, 씬에서 아무것도 하지 못하는 라이팅을 의미, 완전히 구워져서 상호작용할 수 없음.
  • Stationary: 씬과 상호작용을 할 수 있어, 스테이셔너리 라이트로 인해 생기는 섀도는 다이나믹 오브젝트가 해당 섀도와 어우러지게 해줌. (비용이 살짝 비쌈)
    • 런타임에서 스테이셔너리 라이트의 라이팅 색상과 강도를 실제로 바꿀 수 있기 때문.
    • 라이팅을 움직이지는 못함.
  • Movable: 완전히 동적이기 때문에 비용이 비쌈. 모든 라이팅, 섀도인이 다 동적
  • 사람눈으로 차이를 거의 구분할 수 없음.

• 라이팅 빌딩

  • BuildOptions => Lighting Quality => Production/High/Medium/Preview
    • preview: 에디터가 매우 낮은 세팅을 사용해 프리뷰를 보여주거나 라이팅과 섀도잉이 어떻게 보일지 기본적인 개념만 제시
    • Medium: preview보다 약간 더 느리고, 약간 더 나은 결과를 보여줌.
    • High: 비교적 높은 라이팅 제공하지만, 얼룩, 띠현상 때문에 라이트맵 해상도를 올려서 조정해야할 수도 있음.
    • Production: 기본적으로 완성할 수 있는 최고의 퀄리티의 라이팅을 보여줌.(오래걸림)
  • production 과 preview 사이의 퀄리티 차이는 꽤 큼.
  • 개발진행상태에 따라 옵션을 변경(초기 == preview, 모든 작업끝 == Production)

섀도잉

• 섀도잉하는 방법은 다양함.

• 언리얼에서는 두 가지의 주요 섀도잉 타입이 있음.

  • Static: 스태틱 라이트 유형에서 나오는것. 비용이 작음, 씬 상호작용 할 수 없음
  • Dynamic: 스테이셔너리와 무버블 라이트에서 나옴. 비용이 비쌈, 씬 상호작용 할 수 있음.

• static 라이트

  • 다이나믹 오브젝트 즉, 모든 움직이는 오브젝트는 그림자를 드리우지 못함.

• 스테이셔너리 라이트 사용 => 그림자가 서로 합쳐짐(구워진 섀도우에서도)

  • 다이나믹 섀도를 드리우되, 스태틱 섀도잉 시스템의 효과도 많이 가져옴
  • 스태틱과 다이내믹 사이에 위치.

• Dynamic

  • 좀 더 선명하고 가장자리의 부드러움이 전혀 없음.
  • 구워진 섀도우가 없음.

특이한 섀도우

• CSM(Cascaded Shadows)
  • 스태틱 섀도와 다이내믹 섀도의 최고 장점들을 합칠 수 있기 때문.
  • 가까이 있을 때 => 완전한 다이내믹 섀도
  • 멀리 => 스태틱 섀도로 전환
  • Direction Light => cas => Num Dytnamic Shadow Cascade, Dynamic Shadow Distance => 전환되는 거리와 다이내믹 섀도 케스케이드의 수 변경 가능
  • 이 섀도는 Directional Light에서만 사용가능.
• Distance Field Shadows
  • 메시 디스턴스 필드를 사용하여 실제로 라이팅과 섀도의 상호작용을 생성해서 멋진 섀도 감쇠를 만들어냄
  • 비용이 굉장히 높음
  • 포인트 라이트에서 활성화 할 수 있지만, 디스턴스 필드를 활성화 해야함.
  • 프로젝트 세팅 => Distance => 엔진 라이팅 => Generate Mesh Distance Fields => 활성화
• Contact Shadows
  • 컨택트 섀도가 멋진 이유: 실제 스크린 스페이스에 구성되는 섀도.
  • 기본적으로 스크린 스페이스의 섀도
  • 굉장히 작은 디테일 (디렉셔널 라이트의 섀도잉은 섀도 버퍼가 이런 디테일 유형을 나타내기에 충분히 크지 않음)
  • 포인트 라이트 => 디테일 패널 => Contact => Contact Shadow Length
  • Contact Shadow 값을 증가시키면 그림자는 깊어짐(적절히 설정해야함. 1을 넘어가면 별로)
  • 패럴랙스 오클루전 매핑(Parallax Occlusion mapping) => 특정 컨택트 섀도 메서드의 작동 방식을 바르게 볼 수 있는 방법
  • 정말 높은 비용의 기능

Post Process

• 볼륨으로 처리되는 포스트 프로세싱 => 렌더링을 제어하기 때문.

  • 퍼포먼스 다수를 순식간에 잡아먹을 수 있는 구간 중 하나.
• 포스트 프로세스 섀도를 구하는 방법
  • Volumes => Post 검색 => 포스트 프로세스 볼륨 => 디테일 패널
  • 디테일 패널 => Unbound 프로퍼티 체크(언바운드의 역할: 이 포스트 프로세스가 레벨 어디에 배치되든 모든 포스트 프로세스 세팅에 이 포스트 프로세스를 사용하라)
    • 언바운드가 활성화되지 않으면: 볼륨의 스케일과 회전을 조정 => 플레이어가 이 볼륨에 들어오면 포스트 프로세스가 변함. 언바운드는 이를 방지함. => 이 세팅을 월드 모든 곳에 적용.
  • 모바일 톤 매퍼: 모바일 프로젝트 제작에만 유용
  • 안티 에일리어싱: 프로젝트 설정 => 디폴트 세팅에서 설정 가능
  • 포스트 프로세싱 => 블루프린트를 통해 조작된 값도 가질 수 있음. (온도 등 변경)
• 포스트 프로세스의 세팅을 많이 켜고 조정할수록 렌더링에 드는 비용이 커짐.

볼륨

• 많은 볼륨 중 다음과 같은 볼륨만 다룰 것임
  • Lightmass Volumes: 라이팅 계산이 이루어지는 Min 과 Max 영역을 정의, 인터렉티브나 무버블 오브젝트가 월드와의 확실한 상호작용을 통해 여기저기 움직이고 상호작용을 하면서도 월드로부터 라이팅을 받을 수 있게 돕기도 함.
  • Cull Distance Volumes: 레벨에서 확실하게 컬링을 만들어주는 안전 그물역할

Using Volumes

• UE4의 여러곳에 배치해 다양한 일을 수행할 수 있는 액터
• 갈수 있는 곳과 갈 수 없는 곳을 결정.
• 사운드 리버브방식 등 결정
• 상호작용할 수 있는 많은 방식 => 볼륨으로 제어됨.

라이트매스 볼륨

• 두가지 목적

• 1. 라이트매스 시뮬레이션의 경계를 정해 라이트매스가 계산할 가장 큰 영역과 가장 작은 영역을 결정

  • 라이트매스 볼륨을 레벨에 두지 않으면, 결국 라이트를 전혀 받지 않는 영역이나 레벨에서 플레이가 가능하지 않은 영역에 상당량의 연산 시간을 낭비하게 될 수도 있다.
  • 라이트매스 볼륨 => 플레이어가 보거나 상호작용하는 영역만 라이팅 계산 => 계산 양 줄어든다. => 실제 레벨 라이트 계산 빨라짐

• ex

  • Lightmass importance volume
  • 이 볼륨들을 여러개 레벨의 모든 영역에 배치할 수 있지만, 결국 라이트매스란 MIN 과 MAx 위치를 보고 하나의 큰 볼륨을 만든다.
  • 그러니 레벨에 볼륨을 확실히 두고 레벨의 플레이 가능 영역을 모두 포함하는지 확인해야 한다.

• 2. 캐릭터와 같은 동적 오브젝트에게 정적으로 라이팅되는 환경에 대해 알려주는 것.

  • 완전한 다이내믹 라이팅을 만들 수 없다(라이트와 섀도 맵 안에 라이팅을 구움)
  • 즉, 상호작용 못함 => 문제 해결: “Lightmass Importance Samples” 혹은 소형 라이팅 프로브들을 곳곳에 배치
    • viewport=> show => visualize => light sample 에서 확인 가능.
    • 이 샘플들은 각각 캐릭터들에게 배치된 라이팅에 대해 알려준다.(메시 선택, alt + shift를 누른채 옮겨서 확인 가능)
  • 다이내믹 메시가 정보를 받도록, 또는 작은 라이팅 볼륨 샘플과 배치된 샘플들로부터 어떤 색상을 띠어야 하는지 알려주는것인데 다 이 볼륨덕분

• Lightmass Character Indirect Detail Volume

  • 특정 볼륨에 배치된 샘플 숫자를 증가시킴
  • 작은 샘플들 각각이 지오메트리가 있는 곳 위로 배치됨 (샘플이 없으면, 캐릭터 안보임)
  • 캐릭터 볼륨안에 샘플 다수가 있는지 확인
  • 엘레베이터 내부처럼 플레이어가 긴 영역을 따라 이동해야하지만 샘플이 많이 있지는 않은 특정한 장소에서 사용하고 싶을 것

  • 특정 프로젝트에 있는 샘플의 전체적인 양을 증가시키기 위함

  • world Setting => lightmass => Static Lighting Level Scale => 샘플들의 밀도 조절 (높은 밀도 => 디테일 증가 => 0.1로 설정 => 메모리 많이 필요)

Cull Distance Volume

• 특정 크기나 카메라 거리를 초과한 오브젝트의 렌더링을 멈추는 최적화 툴

  • 이를 사용할 때 오브젝트의 모든 것을 컬링할 수단보다는 그냥 기본값처럼 사용(안전 그물역할)

• cull distance volume

  • 디테일 => Cull distances => 배열 => 여러 종류의 입력이 있음(ex, 3개)
  • 오브젝트가 렌더링될자 아니면 멈출지의 기준이 될 크기와 거리를 결정.
  • 이 배열에 카메라의 거리와 크기의 임계점을 담음.
  • 메시에서 Allow Cull Distance 를 활성화 해야함

• 수동적인 방법: 메시 => 렌더링 => 고급 프로퍼티 => Min Draw Distance. Desired MaxDrawDistance, Current Draw Distance : 하드 코딩 설정/ 오브젝트가 카메라로부터 컬링되는 기준 거리 강제 설정 가능

• 볼륨을 사용하여 컬링을 하면, 프로젝트에서 컬링을 구성할 때 원래 필요했을 작업량을 상당히 줄여줌.

  • 일일이 수동으로 최적화하지 않아도 됨.

리플렉션

Reflaections

• 3가지 방법으로 얻을 수 있음
  • 이 방법들은 특정 액터에 의해 제어됨
  • sphere: 비용이 저렴
  • box: 비용이 저렴
  • planar: 비용이 비쌈

• sphere

  • 구체 영역안에 리플렉션을 만든다.
  • 저렴
  • 레벨 전체 커버할 캡처 액터와 , 작은 캡처 몇개를 만들어 여기저기 배치
  • 과용하면 좋지않음
  • 리플렉션 뷰모드 사용하여 세세하게 잘 설정할 수 있다.

• BOX

  • 일반적으로 복도 내부, 네모난 레벨에서 사용
  • 구석에서 약간 오류가 발생
• Planar
  • 프로젝트 세팅 => 렌더링 => support global clip plane for planar reflections활성화
  • 레벨과 모든 메세와 텍스처의 사본을 취해서 위 아래로 뒤집은걸 리플렉션으로 사용
  • 정확한 리플렉션이 나오지만 비용은 메시와 머티리얼의 비용에 직접적인 연관.
  • 몇몇 에러 발생가능 => 작고 파란 하이라이트들이 생김 => 리플렉션이 씬을 One-Sided로 렌더링하기 때문.=> Render Scene Two Sided를 True로 설정해야함
• 포스트 프로세싱 볼륨의 스크린 스페이스 리플렉션(SSR)
  • 포스트 프로세싱 볼륨 => 디테일 패널 => Rendering Features => Screen Space Reflection 활성화
  • Sphere, BOX는 레벨의 모든 다이내믹이 리플렉션 캡처로 고려되지 않는다.
  • 역동적인 리플렉션 => SSR or Planar
  • 스크린 밖에 오브젝트가 있으면 리플렉션 망가짐
    • 화면의 정보를 사용하기 때문(보이지 않으면 반사 x )

Getting Higher Quality Reflections

• 언리얼 == 실시간 엔진

  • 전반적인 리플렉션 캡처 해상도를 최소한으로 낮춤

• 해상도를 실제로 변경 가능.

  • 에디터 => 편집 => 프로젝트 세팅 => 렌더링 세팅 => Capture Resolution
  • 스카이라이트 => 디테일 패널 => Cubemap Resolution
  • 해상도 높 => 메모리 사용량이 많이 늘어남

• 메시에게 High Precision Static Mesh Normal 과 Tangent Encoding 사용

  • 높은 테셀레이트 스피어 사용
  • 편집 => 프로젝트 세팅 => 렌더링=> GBuffer Format => High Precision Normals
  • 메시 => 디테일 패널 => 빌드 세팅 => Use High Precision Tangent Basis => TRUE
  • 메시 전체에 더 나은 보간을 줌.
  • 메시가 높게 테셀레이트 => 버텍스 많이 사용 => 부드러운 트랜지션