Keisa의 프로그래밍

Foot Ik는 경사면에 따라서 발의 위치를 수정하여 자연스러운 모션이 될 수 있도록 하는 기법이다. Foot Ik가 적용되지 않는 다면 케릭터는 허공에 붕뜬 상태로 서있게 된다. 그러나 Foot Ik가 적용되면 자연스럽게 비탈면에 맞춰 발을 이동시키고 서있을 수 있게된다. Foot Ik의 Ik는 inverse kinematics로 역기구학이라는 뜻을 의미한다. 이는 Foot Ik가 발의 위치를 수정하고나면 발의 위치에 맞추어 모델의 전신을 수정하도록 하기 때문에 이렇게 불리는 것. 연산의 순서는 이렇다. 1. 먼저 발을 기준으로 바닥면의 위치를 검사한다 2. 바닥면의 위치로 발을 옮겨준다 3. 옮겨진 발에 맞추어 케릭터의 중심인 Pelvis도 옮겨준다 간단히 표현했는데 Foot Ik 연산을 하나씩 뜯어..

step 노드: Step 머티리얼 표현식은 각 X 값이 Y의 참조 값보다 큰지 작은지에 따라 0 또는 1을 반환합니다. 아래에는 선형 그레이디언트(0에서 1)가 X 입력에 연결되어 있습니다. Y의 값(0.25)이 참조 값으로 사용됩니다. 0.25 미만의 모든 그레이디언트 값은 0(검은색)을 반환하고, 0.25 이상의 모든 값은 1(흰색)을 반환합니다. Fresnel 노드: Fresnel 은 관찰자가 바라보는 각도에 따라 반사되는 빛의 세기가 달라지는 현상을 설명하는 데 사용되는 용어입니다. 예를 들어 물 웅덩이 위에 서서 수직으로 내려다보는 경우, 반사되는 수면이 많이 보이지 않을 것입니다. 머리를 움직여 물 웅덩이의 수면이 시선과 평행이 되어갈수록, 수면의 반사면이 많아지는 것이 보일 것입니다. UE4..

참조: https://modoocode.com/255 씹어먹는 C ++ 토막글 3 - SFINAE 와 enable_if 모두의 코드 씹어먹는 C ++ 토막글 3 - SFINAE 와 enable_if 작성일 : 2019-01-05 이 글은 19113 번 읽혔습니다. 이 글은 여기 에 실린 SFINAE and enable_if 글을 바탕으로 쓰였습니다. C++ 에서 템플릿과 함수의 오 modoocode.com SFINAE는 치환실패는 오류가 아니다라는 말이다. 템플릿 매개변수에 자료형이나 값을 넣을 수 없어도 컴파일 오류가 발생하지 않고 해당 템플릿에 대해서는 코드 생성을 무시하는 현상. 템플릿 매개변수 입력에 제약을 걸어주고 함수 오버로딩 시 프로그래머가 함수 선택을 제어할 수 있게한다. 특정 형식에 대해..

1. Bug1 해당 방식대로 제작하면 여러가지 버그가 생기는데 그 중 첫번째로 카메라가 바라보는 각도에 따라서 음영과도 같은 검은 부분이 생긴다 이 버그의 원인은 카메라가 바닥 평면과 평행에 가까워질수록 발생하는 문제. 해당 버그를 제어하기 위해 MF_DTM_GrazingAngle 함수를 제작한다. 이 함수는 표면의 법선에 기반하여 값을 변조할 때 사용될 값을 반환한다. 이 값은 깊이 외곽선 임계값에 곱해질 것. 이 함수는 카메라 시야 벡터에 대해 표면이 수직일수록, 합성 커널의 픽셀 간 깊이 불연속성을 고려해야 하는 엣지로 간주해야 할 필요가 더 커질 것이다. Fresnel의 카메라와 마주보면 0을 반환하고 카메라에 수직이 될수록 1을 반환하는 성질을 이용하여 카메라와 표면 노말의 수직 여부를 판별한다..

Post Process를 이용한 Outline Shader입니다 참조 유튜브: https://www.youtube.com/watch?v=9KvUfnrHcqM&t=1886s ● 기본원리 아웃라인을 씌우는 기본 원리는 한 픽셀을 잡고 상하좌우 네 개의 픽셀과 깊이값을 검사한다. 공식: Variation = abs(Depth왼 + Depth오 + Depth위 + Depth아래 - 4*Depth가운데(타겟픽셀)) 이렇게 구해진 Variation의 값이 정해진 한계치(Threashold)를 넘으면 외곽선에 해당하므로 해당 픽셀의 색을 바꿔주면 외곽선이 그려지는 효과를 얻을 수 있다. 해당 방법은 Depth Edge Detection으로 이 방법으로는 바깥쪽의 외곽선만을 그릴 수 있다는 단점이 있다. 안쪽의 외곽선..

