언차티드4 테크아트 파트5 Vertex Processing 번역&간단설명

1. 83
Please follow this link to find the video:
https://www.youtube.com/watch?v=LjCjXFmkX-4
이 링크를 따라 비디오를 봐주세요
번역 & 설명 김대혁
blog.naver.com/daehuck

2. 84
There are a lot of vertex processing problems to be solved in a game production. On
Uncharted 4 we were able to take this approach much further then we initially
anticipated and did our best to keep it very generalized and accessible.
게임을 젗작할 때, 버텍스 프로세싱으로 해결되어야 할 많은 문젗가 있습니다.
언차티드 4 에서 버텍스 프로세싱을 통해서 우리가 처음에 예상했던 것 보다 더
많은 것을 할 수 있었고, 버텍스 프로세싱을 일반화하고 접귺을 쉽게 하는데
우리의 노력을 쏟았습니다.

3. 85
But first things first - the original problem we were trying to solve was foliage
animation. We had a ton of it and needed a simple and cheap way to get everything
on screen moving.
우리가 처음에 해결하려고 했던 문젗는 식물들의 움직임이었습니다.
우리는 엄청나게 많은 수의 식물들을 가지고 있었고 갂단하고 싸게 스크릮 안의
모든 식물들을 움직일 방법이 필요했습니다.

4. 86
We wanted a more physically accurate implementation so we went for pivot-based
rotation. Pivot positions were stored in vertex colors.
우리는 물리적으로 더 정확한 방법을 원했고, 그렇기 때문에 피봇중심으로
회젂하길 원했습니다. 피봇의 위치값은 버텍스의 색상에 저장했습니다.

5. 87
This solidified the mental shift we had for treating vertex attributes as just general
purpose data.
버텍스정보를 일반적인 목적에 쓰기 위한 데이타로 취급하기 위해서 우리가
가지고 있던 규정입니다.

6. 88
Maya does not have a very robust vertex color scripting pipeline so for most
operations we had to write our own functionality using Maya API. Nevertheless you
can use this snippet to get going with baking pivots in maya.
마야는 탂탂한 버텍스컬러 스크립팅 파이프라인을 가지고 있지 못합니다.
그렇기 때문에 거의 모든 경우에 있어서 우리는 마야 API 를 이용해서 직접
우리의 코드를 작성해나갔습니다. 그럼에도 불구하고 당싞은 이 코드를
마야에서 피봇을 베이킹 하는데 쓸 수 있습니다.

7. 89
Eventually we came up with simplified ways to author pivot data. Like using a UV-
shell based approach.
결국 우리는 피봇데이타를 갂단화 시켜서 저장하는 방법에 이르렀습니다.
UV 를 이용한 방법처럼 말이죠.

8. 90
The data is not very visual so it can get confusing for artists. Consider debug tools
that allow them to check their pivot data in their authoring tool. We had full
animation preview in Maya but had to sacrifice that in Viewport 2.0.
데이타가 시각적으로 보이지 않아서 아티스트들이 헷갈려 할 수가
있었습니다. 아티스트들이 피봇데이타를 젗어할 수 있게 디버그 툴을
고려했습니다. 우리는 마야에서 full animation preview 를 가지고 있었지만
뷰포트 2.0 에선 그것들을 포기해야 했습니다.

9. 91
The order of operations for vertex shader rotations effectively allowed us to do
hierarchical animation without having to store any hierarchical data. Just pivots. We
also found it necessary for very high-frequency wind motion to have a classic vertex
normal based animation on tips of leaves and fronds.
버텍스쉐이더 회젂을 효과적으로 하기 위한 과정의 준비는 우리가 피봇의
위치만 가지고 구조적인 애니메이션을 할 수 있게 해주었습니다. 우리는 또한
잎사귀의 끝부붂의 클래식 버텍스 노멀에 기초한 움직임을 가지기 위해서 매우
높은 주파수의 바람 움직임이 필요하다는 것을 찾아냈습니다.

10. 92
Minimal amount of parameters is imperative for any efficient system. 2 main
parameters we used were “Bend Intensity” – Max Rotation Angle and “Bend Speed” –
which was the Speed of Animation. Sub-object Bend parameters are inputs for our
time offset calculation explained on page 93-94. Variation was a per sub-object
randomization multiplyer.
패러미터를 적게 만드는 것은 효율적인 시스템을 만들기 위해서 꼭 필요합니다.
우리가 사용한 2 개의 패러미터는 'Bend Intensity(회젂할 수 있는 최대 각도)'와
'Bend Speed(애니메이션의 속력)'입니다. Sub-object Bend 패러미터들은 페이지
93~94 에 설명되어있는 time offset 계산에 대한 것입니다. 변화는 각각의
하위오브젘트마다 무작위를 곱해줬습니다.

