들어가며

앞선 Perforce 베이직 포스트에서는 P4V 클라이언트에서 기본적인 뷰의 구성이나 기능들을 확인해보았습니다.
이번 포스트에서는 워크스페이스를 구성하고 파일을 Submit하고 Depot에 잘 반영되었는지 확인하는 과정을 살펴보려해요.

준비 사항

파일 수정 및 submit 전에 작업할 워크스페이스를 설정해주세요.
우선 P4V를 실행합니다.

1. Server는 사용하고자하는 Perforce 서버 주소를 입력합니다.
2. User는 로그인하고자하는 사용자 ID를 입력합니다.
   1. 사용자 ID는 Open Connection 창에서도 새로 만들 수 있을 수 있지만,
   2. 사내 계정 서비스 또는 LDAP 등으로 계정 관리가 되고 있다는 가정하에 ID를 입력하겠습니다.
3. Workspace는 New를 눌러서 새로운 워크스페이스를 만들어보겠습니다.

Workspace 만들기

1. 앞선 Open Connection 화면에서 Workspace New 버튼을 클릭합니다.
2. Workspace 만드는 화면에서 아래의 값들을 입력, 선택합니다.
   1. Workspace name: 워크스페이스 이름을 입력해주세요. 입력한 값에 따라 Workspace root(경로) 값이 맞춰서 변경됩니다.
   2. Workspace root: 워크스페이스 경로입니다. 경로 변경이 필요할 경우 Browse를 통해 경로를 확인하고 변경할 수 있습니다.
   3. Stream: 워크스페이스와 연결할 Stream을 입력합니다. Browse를 통해 스트림을 찾을 수 있고 입력창에서도 자동완성으로 찾을 수 있습니다.
3. 모두 입력한 뒤에 OK를 누르면 워크스페이스가 생성됩니다.
4. 다른 워크스페이스를 사용하고자할 경우에는 Workspace Browse를 통해 워크스페이스 리스트를 확인할 수 있습니다.
5. 워크스페이스가 생성이 완료되었습니다! 🎉

Workspace로 가서 작업을 시작해보죠!

이제 워크스페이스도 만들었으니 작업하러 들어가보겠습니다.
처음에 들어가면 아래와 같은 화면을 볼 수 있을거에요. (상세한 탭 구성은 저와 살짝 다를 수 있습니다 😈 )

왼쪽에 있는 Depot, Workspace 뷰에 작업할 파일 목록이 보여야하는데 처음에는 보이지 않을겁니다.
아직 워크스페이스와 연결된 depot 스트림에서 데이터를 동기화하지 않았기 때문이죠.
Get Latest를 눌러서 최신화를 해보면 파일들이 최신 데이터 상태로 동기화될겁니다.

Get Latest를 하면 오른쪽 이미지 처럼 폴더 내에 파일이 생긴 것을 확인하실 수 있습니다.
(설마 Get Latest를 하고 있는데 Perforce 서버가 죽거나 다른 분이 파일을 다 삭제하지 않았다면요 🤡 )

파일 작업을 하려면 Perforce에서는 Check Out하고 작업을 시작해야합니다.
(Check Out을 하지 않고 작업을 시작할 경우 각 OS 파일 시스템에서는 파일 잠금을 해제하라고 경고창이 나올거에요.)

Code 파일(Non Exclusive File) 작업

코드, 텍스트 파일 혹은 Non Exclusive 파일 작업의 경우, Check Out 후 바로 작업할 수 있습니다.
Check Out and Open을 눌러주시고 중간에 Select Pending Changelist 창에서 Changelist를 생성합니다.
(이미 작업중인 Changelist에도 추가할 수 있으나 처음 작업한다는 가정하에 Changelist 생성해보겠습니다.)

default Changelist 생성 후 파일이 열립니다. 파일을 수정하고 저장해보았습니다.
Pending 탭에 있는 빨간색 세모 아이콘이 있는 default Changelist에 파일이 있을거에요.

파일 항목에서 마우스 오른쪽 클릭 후 “Diff against have revision”을 해보면 현재 가지고 Revision과 아직 반영하지 않은 수정한 내역의 변경 사항을 확인할 수 있습니다.
(P4V와 함께 사용되는 P4Merge가 실행될겁니다. P4Merge가 없다면 설치하거나 다른 IDE를 통해서 볼 수 있어요.)