PC에서는 CPU에 할당된 메모리를 초과한 메모리를 사용해야할 경우 하드디스크나 SSD에서 가상메모리를 만들어 사용하는데 GPU에서 할당된 메모리를 초과한 메모리를 요구할 경우 CPU의 메모리를 사용하게 된다. 이를 스왑페이지라고 한다. 모바일에서는 단일칩 체제로 CPU와 GPU 메모리의 구분이 없다. 따라서 PC에서 가능했던 상대메모리를 끌어와쓰는 행위를 할 수 없다. 모바일에서의 스왑페이지는 하드디스크의 영역을 사용하게 아니라 메모리의 일부를 스왑페이지 용으로 할당하여 여러 앱들이 해당 메모리를 공유하여 사용할 수 있도록 한다. 따라서 모바일에서는 PC에서와 같은 스왑페이지를 사용하지 못하기 때문에 메모리 크기를 넘어서는 용량을 사용할 수 없다.

출처: https://tsyang.tistory.com/79 드로우콜(Draw Call)드로우콜 CPU는 현재 프레임에 어떤 것을 그려야 할지 정하고, GPU에 오브젝트를 그리라고 명령을 호출하는데 이 명령이 바로 드로우 콜(Draw Call)이다. 게임의 오브젝트를 화면에 렌더링하려면 우tsyang.tistory.com CPU가 GPU에게 물체의 렌더링을 요청하는 행위.  CPU와  GPU는 병렬적으로 동작하고 CPU가 GPU에 명령할 것이 생긴다면 Command Buffer에 명령을 넣어준 뒤 작업을 이어나가고 GPU는 Command Buffe를 확인하여 명령을 수행한다. CPU가 명령을 내릴 때 작업을 멈추고 지시 후 복귀하는 등의 과정이 없이 둘은 병렬적으로 지속적으로 동작을 수행하고 있다는 점이..

참조: https://lolmovies.tistory.com/12 - GPU 바운드가 발생하는 사진 렌더링에서 CPU와 GPU 모두는 프레임을 렌더링하기 위해 각자 맡은 작업을 완료해야한다. 이러한 작업 중 하나라도 완료에 오랜시간이 걸리게 되면, 프레임 렌더링에 지연이 발생할 수 있다. 원인으로 첫번째로, 비효율적인 파이프라인에 의해 발생한다 렌더링 파이프라인 중 하나 이상의 단계가 완료되는데 오랜 시간이 걸리면서 원활한 데이터 흐름을 방해하는데 이것을 병목 현상이라고 한다. 두번째로, 너무 많은 데이터를 넣으려고 할 때 발생한다 CPU가 렌더링하는데 오래 걸리는 문제가 발생하면 CPU바운드(CPU bound, CPU에 묶여있는 상태) GPU가 렌더링하는데 오래걸리는 문제가 발생하면 GPU 바운드(GP..

카메라를 기준으로 픽셀의 깊이를 기록한 Map. 텍스쳐의 형태로 저장된다. 라이트맵은 3D CG에서 빛의 방향과 세기에 따라 생성되는 빛을 받는 오브젝트의 그림자, 반사면, 면의 밝기 차이 등의 라이팅 정보를 사전에 저장하는 텍스쳐를 뜻한다. 플레이어가 바라보는 시야 및 씬의 환경 배치, 광원의 수와 조도 등에 따라서 화면에 출력되는 빛은 시시각각 다르게 보여지게 되며 이를 시각적으로 처리하는 연산에는 빛의 입자 정보를 일일이 따져보아야 하는 상당한 부하가 수반된다. 게임같은 경우, 빛을 계산하는 것이 콘텐츠의 전부가 아니기 때문에 라이팅에서 컴퓨팅 비용을 많이 사용하게 되면 게임플레이 코드 처리나 물리 연산 등에서 활용할 수 있는 자원이 줄어든다. 때문에 최대한 효율적으로 빛을 처리하고 다른 부분에서의..

출처: https://choi-dan-di.github.io/computer-graphics/shadow-mapping/ 깊이 버퍼는 카메라를 기준으로 픽셀의 거리를 기록한 Map이다. 하지만 Shadow Map은 카메라가 아니라 Light를 기준으로 깊이를 기록한 Map. 아래는 출처에서 퍼온 내용 두 단계 렌더링 쉐도우 매핑 알고리즘은 두 번의 렌더링 패스(Rendering Pass)를 통해 수행된다. 첫 번째 패스에서는 쉐도우맵(Shadow Map)이라는 특수한 텍스처를 생성한다. 두 번째 패스에서는 실제 렌더링을 수행하게 된다. 위 이미지에서 광원에서 나온 빛이 미치는 표면은 굵은 선으로 표시되었다. 이들 표면을 균일하게 샘플하여, 각 샘플점 p마다 광원까지의 거리(z)를 쉐도우맵에 저장한다. 이..