서버에서 복셀 오브젝트의 정보를 패킷으로 날릴때마다 컬러테이블을 RLE압축하는건 아무래도 낭비. 최초 접속시 캐릭터 위치 기준으로 오브젝트를 1700개나 받아가는데 아무리 간단한 코드라도 1700번이나-그것도 싱글스레드로- 돌게 할 순 없다. 따라서 다음과 같이 처리한다. 1.복셀의 기하구조가 바뀌거나 컬러테이블 정보가 바뀌었을 경우, 복셀 오브젝트를 ‘컬러테이블->RLE압축’을 위한 업데이트 링크에 넣는다. 2. 매니저에서 일정 시간마다 업데이트 링크에 들어있는 오브젝트들에 대해서 컬러테이블을 … More Voxel Horizon – 백그라운드 컬러 테이블 RLE압축 in Server
복셀당 1바이트짜리 컬러팔레트(사실상 텍스쳐 팔레트)를 사용하는데 이게 은근 메모리 많이 처먹음. 아니 메모리 처먹는건 큰 문제가 아닌데 패킷으로 보낼때가 문제. 8x8x8복셀일때 기하구조를 구현하는데 필요한 메모리는 복셀당 1비트로 64바이트면 되지만 컬러테이블은 복셀당 1바이트니 512바이트가 나온다. 최초 접속시 현재 1700개 이상의 오브젝트를 보내야 하니 패킷량이 장난 아니다. 하여간 그래서 줄이긴 줄여야겠기에 단순하게 압축을 하기로 했다. zlib를 고려했지만 … More Voxel의 컬러테이블 압축
서버로부터 Voxel 데이터 수신 후 3D Mesh빌드. 체감상 1프레임도 안떨어지는 정도로 개선했다. 서버로부터 Voxel데이터 수신 -> 멀티스레드로 Voxel데이터 -> 삼각형 매시 변환, 라이트 계산을 위한 Patch데이터 생성 -> 멀티스레드로 라이트 계산 이 과정으로 진행된다. 라이트 계산이 좀 오래 걸리는데 대략 20ms정도 초과하면 일단 끊고 라이트 계산을 종료하도록 했다. 라이트 계산을 완료하지 못한 오브젝트들은 라이트 계산을 … More Voxel Horizon – Voxel Data Streaming from Server #2
지금껏 내가 만든 게임엔진+기반 플랫폼은 언제나 로딩 속도가 충분히 빨랐기 때문에 지연로딩같은건 사용해본적이 없다. 뻥 안까고 캐릭터 로딩할때 아무도 캐릭터 로딩하는줄 모르는 정도로 빠르게 만들었다. 맵로딩할때도 로딩이 너무 빨라서 로딩시간에 보여주는 일러스트를 볼 수 없으니 로딩시간을 느리게 해달라는 요구도 받은적이 있다. 하지만 이번의 경우는 복셀 데이터를 서버에서 스트리밍 해야하고 데이터량이 적지 않을뿐더러 복셀데이터->삼각형데이터->(최적화된 충돌처리용 삼각형매시, … More Voxel Horizon – Voxel Data Streaming from Server
갑자기 필요해서 UWP, 정확히는 내 윈폰에서 배터리 상태를 얻어올 필요가 생겨서 급히 찾아봤다. Windows::Devices::Power 네임스페이스의 API를 사용하면 된다는 정보는 금방 찾았지만 C++로 구현하는 자료는 어디에도 없다. 아무리 뒤져봐도 없다. C#이라면 이런 식으로 간단하게 구현할 수 있다. 이 스타일 그대로 C++로 바꿔서 코딩해보면 컴파일에 실패한다. Battery^ 객체를 직접 억세스하는건 불가능한것 같다. 그 다음 시도. 아래와같은 방법으로 … More UWP with C++로 Battery 상태 얻어오기
네이티브 코드 체계에선 메모리(일반적인 메모리 , COM객체,Windows HANDLE 등등) 누수 탐지 기능이 반드시 필요하다. 컴파일 타임에서 논리적으로 아무리 완벽한 체계를 제공한다고 해도 말이다. 최근 MS는 COM을 사용하는 예제에서 CComPtr 사용을 적극 권장하고 있다. C++/CX에선 명시적으로 CComPtr을 사용할 필요없이 ^객체가 스마트포인터를 내장하고 있고 UWP프로젝트가 아닌 경우, 예를 들어 DX12샘플같은 경우 CComPtr을 사용하고 있다. CComPtr뿐 아니라 컴파일러 … More 명시적 종료의 필요성 #2
이전에는 GPU에서 라이트 계산과 그림자처리를 했었는데 CPU에서 하는걸로 바꿨다. 복셀 오브젝트가 2만개가 넘어가니 컬링을 해도 복셀 데이터를 Shadow Map에 그리는 시간을 무시할 수 없다. 쉐도우맵 스타일의 그림자가 크게 어울리는것도 아니고 해서 CPU기반으로 바꿨다. KD-Tree traversal로 복셀 최소단위 50x50cm 한 면씩 라이트/그림자 처리를 수행한다. 멀티스레드로 처리하고 한방에 맵 전체를 처리하거나 중간중간 복셀 데이터의 변동분에 대해서 최대 … More Voxel Horizon 개발 근황
내가 작성한 SW Occlusion Culling코드는 256×256 float 버퍼에서 1730개 정도의 삼각형을 Z-Raster / Z-Test 하는데 15만클럭 정도가 소요된다. SSE 명령어셋을 사용하는데 FPU만 사용하는것보다 2배 정도는 빠르다. AVX로 8샘플씩 처리하는 코드도 만들어놨지만 SSE만 쓰는것보다 느리다. 처음엔 싱글스레드 코드였지만 현재는 멀티스레드 4스레드를 사용한다. 내 PC의 물리코어가 4개이고 이 머신에선 4스레드보다 많은 스레드를 투입해도 성능향상이 미비하다. 그래서 현재 … More Game Dev – SW Occlusion Culling 성능
많은 프로그래머들이 2:8 이론을 들어 최적화된 코드를 작성할 필요가 없다고 주장하곤 한다. 극히 일부의 코드가 전체 성능하락의 주요 원인이라는 얘기다. 틀린 얘긴 아니다. 그러나 바꿔 얘기하면 80%의 코드가 최적화되어 있다면 20%의 성능하락 요인을 수정하지 않아도 된다는 뜻도 된다. 게다가 전체적인 코드의 최적화여부는 날 잡아서 하는 최적화에 달려있지 않다. 습관과 기초지식에 달려있다. 기초지식을 잘 습득하고 습관만 … More 최적화 무용론에 대한 반박
픽셀단위나 벅텍스 단위 억세스에선 명령어 한클럭 줄이는것도 상당히 중요하다. 이건 성능에 있어 결코 무시할 수 없는 요소이다. 이런것들을 제외하고 보면 전체적으로 성능을 떨어뜨리는 가장 큰 요인은 메모리 동적할당이다. 그러니까 힙으로부터 메모리를 할당받는 malloc,free,new,delete가 되겠다. 당연히 단편화를 줄이기 위해 힙사용을 줄이면 할당/해제 속도가 빨라진다. 미리 메모리를 pool로 잡아두고 쓰는쪽이 메모리 낭비가 심할것 같지만 경험적으로 보면 메모리 … More 메모리 사용과 성능에 대한 잡설.
yuchi's development 
댓글을 달려면 로그인해야 합니다.