지구 크기의 마인 크래프트를지도처럼 렌더링하려면 어떤 종류의 하드웨어가 필요합니까?

나는이 문제에 대해 생각하고있다. 현재 기술로 복셀 기반 게임에서 지구의 1 : 1 복제본을 만들 수 있습니까? 이 거대한지도를 저장하기에 가장 좋은 데이터 구조는 무엇입니까? 이 데이터 구조를 실시간으로 렌더링하려면 어떤 알고리즘을 사용해야합니까?

이러한 질문은 다음과 같은 가정을합니다.

• 각 복셀의 해상도는 1 입방 미터입니다.

• 간단하게하기 위해 각 복셀에는 1 바이트의 메타 데이터 정보 만 필요합니다. 이 정보는 복셀의 "유형"(지구, 물, 암석 등)을 식별하는 데 사용됩니다.

• 지구 부피는 1 * 10ˆ21 입방 미터입니다.

• "현재 기술"에는 상용 컴퓨터이지만 슈퍼 컴퓨터는 아닌 것을 포함합니다.

• 지구 지형 및 수심계 만지도 생성에 사용됩니다. 인간 건물, 식물 또는 동굴은 제외됩니다. 지하 블록은 지질 연구에 기초하여 선택 될 것입니다. 예를 들어 깊이가 3000km를 초과하면 '마그마'복셀이됩니다.

• Minecraft에서와 마찬가지로 맵은 정적이 아니며 게임 내에서 수정할 수 있습니다.

• '무한한'끌기 거리는 큰 장점입니다. 만약 당신이 날 수없고 행성 전체를 볼 수 없다면 지구 전체를지도에 표시하는 것이 무엇입니까?

내가이 문제에 대해 생각했을 때 얻은 첫 번째 결론은 지구 데이터를 선형 방식으로 저장하는 것이 불가능하다는 것입니다. 각 복셀이 1 바이트의 메모리 만 차지한다고 가정하면 맵을 저장하는 데 여전히 1 제타 바이트가 필요합니다. 따라서 어떤 종류의 압축이 필요합니다.

복셀 옥트리가지도를 압축 할 수 있다고 생각하지만 얼마나 확신 할 수는 없습니다. 이 복셀 맵의 엔트로피는 아마도 매우 낮을 것이므로 매우 높은 수준의 압축이 이루어질 수 있다고 생각합니다.

기권

이것은 이론적 인 질문입니다, 나는 복셀 지구를 쓸 의사가 없습니다.

편집하다

ESA GOCE 는 이미 지구 지오이드를 1cm-2cm 정밀도로 매핑했습니다. 이 정보는 지구의 매우 정확한 높이 맵을 생성하는 데 사용될 수 있다고 생각합니다. 이것은 지구 지형의 틈새를 채우기 위해 알고리즘을 사용할 필요를 배제합니다.

데이터 구조 오버 헤드 및 기타 논리적 / 수학적 요인으로 인해 모든 압축 방법과 같은 모든 분할 방법이 결국 더 이상의 압축이 발생하지 않는 곳에서 팬 아웃되지만 사용하는 공간 분할 방법에 따라 다릅니다. 옥트리에서 예제를 찾을 수 있습니다. 옥트리의 각 노드에 대해 의미있는 순회를 가능하게하려면 포인터를 부모 및 / 또는 자식 (데이터 구조 아키텍처에 대한 방법에 따라)에 유지해야합니다. 모든 트리 구조에는 n 개의 자식이 포함될 수 있습니다. 1 : n의 비율이 낮을수록 공간을보다 효율적으로 사용할 수 있으며 결과적으로 동일한 수의 리프 복셀을 포함하는 더 많은 조상 노드가 있어야하기 때문에 트리 트래버 설에서 오버 헤드가 더 커집니다 (약 510 조) 표면적을 나타내는 이들 중).

귀하의 인스턴스에서 주요 문제는 스토리지 비용과 전체 행성 (또는 그 일부)을 적절한 거리에서 렌더링한다는 점을 고려할 때 옥트리보다 권장하는 데이터 구조가 없습니다. 밉 매핑은 필수입니다. 가장 가까운 2의 더 높은 출력에서 ​​직경 12.8 백만 미터는 2 ^ 24 = 16.8 백만입니다. 순회 할 24 octree 레벨은 엄청난 양의 분기에 해당하며 GPU 및 CPU 모두 매우 비용이 많이 듭니다. 그러나 올바른 일을한다면 한 번에 몇 단계 만 통과하면됩니다. 그러나 필요한 공간의 양을 고려할 때 대안은 거의 없으며 그 사이에 있습니다 (아래 참조).