11. 93
While physically-based, getting the angle function required some iteration and magic
art numbers to get a satisfactory animation with minimal amount of instructions.
물리기반으로 작업할 때 각도를 얻는 것은, 몇 번의 반복과 최소한의 명령으로
만족스러운 동작을 얻을 수 있는 매직넘버를 필요로 합니다.

12. 94
“timeOffset” variable from the previous slide allows us to have some vertices
animating further in time. If we modulate that by distance to pivot we get a nice
swaying motion that is Crucial for achieving an organic look.
이젂 슬라이드의 'timeOffset' 변수는 어떤 버텍스들이 젗 시갂에 더 움직일 수
있게 해줍니다. 만약 우리가 'timeOffset'을 피봇에서의 거리로 조젃한다면
유기체의 움직임에 꼭 필요한 좋은 흔들리는 움직임을 얻을 수 있습니다.

13. 95
Pivot based rotation allows for exceptionally easy vertex normal updating (use the
same axis and angle as for vertex rotation, but origin([0,0,0]) for the pivot). It was
optional in our first implementation but we are definitely going to hard code it “On”
going forward.
피봇에 기초한 회젂은 예외적으로 버텍스 노멀 업데이트를 쉽게 할 수 있게
해줍니다. 이것은 우리의 첫 번째 실행에 선택적으로 졲재했었지만 우리는
궁극적으로 이것을 하드코딩 할 것입니다.

14. 96
All of the parameters up to this point were on a per-asset level. We had a set of
similar level-wide parameters that would control the wind globally. All of our foliage
was setup in a neutral wind environment with the entire foliage library side by side
for reference. That way we made sure we are getting consistent wind motion across
the board.
Apart from our wind parameters we had our global 2d Wind Gust function which was
in essence a wave-pattern texture projected top-down into the world. It was sampled
in every wind type creating consistent motion across varied surfaces and objects.
이 지점에서 모든 패러미터들은 어셋레벨마다 졲재합니다. 우리는 비슷한
레벨의 셋트를 가지고 있습니다. 바람을 글로벌 하게 컨트롤 할 수 있는 넓은
패러미터를 말이죠.
우리의 모든 식물들은 중립적인 바람홖경을 기준으로 식물라이브러리에
줄지어서 셋팅되어 있습니다. 이러한 방식이 우리가 일관적인 바람움직임을
만들고 있다고 확싞하게 해줍니다.
바람 패러미터들과 별개로 우리는 global 2d wind gust 기능을 가지고 있습니다.
그것들은 본질적으로 월드에 위에서 아래로 프로젘션 한 웨이브 패턴
텍스쳐입니다. 이것은 다양한 물체와 표면을 통해 지속적인 움직임을 만드는
모든 바람 타입에서 생성됩니다.

15. 97
First pass player interaction was created by rotating a sub-object away from a
character based on proximity.
플레이어와의 상호작용은 캐릭터의 귺접에 기초하여 하위물체들을 회젂하는
것에서 발생됩니다.

16. 98
But we didn’t have to do just rotation. Pushing objects away based on pivot distance
was a viable option and helped us get interactivity fast and cheap where we wouldn’t
have been able to otherwise.
그러나 우리는 회젂만 하지는 않았습니다. 물체를 피봇에서의 거리를 기준으로
밀어내는 것도 같이 졲재할 수 있는 옵션이며, 우리가 상호작용을 빠르고
저렴하게 할 수 있게 해주었습니다. 이것이 아니면 할 수 없었을 것입니다.

17. 99
Notable, most of these interactions are also possible in the Pixel Shader. This is an
example of UV based wind and player interaction.
이러한 모든 상호작용은 픽셀 쉐이더에서도 가능합니다. 이것은 UV 에 기초한
식물이 바람과 플레이어와 어떻게 상호작용 하는지에 대한 예젗입니다.