수정한 파일 내용이 문제가 없는 것을 확인했다면 실제 스트림에 반영하기 위해 Changelist를 Submit 합니다.

1. Pending Changelist 항목에서 마우스 오른쪽 클릭 후 Submit을 선택합니다.
2. Submit Changelist 창에서 Changelist 설명(Description) 항목에 값을 입력합니다.
   1. 설명에는 작업에 대한 상세 내용과 ITS(jira, redmine 등)를 사용한다면 issue 키를 입력합니다.
   2. Perforce job을 사용한다면 job을 입력하기도합니다.
3. 모든 값이 잘 입력되어있다면 Submit!
4. 변경사항(Changelist)이 잘 제출되었는지는 History 또는 Submitted 탭에서 확인할 수 있습니다.

Asset 파일(Exclusive File) 작업

앞서 코드, 텍스트 파일은 Non Exclusive 파일이어서 체크아웃 후 바로 작업가능한 것으로 말씀드렸습니다.
주로 이미지 파일이나 게임 개발시 사용하는 머터리얼 애셋 등은 대부분의 경우 Exclusive로 설정되어있습니다.

Exclusive로 설정되어있을 경우 내가 작업하고자 A.png 파일을 체크아웃 할 경우,
다른 사람은 내가 체크아웃을 해제할 때까지 A.png 파일을 사용할 수 없습니다.

이미지 파일 또는 애셋 파일들은 여러 사람이 동시 작업할 경우 변경 사항의 컨플릭트를 해결하기 어렵기에
동시 작업을 할 수 없도록 약속을 만들었다고 이해하시면 좋을 것 같습니다.
(SVN, Git lfs에도 있는 파일 Lock 기능입니다.)

• pineoc_main3(user1)에서 test1.png 파일을 수정하기 위해 test1.png를 체크아웃합니다.
• pineoc_main(user2)에서도 test1.png 파일을 수정하려고했더니 이미 Lock이 되어있어서 체크아웃할 수 없습니다.
• pineoc_main3(user1)에서 작업이 끝나고 Lock이 풀려야 pineoc_main(user2)에서 작업이 가능합니다.

위 경우는 동일한 사용자의 워크스페이스 뿐만 아니라 다른 사용자의 워크스페이스에서도 체크아웃이 이뤄지면 파일은 잠기게됩니다 (Lock).

이후 작업을 완료하고 Submit하는 과정은 텍스트 수정 작업과 동일합니다.

작업된 Changelist 확인하기

워크스페이스에서 체크아웃, 파일 수정, 서밋까지 했으니 잘 반영되었는지 확인해보겠습니다.
보통은 작업 후 잘 반영되었는지 History탭에서 Revision을 확인해봅니다.

왼쪽은 워크스페이스에서의 History, 오른쪽은 리모트 depot 스트림의 History입니다.

서밋한 내용이 정확히 반영되었는지 보고 싶다면 해당 리비전에 마우스 오른쪽 클릭 후 diff를 이용해 확인해볼 수 있습니다.
(이미지도 어떤 변경이 있었는지 알 수 있지만 다른 바이너리 파일들은 안됩니다.)

마무리

이렇게 워크스페이스 생성부터 파일 서밋까지 간단하게 정리해보았습니다.
Perforce를 사용하는 곳이 많지 않다보니 하나하나 가이드 문서가 소중한 느낌이긴하네요. 조금조금 팁이 생길 때 마다 포스트 남겨보겠습니다.
이 문서가 하시는 업무에 도움이 되기를 바랍니다. 🙇‍♂️

다른 Perforce 가이드 문서들

• P4V 소개 - 기본 개념 및 Cheat Sheet
• Perforce Client(P4V) basics
• Perforce(P4V) bookmark(북마크)
• Perforce(P4V) Revision Graph(리비전 그래프) 기능
• Perforce(P4V) Search(검색) 기능
• Perforce(P4V) Workspace(작업공간) 관리
• Perforce(P4V) Stream(스트림)
• Perforce Stream, task stream / 태스크 스트림
• Perforce(P4V) Time lapse 기능