octrees의 밉 매핑 기능은 여러분이 기술 한 것과 같은 대량의 작업을위한 매우 강력한 도구입니다. 알려진 다른 모든 세분화 방법 (KD 트리 제외)과 달리 octree는 레벨 당 세분화를 최소로 유지합니다. 즉, 밉맵 레벨 간의 시각적 차이와 물리적 차이도 최소로 유지됩니다. 나무 아래로.

반면에 계층 적 그리드 순회가 최소로 유지되는 세계를 생성하려면 속도를 높이기 위해 공간을 절충해야합니다.

이상적인 1 : n 비율에 대해 말하면,이 점에서 kd-tree보다 더 미세한 구조는 없습니다. octree가 각 축에 대해 2로 나뉘어 2 ^ 3 = 8 개별 자식 셀이되는 경우 kd 트리는 세분화 수준 당 정확히 한 번 분할됩니다. 이에 대한 문제는 분할 할 하이퍼 플레인을 선택해야하며이 하이퍼 플레인은 3 개의 축 중 하나를 선택할 수 있다는 것입니다. 공간 측면에서는 최적이지만 동적 포털 유형 구조를 기록해야하므로 3D 탐색 (예 : 물리 또는 렌더링에 옥트리를 사용할 때의 기본 op) 인 3D 탐색을 훨씬 더 어렵게 만듭니다. 인터페이스 개별 kd- 트리 노드 사이의 .

RLE은 압축에 대한 또 다른 접근 방법이지만 RLE 압축은 1 차원이기 때문에 이와 같은 문제 (작업 기반이 구형 인 경우)에는 적용하기가 더 어렵습니다. 작동하는 축을 선택해야합니다. 행성에서는 극축을 선택할 수 있지만, 단일 축을 선택하면 최적이 아닌 각도에서 작동 할 때 렌더링 및 물리학에 대한 횡단 문제가 발생합니다. 물론 스토리지 비용을 3 배로 늘리거나 추가 최적화를 위해 6 축 (-x, + x, -y, + y, -z, + z)으로 RLE를 동시에 실행할 수도 있습니다.

따라서 귀하의 질문에 대답하십시오 (또는 아닙니다!)

어떤 종류의 하드웨어에 직접 대답하지는 않지만 octree 관점에서 보는 것이 시작 된다고 생각 합니다. 가능한 어떤 종류의 하드웨어에 당신이 실제로 무엇의 아이디어를 제공 할 수 있습니다. 이 경로를 따라가는 것이 좋습니다. 정말로 알고 싶다면 간단한 스파 스 옥트리를 구현하는 것이 가장 쉬울 수 있습니다.(참조에 Laine의 논문 참조) 구형 복셀 껍질을 그 안에 넣고 결과 공간 사용량이 어떻게되는지 확인하십시오. 거기에서 단계. 시스템 메모리가 나오기 전에 얼마나 멀리 갈 수 있는지보십시오. 시각화를 원하지 않는 한 렌더러를 작성할 필요가 없습니다. 또한 이것은 CPU에서 가장 잘 수행된다는 것을 명심하십시오 .GPU는 일반적 으로이 규모의 문제를 처리 할 메모리 용량이 없습니다. 이것이 인텔이 대규모 병렬 프로세서로 전환하려는 이유 중 하나입니다. GPGPU의 이점은 이런 종류의 시스템에 더 유리한 시스템 버스 병목 현상없이 훨씬 더 넓은 메모리 공간에 적용될 수 있습니다. 여기 또는 mathematics.stackexchange.com에 다른 것이있을 수 있습니다.

당신의 무한한 시거리 요구의 관점에서, 그러나 문제는 항상 "어떤 거리에서 얼마나 상세하게"에 달려 있습니다. 무한한 디테일을 렌더링하려면 무한한 리소스가 필요합니다. 그것이 바로 씬마다 가변적 인 밉 매핑이 작용하는 곳입니다. 또한 모든 데이터 구조는 공간에 대한 속도의 상충 관계를 구현하거나 그 반대로도 구현한다는 점을 명심하십시오. 같은 양의 엔지니어링 노력으로 더 큰 세상을 원한다면 렌더링이 적거나 느려집니다.

내가이 문제에 대해 생각했을 때 얻은 첫 번째 결론은 지구 데이터를 선형 방식으로 저장하는 것이 불가능하다는 것입니다. 각 복셀이 1 바이트의 메모리 만 차지한다고 가정하면 맵을 저장하는 데 여전히 1 제타 바이트가 필요합니다. 따라서 어떤 종류의 압축이 필요합니다.

실제 세계의 각 입방 미터의 속성을 찾지 못할 가능성이 높으므로 가정에 따라 불확실한 데이터를 생성 할 방법이 필요합니다. 따라서 알아 낸 경우 모든 데이터를 계산하고 저장할 필요는 없지만 즉시 생성 할 수 있습니다.