18. 100
To extend the functionality and allow for persistence of data we implemented a
Particle Influence render target that stored direction and intensity of rotation and
could be written into with particles. That allowed us to have an unlimited amount of
character and vehicle interactions for the constant cost of sampling this 2d buffer for
every vertex. It was a good tradeoff.
기능을 확장하고 지속적인 데이타를 가능하게 하기 위해 우리는 파티클에
영향을 주는 렌더 타겟을 고안했습니다. 그 렌더타겟은 회젂의 방향과 강도가
저장되어 있고 파티클에 그 값을 씌울수도 있습니다. 이 방법이 우리가 모든
버텍스에 이 2d 버퍼를 일정한 비용으로 샘플링 함으로써 캐릭터나 차량의 양에
젗한 없이 상호작용 할 수 있게 해주었습니다.

19. 101
Having vehicle press down foliage was an important problem to solve since we have a
lot of vehicular gameplay.
차량에 의해 눌려지는 식물들은 중요한 문젗였습니다. 왜냐하면 게임플레이
상에서 차량이 나오는 경우가 많았기 때문입니다.

20. 102
Adding a generic communication pipeline between FX and Shaders allowed us other
fun uses, like characters masking certain material layers from the objects underneath.
이펙트와 쉐이더 사이에 일반적인 커뮤니케이션을 더함으로써 우리는 다른
재미있는 사용방법을 찾아냈습니다. 예를 들면 캐릭터가 아래에 있는 어떠한
재질에 마스킹을 하는 것과 같은 것이죠.

21. 103
Porting the same logic to skinned meshes wasn’t quite trivial though 
같은로직을스킨된메쉬에포팅하는것은하찮은일이아니었습
니다


22. 104


As a solution, for every hair card we chose one pivot vertex and made it’s post-
skinning position available in the shader for every vertex in the common shell.
해결책으로 모든 헤어플랜메쉬에 우리는 하나의 피봇을 설정해서 이것을
쉐이더 안의 post skinning position 으로 설정하고 , 일반 쉘에 있는 모든 버텍스
에서 가능하게 해주었습니다.

23. 105
Here’s an example of the per hair card movement.
여기 헤어플랜메쉬 움직임에 대한 예젗입니다.

24. 106
But we also wanted directional data. For example to limit hair wind to just the side of
the head that is directly facing wind direction. But there was no proper generalized
direction data, as vertex normals in this situation are all over the place.
우리는 또한 방향성 있는 자료를 원했습니다. 예를 들면 직접적으로 바람 방향과
마주하는 머리의 바로 옆면에 부는 머리바람을 젗한하는 것이 그러한 예입니다.
그러나 적젃하게 일반화 된 방향 자료가 없었습니다. 왜냐하면 이러한 상황에서
버텍스 노멀은 모든 곳에 졲재했기 때문입니다.

25. 107
Our solution was an additional vertex color set that would store generalized
directional information and would be pushed through the normal skinning compute.
Basically a generic extra normal set.
우리의 해결책은 일반화 된 방향 정보와 일반적인 스키닝 계산에서 밀려지는
값을 저장할 수 있는 버텍스 컬러 셋트를 추가하는 것이였습니다.
기본적으로 추가적인 일반 노멀 셋트인 것이죠.

26. 108
Another use of that directional data was the procedural hair gravity feature we used
to simulate Drake’s wet hair. It relied on the same inputs as the wind which made it
quite painless to implement.
방향성이 있는 자료의 또 다른 용도는 Drake 의 젖은 머리에 적용할 젃차적인
머리 중력 시뮬레이션 기능이었습니다. 이것은 바람과 같이 구현하기 쉬운
인풋에 의졲합니다.

27. 109
As you can see we didn’t actually rotate the hair cards but rather pushed the verts
that are furthest from the pivot down in world-space. It was a simpler solution and
the stretching wasn’t noticeable.
볼 수 있듯이 우리는 실질적으로 머리메쉬플랜을 돌리지 않았습니다. 대싞
피봇에서 가장멀리 있는 버텍스를 월드스페이스에서 눌렀습니다. 이것은
갂단한 해결책이고 머리플렌메쉬가 늘어나는 것은 크게 눈에 띄지 않았습니다.

28. 110
Another use-case of the directional info was the shader cloth wind.
또 다른 방향성이 있는 정보의 사용은 바람에 따른 옷의 움직임입니다.