Blender 2.93 Mac OS에서 시작시 크래시

이번에 컴퓨터 그래픽스를 공부하면서 렌더링이나 그래픽 애셋 작업이 어떤 것인지 알아보려고 Blender를 설치해보았습니다.

https://www.blender.org/

Mac OS에 설치하고 실행해보았는데 크래시가 발생하는 겁니다.

어떤 크래시인가?

크래시 발생에 대한 세부사항은 다음과 같았습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

Process:               Blender [39427]
Path:                  /Applications/Blender.app/Contents/MacOS/Blender
Identifier:            org.blenderfoundation.blender
Version:               2.93.4 (2.93.4 2021-09-01)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           Blender [39427]
User ID:               501

Date/Time:             2021-09-20 18:36:26.898 +0900
OS Version:            macOS 11.6 (20G165)
Report Version:        12
Bridge OS Version:     5.5 (18P4759a)
Anonymous UUID:        xxx

Sleep/Wake UUID:       xxx

Time Awake Since Boot: 44000 seconds
Time Since Wake:       2400 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Application Specific Information:
abort() called
terminating with uncaught exception of type boost::locale::conv::conversion_error: Conversion failed

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
...

크래시 내용만 골라서 확인해보겠습니다.

1

terminating with uncaught exception of type boost::locale::conv::conversion_error: Conversion failed

보니까 locale과 관련한 에러같기도한데 검색해보았더니 LOCALE 쪽 이슈라고 합니다.

해결방법?

Mac 언어 설정을 한국어/중국어/일본어로 했을 경우 발생할 수 있다고합니다.

1. 시스템 환경설정 실행
2. 언어 및 지역 선택
3. 선호하는 언어 English 첫번째로 설정 (시스템 언어 English로 설정)
4. Blender 실행
5. 문제 해결!

향후 업데이트에는 수정될 수 있겠지만 당분간은 언어 설정 변경을 통해서 문제를 우회해서 사용해야겠네요.
Blender를 사용하는데 크래시가 발생한다면 참고하여 사용해보세요.
(실행한 뒤에는 언어 변경을 하더라도 잘 동작합니다.)

Baking이 뭐죠? 🍞 🥖 🍩

⚠️ 기술적으로 깊게 다루는 글이 아닌 그래픽스, 렌더링과 관련한 공부 중에 정리한 내용입니다.
일부 기술적인 내용은 오류가 있을 수 있습니다.

사전적 의미의 Baking

• 굽다, 구워지다, 굽기
• 빵을 굽다 / 햇볕에 피부를 태운다는 뜻으로 쓴다(?)

CG(Computer Graphics)에서의 Baking은?

위키에서 설명하는 Baking을 찾아보았습니다. (번역을 돌려보겠습니다. 🤖)

베이킹은 최적화로 복잡한 고해상도 모델 또는 비싼 프로세스(예: GI, Global Illumination)의 세부 정보를 표면 텍스처(저해상도 모델에서 가능)로 렌더링하는 것이 가능합니다. 베이킹은 렌더 매핑이라고도 합니다. 이 기술은 라이트 맵에 가장 일반적으로 사용되지만 노멀 맵과 변위 맵을 생성하는 데에도 사용할 수 있습니다. 일부 컴퓨터 게임(예: Messiah)은 이 기술을 사용했습니다. 원래 Quake 소프트웨어 엔진은 즉석 베이킹을 사용하여 라이트 맵과 컬러 맵(“표면 캐싱”)을 결합했습니다. 베이킹은 LOD(Level Of Detail) 생성의 한 형태로 사용할 수 있습니다. 여기에서 다양한 요소와 재질이 포함된 복잡한 장면은 단일 텍스처가 있는 단일 요소로 근사화될 수 있으며, 그런 다음 알고리즘을 통해 렌더링 비용을 낮추고 드로콜을 줄일 수 있습니다. 또한 3D 조각 소프트웨어 및 포인트 클라우드 스캐닝에서 세부 모델을 가져와 실시간 렌더링에 더 적합한 메시로 근사하는 데 사용됩니다.

https://en.m.wikipedia.org/wiki/Glossary_of_computer_graphics#baking