무엇보다도 누군가가 실제로 구멍을 파는 경우에만 계산해야하기 때문에 지구 내의 모든 복셀을 버릴 수 있습니다. 복셀이 보입니다.

지구 표면의 경우 이미지를 계산의 시작점으로 사용했을 것입니다. 어쩌면 일종의 온도 및 습도 맵을 사용하여 적용 할 블록 유형을 계산할 수 있습니다. 예 : 물, 모래 (사막), 잔디, 눈 등. 이미지에는 지구 표면의 평방 미터당 1 픽셀의 정보가 없을 것이므로 약간의 노이즈를 혼합하여 약간의 변화를 생성해야합니다. 표면. 그럼에도 불구하고 항상 같은 무작위 씨앗을 사용하는 경우 결과는 결정 론적이어야합니다.

또한 입면도의 높이를 결정할 수 있도록 입면도가 유용합니다. 그렇게하면 산 등을 추가 할 수 있습니다.

따라서 이것은 지표면에 대한 정보를 포함하는 일부 2D 이미지의 데이터 볼륨으로 요약됩니다. 내부의 모든 것에 대해 지구 중심으로부터의 거리에 따라 다른 유형의 블록을 렌더링하는 순수한 절차 적 접근 방식으로 되돌아갑니다. 그러나 위에서 말했듯이 누군가가 구멍을 파낼 때만 계산해야합니다.

변경 사항을 영구적으로 유지하려면 수정 사항 만 세상에 저장 합니다. 누군가가 구멍을 파면 주변 복셀을 절차 적으로 렌더링 할 수 있어야하므로 어떤 복셀이 제거되었는지에 대한 정보를 저장합니다.

렌더링과 관련하여 :이 작업을 수행하려면 정교한 세부 수준 및 컬링 알고리즘이 필요합니다. 카메라가 전 세계를 보여주는 확대 / 축소 수준에있을 때 모든 표면 복셀을 렌더링하는 것은 바보입니다. 이 수준에서는 복셀이 훨씬 커야하며 단순한 질감의 구면 충분할 수도 있습니다.

가장 까다로운 것은 다른 "해상도"에 대해서도 복셀 속성을 계산할 수있는 견고한 제너레이터를 사용하여 다른 수준의 세부 정보를 생성하는 것입니다.

기본적으로 Minecraft와 동일한 작업을 수행 할 수 있습니다. 그러한 양의 데이터를 만드는 대신 세계를 수학 공식으로 정의 할 수 있습니다. 데이터를 표시해야 할 때마다 공식을 사용하여 데이터를 생성합니다.

이러한 공식은 일반적으로 Perlin noise 개념을 사용하여 구성 되며 모든 수준에서 세부 사항을 허용하며 실제 세계보다 큰 산맥을 가질 수 있지만 그중 일부만 생성하도록 선택할 수 있습니다. 원하는 양의 디테일을 생성 할 수 있으므로 가까운 물건에 대해 매우 세밀한 디테일을 만들 수 있지만 필요한 디테일 수준에서 멀리 떨어진 풍경을 생성 할 수도 있습니다.

Minecraft는 방문한 모든 블록을 저장하고 변경 사항이 완료되면 생성 된 세계와 업데이트 된 세계의 차이점 만 저장할 수는 있지만 큰 블록을 저장하는 것이 더 쉬우 며 비교적 잘 압축됩니다.

나는 이것을 정말로 제한하는 게임이 없다고 생각하지만, 큰 게임 세계의 "중요하지 않은"모든 세부 사항의 공식적인 생성을 사용하는 것이 매우 일반적입니다. 단순히 로트를 생성하고 디스크에 넣는 것과는 대조적으로 필요한 접근 방식이 얼마나 일반적인지 잘 모르겠습니다.

벡터 데이터는 원하는 스케일로 스케일링 할 수있는 이점이 있으므로 지구의 육상 질량에 대한 벡터 데이터를 찾을 수 있습니다. 지구의 높이 맵과 결합하여 지형의 높이를 생성하십시오. 마지막 단계는 이미지를 기반으로 상단 블록의 유형을 선택할 수있는 상세한 위성 이미지입니다. 따라서 바위가있는 곳, 모래가있는 곳 등으로 바위를 얻습니다. 지구의 실제 내부는 아마도 생성되어야합니다 작업 할 상세한 지리 데이터를 찾을 수 없다면 Minecraft처럼 그렇게합니다. 기본적으로 XYZ 좌표 입력 만 주어지면 지리 데이터를 찾아 외삽합니다. 즉, 데이터가 제한되어 있고 나머지는 최대한 정확하게 추정합니다.