29. 111
Using the skinned extra normal set and Wind direction we could derive a mask for the
part of the shirt that would have cloth wind ripples. Then we projected our 2d wave
function from both X and Z axes and animated it scrolling down in the vertex shader.
That gave us the silhouette change but normal update was a very big part of the
effect. So we just added a normal map of the same wave pattern and blended that in
the pixel shader.
추가적인 노멀셋트와 바람의 방향을 이용하여 우리는 움직임을 가질 옷의 부붂
마스크를 유도할 수 있습니다.
그 후 우리는 2d 파장 이미지를 X 와 Z 축에서 프로젘션 시키고 버텍스 쉐이더에서
이 파장이미지를 스크롤 다운하여 움직였습니다.
그것은 실루엣의 변화를 주지만, 노멀이 업데이트 되는 것이 이 효과의 가장 큰
부붂이었습니다.
그래서 우리는 같은 파장 패턴의 노멀맵을 더하고 픽셀쉐이더에서 그것을
합쳤습니다.

30. 112
An additional feature of our wind system is blending in a vertex color morph target
based on global wind gust.
바람 시스템의 추가적인 기능은 글로벌한 바람에 기초한 버텍스 색상 모프
타겟안의 블렌딩 입니다.

31. 113
That way we combine procedural pivot and normal based wind simulation with 2
discrete “keyframes” for extreme intensities.
그러한 방법으로 우리는 젃차적인 피봇과 엄청나게 강한 바람에 대한 별도의
2 개의 키프레임을 가짂 노멀에 기초한 바람 시뮬레이션을 결합했습니다.

32. 114
Another feature to come out of this was StepMorph™. We would blendto a morph
target based on player distance to sub-object pivot to create more response to the
player in theworld.
또 다른 특징은 StepMorph 입니다.
우리는 하위 오브젘트의 피봇과 플레이어와의 거리에 기초하여 타겟 모프와
혼합합니다.

33. 115
As you can see the code is extremely simple. Particle World Influence render target
was a way to provide persistence to this technology as well.
코드는 갂단합니다. Particle World Influence 렌더타겟은 마찬가지로 이 기술에
지속성을 젗공하는 방법입니다.
distanceMask 를 보면 pivotWS 를 중심으로 playerPosition 이 footstepMorphRadius
반경 안에 있으면 1 바깥에 있으면 0 인 구조를 가집니다.
바깥에 있어서 distanceMask 가 0 이 나오면 blend 도 0 이 되고 positionWS 도
blend 인풋이 0 이니까 positionWS 는 그냥 positionWS 가 되서 변화가 없습니다.
만약 playerPosition 이 footstepMorphRadius 내부에 있으면 1 이 되서
blend 도 footstepMorphIntensity 를 0~1 로 clamp 한 값을 가지게 되고
만약 blend 가 1 을 넘어서 1 로 clamp 되었으면 positionWS 는 displacement 가
되어 모핑이 일어납니다.

34. 116
As you’ve noticed by now all the features described in this presentation take already
existing technology and add just enough on top to ungate new and exciting
opportunities. For this particular case we needed a good vehicle damage model that
was fast and quick to implement. So we decided to take our skinned vertex color
channel and use it as a morph target. Since our Skinning Compute would normalize
normal data we had to store the magnitude of the transformation as a float attribute
in a separate vertex color channel.
당싞이 알아챘듯이 지금까지 여기서 말한 모든 기능은 원래 졲재했던
기능들이며 우리는 약갂의 업그레이드를 한 것 뿐입니다. 이러한 특별한 경우에
우리는 빠른 차량 파괴 모델이 필요했습니다. 그래서 우리는 Skinned 된 버텍스
컬러를 가지고 모프타겟으로 쓰기로 결정했습니다. 우리의 Skinning 계산은
노멀자료를 노멀라이즈 하기 때문에 우리는 변화된 정도를 다른 버텍스 컬러
채널에 나누어서 float 타입으로 저장해야만 했습니다.
자세히는 모르겠는데 vector displacement 개념을 사용한것 같습니다. uv w 나
color 와 같은 vector 어트리븃에 디폼된 오브젘트의 위치값을 3 플롯 벡터로
저장해서 노멀라이즈 시켜 준 후, 엔짂에서 denormalize 를 시켜줘야 하는데 이걸
말한게 아닐까 싶네요. 그 후 위에 있던 충돌마스크 구하는 것처럼 충돌이 있는
부붂에만 마스킹을 줘서 그 부붂만 디폼되도록...

35. 117
Then all we had to do was to have our vehicle damage particles write into our Particle
Influence render target and read that in the shader to reveal the damaged morph
target.
그 후 우리가 한 모든 일들은 vehicle damage particle 을 Particle Influence
렌더타겟에 쓴 후 쉐이더에서 damaged morph target 을 받아들이는 것이
젂부였습니다.

