더욱 최적화된 도면

지난 달, 새 지도를 준비하면서 RAM을 덜 소모하도록 지도 선 그리기를 최적화하고 영역 다각형에 대한 일부 최적화를 시작했습니다. 매우 잘 작동했기 때문에 새로운 지도 작업에 뛰어들기보다는 선 그리기와 동일한 최적화 아이디어를 사용하여 모든 기존 그리기 코드가 새 코드로 교체될 때까지 계속하기로 결정했습니다. 여기에는 모든 메시가 어떻게 저장되고 렌더링되는지 검토하고 트랙 렌더링도 변환하는 작업이 포함되었습니다. 2주간의 작업 끝에 전체 메모리 사용량을 50% 줄이면서 렌더링 속도도 더 빨라졌습니다.

이 예는 도쿄 한가운데에 있는 수천 개의 트랙 세그먼트가 있는 복잡한 저장에서 가져온 것이며 LOD 0의 한계에서만 확대되었으므로 순수 렌더링 POV에서 가능한 최악의 경우입니다. 이 시점에서는 절차적 메시와 계산 셰이더에 들어가는 것 외에는 더 이상 최적화할 것이 없습니다. 그리고 이는 출력을 위해 임시 메모리 버퍼가 필요하기 때문에 RAM 사용량을 숨기는 것뿐입니다.

새로운 1.10 세계 지도, 모든 것이 처음부터 다시 만들어졌습니다.

이제 지도 업데이트라는 1.10의 주요 작업을 본격적으로 시작할 차례였습니다. 게임과 개발 프로세스의 이익을 위해 수백 GB의 RAM을 갖춘 값비싼 서버가 필요한 기존 변환 시스템을 사용하지 않고 대신 더 낮은 사양에서 수행할 수 있는 새롭고 느린 프로세스를 고안하기로 결정했습니다. PC에서는 며칠 내에 완료할 수 있습니다. 이렇게 변경한 이유는 이번에는 개발하는 동안 서버를 임대하지 않고도 더 큰 규모의 샘플에서 지도 출력을 분석할 수 있는 능력을 더 키우고 싶었기 때문입니다. 최종 내보내기를 위해 며칠 동안 임대하는 것은 괜찮지만, 한 달 이상 실행하면 너무 빨리 비용이 많이 듭니다.

새로운 인구 계층을 추가한 마지막 지도 추가는 이미 절반에 이르렀으며 RAM이 "단지" 128GB만 필요하며 이 크기의 베어메탈 서버를 임대하는 데 드는 비용은 월 50유로 미만입니다 . 하지만 홈 서버로 설정한 소박한 i3-12100에서 32GB RAM으로 이 작업을 수행할 수 있는지 여전히 확인하고 싶었습니다.

지금까지는 작동하지만 아직 전체 행성 OSM 변환을 시도하지 않았으므로 실패할 가능성이 여전히 전적으로 있으므로 변환 프로세스는 어디서나 빠르고 깔끔하게 다시 설치할 수 있도록 준비해야 합니다. 과거에는 Docker를 사용하여 이 작업을 수행했지만 이번에는 Nix Flakes를 사용했습니다 . 이는 훨씬 더 개발자 지향적인 도구이며 컨테이너 내부에서 자체적으로 롤링할 필요 없이 종속성 해결을 도구 세트의 핵심 부분으로 만듭니다.

변환 프로세스 자체의 경우 1.1 코드를 모두 버리고 1.3 코드 중 일부를 유지합니다. 특히 OpenStreetMap과 관련된 모든 작업은 처음부터 다시 작성되었으며, OSM 데이터를 로드하여 개체 데이터베이스로 변환한 다음 렌더링에 최적화된 타일 데이터베이스로 변환하는 모든 단계가 어떻게 수행되는지 분석하고 있습니다. 목표는 더 높은 수준의 최적화를 실현하는 것입니다. 따라서 결과 게임 맵 파일은 더 작거나 크기가 비슷하거나 크면 이전보다 더 많은 OSM 데이터와 더 높은 충실도를 포함합니다. 비록 게임이 기본적으로 그 중 일부만 사용하더라도 더 많은 OSM 태그를 포함하고 싶습니다. 미래에 유용할 수도 있고 어떤 방식으로든 모더에 노출될 수도 있습니다. 게임에서 natural=shingle과 natural=scree에 서로 다른 텍스처를 사용하지 않는 것에 대해 매우 강한 의견이 있습니까? 자유롭게 수정해 주세요. 데이터가 거기에 있을 것입니다.