Performing an expensive calculation offline, and caching the results in a Texture map or Vertex attributes. Typically used for generating lightmaps, normal maps, or low level of detail models.

오프라인에서 값비싼 계산을 수행하고 결과를 텍스처 맵 또는 버텍스(Vertex) 속성으로 캐싱합니다.
일반적으로 라이트맵, 노말 맵 또는 낮은 수준의 LOD(Level of Detail)을 생성하는 데 사용됩니다.

Texture baking, Light baking 등이 있으며 텍스쳐나 빛을 렌더링할 때 미리 만들어둔 결과물로 빠르게 효율적으로(저렴한 비용으로) 렌더링할 수 있도록 미리 만들어두는 것으로 굳이 비유하자면..

빵을 먹을때 밀가루 반죽하고 휴지하고 틀에 넣고 굽고 먹는 것이 아니라
미리 반죽 준비해두고 오븐도 예열해두고 바로 구워먹을 수 있게 준비해두는 것
(혹은 다 구워두고 먹기만하는 것) 정도로 비유할 수 있겠네요.

왜 Baking 하나요?

오브젝트를 렌더링하기 전에 미리 준비할 수 있는 것들을 준비해서 실제 렌더링할 때 가져다가 효율적으로 렌더링하는 것이 좋잖아요.
왜 효율적으로 렌더링해야하죠? 더 많은 오브젝트를 부드럽고 높은 품질로(이쁘게) 렌더링할 수 있으니까요.

미션임파서블 - 고스트 프로토콜 복도씬 https://youtu.be/k9HGylRFS-U?t=27

조금 다른 예시지만 미리 만들어두고 다른 것을 할 수도 있죠. 😈

빛과 텍스쳐 변화에 맞춰 실시간 연산 처리가 가능한 하드웨어 스펙과 기술이 늘어나고 있지만
베이킹된 텍스쳐 맵, 노멀 맵, 라이트 맵 등을 사용하면 렌더링할 때 비용을 크게 절약할 수 있습니다.

맵(Map)? 매핑(Mapping)?

텍스쳐를 이쁘고 효율적으로 렌더링하기 위해서 많은 기술들이 들어갑니다.
실제로 오브젝트의 매시(mesh)를 상세하게 만들어서 렌더링할 수 있겠지만 매시를 상세하게 만들수록 렌더링 비용이 증가하게 됩니다. 렌더링시 실제로 보이는 결과물이 거의 동일하지만 매시는 덜 자세하게 만들고 매핑 기술들을 적용하여 렌더링 비용을 줄일 수 있죠.

주로 언급되는 매핑 기술들은 범프 매핑, 법선 매핑(노말 매핑), 시차 매핑(Parallax Mapping), 변위 매핑(Displacement Mapping), 라이트 매핑(Light Mapping, Lightmap), 쉐도우 매핑(Shadow Mapping) 등이 있고 이외에도 많은 기술들이 있습니다.

사실 매핑과 관련한 내용들이 많아서 그래픽스 엔지니어, TA나 아티스트가 아니라면 다 상세하게 알기는 쉽지 않을 것 같네요.
이런 기술들이 우리가 렌더링된 영상을 볼때 적용되어있다 정도만 알아주세요. 😸

• https://ko.m.wikipedia.org/wiki/텍스처_매핑
• https://en.m.wikipedia.org/wiki/Bump_mapping
  • https://en.m.wikipedia.org/wiki/Normal_mapping
  • https://en.m.wikipedia.org/wiki/Parallax_mapping
• https://en.m.wikipedia.org/wiki/Displacement_mapping
• https://en.m.wikipedia.org/wiki/Lightmap