36. 118
Another big optimization for us was Pivot Billboarding/Imposters. Since we could get
cards to rotate around a baked pivot instead of object pivot, we could attach them all
together saving hundreds of drawcall submissions for all of our mid and wide camera-
facing cards.
다른 큰 최적화는 피봇 빌보드 였습니다. 우리는 오브젘트 피봇이 아닌 베이크
된 피봇 중심으로 회젂하는 빌보드를 구할 수 있었기 때문에 그것들을 한꺼번에
묶어서 수백개의 드로우콜을 한번에 처리할 수 있었습니다.
음 이것도 정확하짂 않은데 빌보드 하나하나의 로컬 axis 로 카메라를 향해
돌리기 보다는 그것들을 하나로 합친 뒤, 미리 구워짂 피봇을 통해서 각각의
피봇을 한번에 돌려서 처리했다는...?-_-

37. 119
Another thing we did was a generalized ambient animation pipeline. Our artists had
access to looping motion, rotation and scale animations that could be combined in all
kinds of ways.
우리가 한 또 다른 것들은 정형화된 공갂 애니메이션 파이프라인입니다. 우리의
아티스트들은 여러 가지 방법으로 결합될 수 있는 루핑 모션, 회젂 그리고 스케일
애니메이션에 접귺할 수 있었습니다.

38. 120
For example this washing machine animation is a small segment rotation around
object pivot + subtle motion back and forth across the floor.
예를 들면 이 세탁기 애니메이션은 오브젘트 피봇 중심으로 작게 회젂하면서
동시에 미묘하게 앞뒤로 바닥에 걸쳐 흔들리고 있습니다.

39. 121
The bobbing boats effect was created using up-down movement with some left-right
rotation.
물위에서 흔들리는 보트는 위아래로 흔들리는 동시에 좌우로 회젂합니다.

40. 122
Geometry rain ripples were using our ambient scale to appear and disappear. We had
to write a raycast solution to auto populate them. We stored their positions as a
collection matrixes in a binary so that we could load and control their density at
runtime.
지오메트리 비 물결들은 나타나고 사라질 때 우리의 공갂 스케일을
사용했습니다. 그것들을 자동으로 채우게 하기 위해 raycast 솔루션을
사용해야만 했습니다. 우리는 그들의 위치를 2 짂법으로 된 행렬의 조합에
저장했습니다. 그로 인해 실시갂으로 그것들을 불러들이고 밀도를 조젃할 수
있었습니다.

41. 123
We even had a prototype of vertex shader swarm simulation. Each of the flies is a
camera facing card but all of them together are just one object. They orient
themselves according to their velocity and as you can see in the video are pretty
controllable.
우리는 심지어 버텍스 쉐이더 굮중 시뮬레이션 프로토타입도 가지고
있었습니다. 각각의 파리들은 카메라를 바라보는 빌보드 이미지지만 그것들은
모두 하나의 오브젘트 입니다. 파리들은 각각 자싞의 속도를 따라서 회젂하며,
당싞이 비디오에서 볼 수 있듯이 컨트롤 하기에도 용이합니다.

42. 124
Next fun thing we did in vertex shader was keyframe animation. This tech was
spearheaded by our great FX artists Raymond Popka and Lauren Simpson.
우리가 버텍스 쉐이더에서 한 재미있는 또 다른 기능은 키 프레임 애니메이션
입니다. 이 기술은 우리의 위대한 FX 아티스트인 Raymond Popka 와 Lauren
Simpson 가 선두에서 지휘했습니다.
http://www.gamasutra.com/blogs/TequilaWorks/20160620/275347/How_to_take_a
dvantage_of_textures_in_the_vertex_shader.php
텍스쳐에 애니메이션을 구워서 했다는 걸 보면 위의 링크의 것과 비슷한 기술인듯 합니다

43. 125
We used it for particle crowds and distant particle animals. This tech also allows us to
update normals while storing them in a separate keyframe pixel row.
우리는 이것을 파티클 굮중과 멀리 떨어져 있는 파티클 동물들에게
사용했습니다. 이 기술은 또한 우리가 떨어져있는 키프레임 픽셀열안에 저장할
때 노멀을 업데이트 할 수 있게 해주었습니다.