하지만 지도 파일에 없는 일부 데이터가 있습니다. 특히 건물은 다시 제외될 것입니다. 지난 3년 동안 OSM의 건축 데이터는 엄청나게 향상되었습니다. 여기서 형용사는 이중 임무를 수행합니다. 왜냐하면 건물이 이제 크기로 볼 때 OSM 데이터베이스의 약 절반이기 때문입니다. 그러나 이러한 개선에도 불구하고 지도에 표시된 건물이 없는 중간 규모의 도시나 일부 지역이 누락된 도시를 탐색하는 것은 여전히 ​​쉽습니다. 게임 맵 파일을 2배 더 크게 만들려면 그럴 만한 이유가 있어야 하며 건물을 포함하면 여러 곳에서 누락된 건물에 대한 "버그 보고서"를 즉시 받게 됩니다. 그래서 제 소스가 불완전하다고 1000번 설명하기보다는, 동시에 파일을 훨씬 더 크게 만들기 위해, 데이터를 포함시키지 않습니다. 철도 인프라, 대중교통 시스템과 관련된 모든 메타데이터도 이번에는 게임플레이상의 이유로 제거됩니다. 해당 데이터를 맵에 노출하면 즉시 플레이 가능하게 만들어야 하는 "필요"가 생성되는데, 저는 이를 원하지 않습니다. OSM 데이터는 표시용으로 최적화되어 있으며 예를 들어 게임에서 트랙으로 사용할 수 있는 방식으로 구성되어 있지 않습니다.

이러한 결정을 통해 저는 중간 객체 데이터베이스를 위한 최소 능력 시스템을 구현했습니다. 1.3 임포터로부터 학습하여 공간 개체 인덱스를 게임 내 타일 그리드에서 개체를 찾는 것과 동일하게 만들어 엄청난 속도 향상을 실현했습니다. 이번에 중간 데이터베이스는 또한 일반적인 이진 트리가 아닌 해시 테이블을 사용하여 단 두 번의 파일 읽기만으로 파일에서 개체를 찾는 데 최적화된 나만의 사용자 정의 파일 형식이기도 합니다. 다른 용도로는 유용하지 않지만 꼭 그럴 필요는 없습니다.

전체 행성 가져오기 및 지도 구축을 시도하기 전에 저는 가장 복잡한 OSM 개체인 해안선과 바다부터 시작하기로 결정했습니다. 해안선은 OSM 지도의 괴물입니다. 관계를 맺으면 수백만 개의 노드가 있게 됩니다. 행성 OSM 해안선을 사용하는 대신 미리 만들어진 미리 잘라낸 물 다각형 데이터 세트를 사용합니다. 비록 나름대로의 어려움이 있기는 하지만 작업하기가 더 쉽습니다. 예를 들어, 타일 피라미드에는 여러 세부 수준이 있으며 덜 세부적인 수준에서는 다각형의 품질을 줄여야 합니다(단지 노드 수임). 수행 방법에 따라 축소하면 이음새와 얇은 공백 영역이 나타납니다. 따라서 단순화 프로세스에서는 이를 인식하고 가능하면 "극단적인" 지점을 존중해야 합니다. 또 다른 문제는 이러한 다각형이 더 작을 수 있지만 작지는 않으며 특히 군도 주변에서는 여전히 매우 복잡할 수 있다는 것입니다. 이러한 다각형에는 구멍이 있으며 불가능한 형상이 생성되는 것을 방지하려면 점을 단순화한 후 조심스럽게 삼각형화를 수행해야 합니다. 이 문제는 1.9에서 깨졌으나 1.10에서 이미 수정된 올란드 제도에서 발생했습니다.

1.10 맵 재구축 프로세스는 아직 초기 단계이지만 이제 더 많은 데이터로 확장할 수 있는 모든 기반이 마련되었습니다. 1.10은 2023년에 수행된 지난 3개의 주요 릴리스보다 개발하는 데 시간이 더 오래 걸리지만, 이상적으로는 베타 시리즈가 20GB 이상의 파일을 두 번 이상 다운로드하지 않아도 되므로 올바르게 수행하는 것이 중요합니다.

--------------------------------------------------------

구글 번역기 돌려서 어색한 부분이 있을 수 있음