언리얼 엔진에서는 텍스쳐를 이런식으로 데이터들을 연결해서 머터리얼 + 매시로 물체들을 렌더링합니다.
언리얼 엔진뿐만 아니라 최신 게임 엔진에서는 위와 같은 PBR(Physically Based Rendering)을 이용하여 렌더링합니다. (표면의 재질에 따른 빛의 반사가 물리적으로 어떻게 이루어지는지를 시뮬레이션해서 그래픽을 표현하는 기법으로 https://namu.wiki/w/물리 기반 렌더링 자세한 내용은 나무위키를 참고해보세요.)

Baking할 때 주로 어떤 것을 굽나요?

앞서 살펴보았던 내용을 다시 가져왔습니다.

• https://en.m.wikipedia.org/wiki/Glossary_of_computer_graphics#baking

  Performing an expensive calculation offline, and caching the results in a Texture map or Vertex attributes. Typically used for generating lightmaps, normal maps, or low level of detail models.

오프라인에서 값비싼 계산을 수행하고 결과를 텍스처 맵 또는 버텍스(Vertex) 속성으로 캐싱합니다.
일반적으로 라이트맵, 노말 맵 또는 낮은 수준의 LOD(Level of Detail)을 생성하는 데 사용됩니다.

여기서 오프라인의 의미는 실제 렌더링이 이뤄지지 않는 환경을 의미합니다.
실시간으로 렌더링하기에 비용이 큰 라이트맵, 노말 맵, LOD를 미리 만들어두는 것이죠.
앞서 위키 링크를 첨부해두었지만 각각 항목에 대해 살펴보겠습니다.

라이트맵(LightMap)

https://en.m.wikipedia.org/wiki/Lightmap

위와 같은 화면(Scene)에 설정되어있는 빛(해, 조명 등 빛 오브젝트)에 따라 보이는 빛나는 부분과 어두운 부분에 대해 맵을 만든 것을 라이트맵(LightMap)이라고 합니다.

간단하게 라이트맵은 빛에 따라 보이는 것을 텍스처로 만들었다고 볼 수 있습니다.
실시간으로 빛을 계산해서 보여줄 필요없이 텍스처를 보여주어 렌더링시 비용을 절약합니다.

다만 라이트맵은 정적인 물체, 환경에 대해 생성할 수 있다는 제한이 있습니다.
물론 최신 게임 엔진에서 지원하는 기능 중에는 움직이는 물체에 대해 라이트맵을 생성 및 적용할 수 있는 기능을 지원할 수도 있습니다만.. 아마 빛 자체를 실시간 렌더링하는 기술이지 않을까 싶습니다.

Unity에서는 Light Prove(라이트 프로브)를 이용해서 빛의 실시간 렌더링을 일부 지원하고 있고,
Unreal Engine 5에서는 루멘(Lumen) 시스템을 이용해서 빛의 실시간 렌더링을 모두 지원한다고 하네요. (강력하다..)

잠시 딴길로 갔지만 정리해보면,
라이트맵은 빛에 따라 표현되는 것을 텍스처(이미지)로 만들어서 렌더링할 때 비용을 줄일 수 있는 친구입니다.

노말 맵(Normal Map)

https://en.m.wikipedia.org/wiki/Normal_mapping

링크는 노말 매핑이지만 노말 매핑에 사용되는 것이 노말 맵이니 참고할 수 있겠습니다.
노말 매핑은 튀어나온 곳, 움푹 들어간 곳의 빛을 왜곡하는 기법입니다. 노말 매핑을 사용하면 많은 폴리곤을 사용하지 않고 세세한 부분을 표현할 수 있습니다.

위와 같이 매시의 폴리곤 수를 줄이고 노말 매핑을 적용하면 폴리곤이 많은 매시의 효과를 볼 수 있습니다.

• 왼쪽 이미지: 평평한 텍스처 이미지입니다.
• 중간 이미지: 노말 맵으로 빛의 XYZ를 RGB로 표현한 맵 이미지입니다.
• 오른쪽 이미지: 왼쪽 이미지에 중간 이미지의 노말 맵을 노말 매핑한 최종 렌더링된 모습입니다.

정리해보면 노말 맵은 오브젝트의 굴곡을 표현할 수 있는 빛의 벡터 정보를 갖는 데이터입니다.

LOD(Level Of Detail)

https://en.m.wikipedia.org/wiki/Level_of_detail_(computer_graphics)

직역하면 세부 수준(…)이지만 오브젝트의 세부 표현을 레벨(또는 거리)에 따라 표현한다 정도로 이해하면될 것 같습니다.

LOD를 적용하면 아래와 같은 장점이 있습니다.

• 멀리있는 오브젝트를 자세하게 표현하지 않아 비용을 줄일 수 있습니다.
• 멀리있는 오브젝트를 덜 자세하게 표현하여 자연스럽게 표현할 수 있습니다.
  (실제 멀리 있는 물체를 보았을 때 작고 흐릿하게 보이는 것처럼 표현되어야 자연스럽기 때문이죠.)

언리얼 엔진에서는 LOD 0가 가장 자세하게 표현하고 LOD 1, LOD 2 이렇게 점차 덜 자세하게 표현합니다.

위 이미지는 각 플랫폼 별로 표현할 LOD 기준을 정하고 상황에 맞춰 렌더링 될 수 있도록 설정한 것을 보여주고 있네요.

LOD는 밉맵(MipMap)을 이용하여 적용할 수도 있고 언리얼 엔진처럼 LOD 레벨별로 매시&텍스쳐를 설정할 수도 있습니다.
여기서 밉맵은 렌더링 속도를 향상시키기 위한 목적으로 기본 텍스처와 이를 연속적으로 미리 축소시킨 텍스처들로 이루어진 비트맵 이미지의 집합입니다. (자세한 내용은 위키를 참고해주세요.)

정리해보면 LOD는 가까울수록 자세하게 보이게하는 방식입니다.
(구현에 따라 다르게 보이게 설정할 수도 있지만 일반적인 정의로 이해해주세요)

Baking 결과물로 뭘하죠?

베이킹 결과물인 라이트 맵, 노말 맵, LOD로 오브젝트들을 렌더링할 때에 사용합니다.
매시의 상세(디테일)를 줄이고 여러 매핑 기술을 적용해서 렌더링 비용을 줄이고 빠르게 표현할 수 있죠.

마무리: 이제 Baking이 뭔지 대략 이해했나요?

저는 처음에는 Bake, Baking이 그냥 빵을 굽는 정도의 뭔가 미리 컴파일 같은 것을 해두고 사용한 것인가 싶었는데요.
이번에 정리하면서 베이킹을 하고 반영하기 위해 많은 기술들이 들어간 것을 공부할 수 있었습니다.

주로 위키를 통해서 베이킹이나 그래픽스와 관련한 내용들을 알아볼 수 있었는데 조금 더 깊게 그래픽스 엔지니어링과 관련한 일반적인 지식도 공부하고 싶어졌네요.

https://gabrielgambetta.com/computer-graphics-from-scratch/

컴퓨터 그래픽스를 한번 쓱 훑어보기 좋을 것 같아 한번 읽어보고 포스트 남겨보겠습니다. 😄

Low level Graphics API (저수준 그래픽스 API)

DirectX, Vulkan을 소개하기에 앞서 저수준 그래픽스 API는 뭔지 알아봐야겠죠?

https://en.wikipedia.org/wiki/List_of_3D_graphics_libraries

위키에서는 3D 그래픽스 라이브러리로 이야기하고 있지만 그래픽스 API로 이해하고 보시면될 것 같습니다.
말 그대로 컴퓨터에서 3D를 볼 수 있게하는 그래픽스 엔진, 라이브러리로 이해하시면 편하겠네요.

이런 API를 통해서 언리얼 엔진이나 각종 게임 엔진에서 오브젝트들을 렌더링하고 그래픽 결과물들을 보여주고 있습니다.

DirectX, Vulkan 소개

DirectX

https://ko.wikipedia.org/wiki/DirectX

마이크로소프트에서 만든 주로 게임 개발에 널리 쓰이고 있는 API입니다. (멀티미디어를 위한 API)
DirectX에는 2D, 3D 등 그래픽 렌더링을 위한 API가 포함되어있습니다.

DirectX는 마이크로소프트 플랫폼(Windows, Xbox)에서 동작하는 그래픽스 API로 많은 게임에서 사용되는 API입니다.
현재 최신 버전은 12버전으로 Dx12, D3D12로 많이 부르기도합니다.

관련 자료들은 마이크로소프트 페이지에서도 확인하실 수 있으니 참고해보세요!

• https://docs.microsoft.com/en-us/windows/win32/direct3d12/direct3d-12-graphics
• Youtube Videos: https://www.youtube.com/channel/UCiaX2B8XiXR70jaN7NK-FpA

Vulkan

https://ko.wikipedia.org/wiki/%EB%B2%8C%EC%BB%A8_(API)

Vulkan은 크로스 플랫폼 3D 그래픽스 API입니다. 모바일, 리눅스, 마이크로소프트 플랫폼 등에 사용될 수 있다는 뜻이죠.
크로노스 그룹에서 OpenGL의 차세대 버전으로 준비하다가 Vulkan이라는 이름으로 릴리스되었습니다.

OpenGL처럼 게임이나 미디어 처럼 고성능 실시간 3D 그래픽스 앱을
모든 플랫폼에서 고성능으로 CPU를 적게 사용하도록 개발하는 것을 목표로 만들어진 API입니다.

영상에서는 기존 OpenGL 보다 Vulkan이 CPU 코어 활용성이 좋고 에너지를 덜 쓰는 것을 비교해서 보여주고 있네요.

DirectX 11, DirectX 12, Vulkan 뭘 써서 개발해야할까?

요즘 게임 개발을 하는데 바로 저수준 그래픽 API를 사용해서 개발하는 경우는 별로 없을겁니다.
언리얼 엔진이나 유니티 등 상용 엔진들을 사용해서 게임 컨텐츠를 개발하고 있죠.

컨텐츠 개발 이후 최적화에 있어서 어떤 것을 중점으로 최적화를 할지, 어떤 플랫폼에 런칭을 할지에 따라 위 질문에 있는 모든 것을 사용해야할 수도 있습니다.
Dx11이 Dx12 보다 버전이 낮지만 현재 개발된 환경에 따라 11 버전을 사용해야할 수도 있겠죠.
API에 맞게 최적화도 필요한 것이 있어 각 개발 환경에 맞춰 개발해야한다 정도로 이야기할 수 있을 것 같습니다. (너무 정론이네요 😂)

DirectX vs Vulkan?

2개의 API를 확인해보았으니 비교를 안해볼 수 없죠! 사실 Youtube에서 2개의 API를 치면 많이 나오는 것이 비교내용입니다.
게이머 입장에서는 그래픽 품질은 좋고 FPS가 잘나오면 최고이니까요. 게임 개발 엔진들에서도 각 API를 사용하여 개발할 수 있도록 지원하고 있기도하구요.

영상만 보았을 때는 Dx11은 Dx12, Vulkan에 비해 안좋은 버전으로 보이지만 사실 버전에 맞춰 게임 코드도 최적화가 필요하기에 버전만 12로 올리기는 어렵습니다.

다른 블로그 글이나 아티클들을 보면 두 API를 비교한 것은 대부분 성능상의 비교가 대부분인데요.
이건 사실 하드웨어 + 게임(앱) 마다 천차만별이라서 뭐가 더 좋고 나쁘다를 판별하기는 어렵다고 생각합니다.

마무리

사실 2개의 API를 비교하고 차이점을 정리하기에는 어려움이 있네요.

각각 그래픽을 렌더링하기 위해 다른 동작을 사용하고 있는 것도 있고 기본 개념이 같은 것들도 있었습니다.

이번 포스팅을 위해 공부를 얕고 짧게했지만 누가 우위에 있냐는 크게 중요하지 않은 것으로 결론을 내렸습니다.

아마 다음에는 하나하나 조금 더 깊게 공부할만한 주제로 찾아올 수 있지 않을까 싶네요.

다음에는 게임 개발에 필요한 그래픽스에 대해 조금이나마 더 알 수 있는 지식으로 찾아오겠습니다. 감사합니다. 😈

Perforce Stream(스트림)?

지난 포스트에서 작업공간(workspace)를 살펴보았는데요. Perforce(P4V) Workspace(작업공간) 관리
이번에는 작업공간과 연결되는 서버 쪽 작업공간, 스트림을 살펴보겠습니다.
(작업공간보다는 브랜치가 더 익숙한 것 같긴합니다 😸)

가이드 문서: perforce - about streams

Stream Depot

Git에서 저장소(Repository)와 같은 역할을 하는 Depot입니다.
Depot 내에는 많은 스트림들이 있고 여러 유형의 스트림이 있습니다.

스트림 유형(Stream types)

• Mainline: 최상위 스트림으로 메인 브랜치로 볼 수 있습니다.
• Release: 안정적인 소스 상태로 관리하기 위한 스트림으로 주로 안정적인 릴리스를 준비하기 위해 사용하는 스트림입니다.
• Development: 개발이 이뤄지는 피쳐 스트림입니다.
• Task: 작은 단위의 작업을 할 때 사용할 수 있는 특수한 스트림입니다. 자세한 내용은 링크를 참고하세요.
• Virtual: 특정 인원에게 제한된 뷰를 제공하기 위한 스트림입니다. 자세한 내용은 링크를 참고하세요.

스트림 그래프(Stream Graph)

스트림 그래프를 보면 스트림간의 부모-자식(Parent-child) 관계를 설정할 수 있다는 것을 알 수 있습니다.
이 관계에 따라 코드의 변경 사항을 전파할 수 있습니다. (rebase, merge할 수 있다는 이야기입니다.)

그래프 방향에 맞춰서 머지 다운(merge down), 카피 업(copy up)이라는 액션을 통해 소스를 머지, 리베이스합니다.
가이드 문서에서는 Propagation(전파)라고 표현하고 있습니다.

이 전파 방식의 목표는 안정적이지 않은 스트림을 보다 안정적인 부모 또는 자식으로 최신 상태를 유지하여
변경 사항이 덜 안정적인 스트림에서 보다 안정적인 스트림으로 전파될 때 덮어쓰지 않도록 하는 것입니다.

가이드 문서에 있는 내용을 가져왔더니 좀 어렵게 설명이 되었네요. 😢
“스트림을 안정적으로 만들고 유지하는 것을 계층으로 전파하는 방식을 통해 이뤄질 수 있도록 했다” 정도로 이해하면 될 것 같습니다.

그래프에 있는 이미지를 짧게 살펴보면,

• rel1 : 릴리스 타입의 스트림으로 main1을 통해 머지 다운, 카피업 (전파)합니다
• main1 : 메인라인 타입의 스트림으로 rel1과 전파할 수 있으며 dev1, dev2과 통신(전파)할 수 있습니다.
• dev1, dev2 : 각각 개발 타입의 스트림으로 main1과 전파하며 각자 dev11, dev22와 전파할 수 있습니다.
• dev11, dev22 : 개발 스트림의 개발 스트림으로 main1에는 직접 전파하지 못하고 dev1, dev2를 통해 전파할 수 있습니다.

여기서 각 스트림 노드에 회색이냐, 파란띠가 둘러져있냐는 부모 스트림 상속(Inherit) 유무를 뜻합니다.
파란띠는 noinherit 으로 상속하지 않았다는 표시, 회색 노드는 상속했다는 표시입니다.

상속한 경우 부모 파일을 공유하거나 다른 경로에 맵핑할 수 있습니다. 자세한 내용은 스트림 뷰 설정에서 확인할 수 있습니다.
(스트림 뷰 설정도 내용이 많아서 따로 정리해서 공유하겠습니다.)

스트림 정리!

짧게 살펴본 스트림 정리해보겠습니다.

1. Perforce에는 Depot(저장소) 하위에 스트림들이 있습니다.
2. 스트림은 git에서 브랜치 와 비슷한 친구로 이해할 수 있습니다.
3. 스트림은 계층 구조를 가질 수 있고 여러가지 타입으로 설정할 수 있습니다.
4. 스트림 간의 코드 전파는 git 브랜치와 다르게 머지 다운, 카피 업과 같은 액션으로 코드를 머지하고 싱크합니다.

스트림 정리는 이만 마치고 다음 포스트에서 스트림 뷰 설정과 상속에 대해 공부하고 정리해보겠습니다. 😸

다른 Perforce 가이드 문서들

• P4V 소개 - 기본 개념 및 Cheat Sheet
• Perforce Client(P4V) basics
• Perforce(P4V) bookmark(북마크)
• Perforce(P4V) Revision Graph(리비전 그래프) 기능
• Perforce(P4V) Search(검색) 기능
• Perforce(P4V) Workspace(작업공간) 관리
• Perforce(P4V) Stream(스트림)
• Perforce Stream, task stream / 태스크 스트림
• Perforce(P4V) Time lapse 기능