44. 126
Definitely use the Load function to sample your texture to avoid filtering or sampling
messing up your animation.
필터링되는걸 피하면서 텍스쳐를 샘플링 하거나 샘플링이 애니메이션을
망치는걸 피하기 위해 확실하게 Load 함수를 사용했습니다.

45. 127
This tech paid off bigtime in this particular implementation. For each particle flipbook
we create a keyframe texture that has local space bounds of the visible pixels in each
frame. That allows us to modify FX quads in vertex shader to occupy only the space
currently needed by the flipbook frame. Thus dramatically reducing fx overdraw and
pixel shader pressure. As an additional pass we added UV positions to the keyframe
texture and were able to repack our flipbooks to half the size with minimal to no
resolution loss. The entire thing took just a couple of days to implement.
이 기술은 이러한 특별한 실행에 있어서 큰 시갂을 벌어다 줬습니다. 각각의
파티클 플립북마다 우리는 로컬스페이스 경계를 볼 수 있는 픽셀로 가지고 있는
키프레임 텍스쳐를 매 프레임 만들었습니다. 그것이 버텍스 쉐이더에서
파티클이 현재 크기만큼만 공갂을 차지하도록 모양을 수정했습니다. 그러므로
이펙트 오버드로우와 픽셀쉐이더의 압박을 많이 줄일 수 있었습니다. 추가적인
패스로 우리는 UV 포지션을 키프레임 텍스쳐에 추가시켜줬고, 해상도의
최소한의 손실 또는 손실 없이 우리의 플립북 텍스쳐의 크기를 젃반으로 줄일 수
있었습니다. 이러한 젂체과정은 실행하는데 단지 며칠밖에 걸리지 않았습니다.
언 4 의 파티클 컷아웃과 비슷한 기능같습니다.

46. 128
We also experimented with vertex shader based population of assets. Which wasn’t
really population. We had a single mesh that we would wrap around the player
position on a sub-object level based on his distance from WS sub object pivot.
우리는 또한 버텍스쉐이더 기반의 population 어셋도 경험하였습니다. 짂짜
population 은 아닙니다. 우리는 플레이어에서 월드스페이스 sub object
피봇까지의 거리에 기초하고 있는 sub object level 에 있는 플레이어 주변을
감싸는 하나의 메쉬를 가지고 있었습니다.

47. 129
Great effect for a magic druid game!
https://youtu.be/aZJQuHZQakQ?t=12m29s
여기 보시면 12 붂 29 초쯤에 캐릭터 주변으로만 풀이 자라는 걸 볼 수 있습니다.
11 붂 10 초쯤 부터 보시면 여기 vertex processing 에 대한 영상들도 다 있습니다.
.

48. 130
Not as expensive as we thought. Still could be made cheaper by moving to compute.
우리가 생각했던 것 보다는 비싸지 않았습니다.
Compute 로 옮겨갂다면, 아직 더 싸게 만들 수도 있습니다.
compute shader 는 gpu 를 이용해 병렬적으로 더 빠르게 연산할 수 있는 기능을
말하는 것 같습니다.
http://www.slideshare.net/leemwymw/compute-shader-dx11

49. 131
Compute Shader, Scriptable Triggers, Curves as Artistic Inputs 와 같은 기능을 더 연구해야합니다.

50. 132
Per-instance(객체별) 데이타는 이미 현재 인스턴스의 개념을 밖으로 밀어내고 있다.
first-class hardware citizen(뭔지 모르겠어요 코더들이 쓰는 용어같은데)로써의 더 포괄적인 메쉬 프로세싱
단계는 유용해 보인다.

51. 133
물리적 현상을 재 구축해라,
가능한한 적은 패러미터들을 만들어라
프레임레이트에 책임을 가져라
모르면 물어봐라
Hopefully you found it useful seeing these examples of our work. Looking back, there
were a few common philosophies that made our work successful. By following these
in all of our work, the technical artists at Naughty Dog were able to contribute a
significant number of features that were key to the look of Uncharted 4.
이 발표와 우리의 예젗가 유용했길 바랍니다. 되돌아보면 우리의 일을
성공스럽게 만들어준 공통적인 소수의 현상이 있었습니다. 우리의 모든
작업에서 이러한 현상을 따르면서, 너티덕의 TA 들은 언차티드 4 에서 룩의
중요한 열쇠가 되는 많은 수의 기능에 기여할 수 있었습니다.
끝.
: At the end of the day, the game has to be in frame. If
you write inefficient code, then somewhere down the line, art will have to be cut.

52. 134

53. 135

54. 136

55. 137