Minecraft 1.16.5, 26.3용 Structure Layout Optimizer 모드

가능한 한 일반적인 Jigsaw 구조물 생성을 최적화합니다. 기본적으로 이 모드는 구조물의 외형을 전혀 바꾸지 않는 것을 목표로 합니다. 단지 구조물이 더 빠르고 효율적으로 생성되도록 하려는 것뿐입니다. 그게 전부입니다.

다음은 수행된 최적화에 대한 더 기술적인 세부 사항입니다. 이 모드를 모드팩에서 실행할 때 발견되는 충돌이나 문제를 보고해 주세요!

• VertexShape의 최적화되지 않은 호출을 BoxOctree로 대체하여 조각들이 전체 구조물 대신 주변 조각들만 교차 검사하도록 합니다.

• 기본적으로 바닐라는 구조물 레이아웃을 위해 조립 중인 조각들의 경계를 저장하는 데 VoxelShape를 사용합니다. 새 조각을 추가할 때, 다른 조각과 교차하지 않고 레이아웃에 맞는지 확인해야 합니다.

문제는 VoxelShape가 이 목적에 적합하지 않다는 것입니다. VoxelShape가 다른 VoxelShape와 교차하는지 확인할 때 모든 꼭짓점을 비교하기 때문입니다. 조각이 매우 많은 Jigsaw 구조물에서는 유효한 조각이 레이아웃에 추가될수록 이 교차 검사가 크게 느려집니다. 재귀적인 Jigsaw 구조물에서 많은 수의 조각을 생성할 때 렉이 발생할 수 있습니다.

여기서의 최적화는 일반 VoxelShape를 내부에 BoxOctree 구현을 담은 더미 VoxelShape로 대체하여 BoxOctree를 필요한 곳으로 전달하는 것입니다. 이 BoxOctree는 교차를 확인할 때 들어오는 경계 상자에 가까운 조각들만 검사합니다. 따라서 대부분의 조각은 검사에 영향을 주기에 너무 멀리 있으므로 무시되어 교차 검사 시간이 걷잡을 수 없이 늘어나는 것을 방지합니다.

• Jigsaw Block이 완전히 막혀 있는지 확인하여 자식 rigid 조각 검사를 건너뛸 시점을 파악합니다.

• 바닐라에서는 부모 조각의 모든 Jigsaw Block이 자식 조각의 모든 Jigsaw Block을 검사하여 두 조각을 연결할 시점을 파악합니다. 문제는 부모 조각의 Jigsaw Block이 구조물 경계의 가장자리를 향하고 있거나 다른 별개의 조각을 향하고 있다면, 그 Jigsaw Block은 rigid 구조물 조각을 생성할 공간이 전혀 없다는 것입니다. 따라서 이 rigid 자식 조각 검사를 건너뛰고 다음 조각을 검사하도록 게임에 지시할 수 있습니다. 이는 값비싼 Jigsaw Block 일치 검사를 많이 수행하지 않아도 되게 해줍니다. 특히 Jigsaw Block이 엄청나게 많은 구조물에서 그렇습니다.

• (26.2 이하) Jigsaw target/facing 일치를 약간 더 최적화된 버전으로 대체합니다.

• 블록 속성 가져오기 횟수를 절반으로 줄입니다. 바닐라는 각 JigsawBlock에 대해 같은 속성에서 top과 front 값을 얻기 위해 getValue를 두 번 호출하지만, 한 번만 가져와 필요한 모든 값을 얻을 수 있습니다. Jigsaw Block의 NBT에서 joints, targets, name 문자열 값을 가져오는 속도도 약간 개선했습니다.

또한 joint 데이터 검사를 byName(성능이 좋지 않음)으로 Enum으로 변환할 필요가 없도록 단순화하고, 자주 실행되는 로직의 양을 줄이기 위해 검사 순서를 재배치했습니다.

이는 Jigsaw Block이 매우 많은 Jigsaw 구조물에 도움이 됩니다. 각 Jigsaw Block이 다른 구조물 조각의 모든 Jigsaw Block에 대해 이 일치 코드를 실행하기 때문입니다.

• finalizeProcessing StructureProcessor가 없는 거대한 구조물 NBT가 이제 훨씬 빠르게 로드되도록 했습니다.

• NBT 구조물 조각이 청크에서 생성될 때, 전체 NBT 조각이 메모리에 로드된 다음 StructureProcessor가 적용되도록 여러 번 모든 위치를 반복하고, 나중에 현재 생성 중인 청크 밖의 모든 위치를 무시합니다. 이는 그다지 효율적이지 않고(정말 낭비이며) 거대한 NBT 파일의 로드 시간을 크게 증가시킵니다.

이 모드의 최적화는 경계 검사를 미리 수행하여 StructureProcessor에 전달하기 전에 필요 없는 모든 위치를 제거하는 방식으로 작동합니다. 그러나 finalizeProcessing 메서드를 재정의하는 StructureProcessor는 올바르게 작동하기 위해 모든 NBT 위치가 필요할 수 있으므로, 이런 종류의 StructureProcessor가 있는 조각에서는 이 최적화가 비활성화됩니다. 이런 구조물은 매우 적습니다. 바닐라에서는 finalizeProcessing 메서드를 재정의하는 Capped StructureProcessor를 사용하기 때문에 Trail Ruins만 이 최적화를 받지 못합니다.

• (1.21.1+) SinglePoolElement의 Jigsaw Block 목록 셔플 및 우선순위 로직을 약간 더 빠른 버전으로 대체합니다.

• 주요 이점은 값을 반환하기 전에 먼저 데이터 유형을 확인하기 위해 두 번 가져오는 대신, 한 번만 항목을 가져오는 새 메서드를 사용하여 NBT에서 selectionpriority 데이터를 약간 더 빠르게 가져오는 것입니다. 바닐라는 두 번 가져오는데, 다소 이상하고 낭비입니다.

우선순위를 위한 새로운 정렬 시스템도 시도했지만, Trials Chamber처럼 selectionpriority를 실제로 사용하는 몇몇 구조물에만 도움이 됩니다. 전반적으로 이것은 아마 가장 약한 최적화이지만, Jigsaw Block이 터무니없이 많은 Jigsaw 구조물에는 꽤 도움이 됩니다. 따라서 이 최적화를 유지할 가치가 있습니다.

Jigsaw Block이 실행되는 순서와 관련하여 바닐라 시드와의 동일성을 깨뜨릴 수 있지만, 아직 그 증거를 찾지 못했습니다.

• 이미 검사했고 현재 위치에 생성될 수 없었던 SinglePoolElement에 대한 로직 실행을 건너뜁니다.

• 이 최적화는 바닐라 StructureTemplatePool이 가중치 값에 따라 요소의 중복을 포함하는 모든 SinglePoolElement 목록을 보유한다는 사실에서 비롯됩니다. 따라서 Template Pool에서 집에 가중치 100을 지정하면, 그 집은 이 목록에 100번 들어갑니다! 그리고 레이아웃을 생성할 때 게임은 이 목록의 복사본을 만들어 섞고, 목록을 반복하여 맞는 첫 번째 조각을 생성하려고 시도합니다. 즉, 해당 위치에서 이전에 맞지 않는 것으로 확인된 중복 항목에 대해서도 검사 로직을 다시 실행합니다. 제가 하는 최적화는 이미 검사한 조각에 대한 로직을 건너뛰고 목록의 다음 조각으로 계속 진행하는 것입니다. 이는 Template Pool에서 높은 가중치 값을 많이 사용하는 구조물에 좋은 성능 향상을 제공합니다.

• 또한 deduplicateShuffledTemplatePoolElementList 구성 옵션을 켜면 Template Pool의 높은 가중치 요소에서 더 많은 성능을 얻을 수 있습니다. 문제는 이 구성이 구조물의 레이아웃을 변경하는 대가를 치른다는 것입니다. 레이아웃은 여전히 유효하고 좋습니다. 다만 구성 옵션을 끈 경우와 다를 뿐입니다. 기본적으로 그 추가 성능 향상을 얻기 위해 구조물 레이아웃의 시드 동일성을 깨뜨리는 것입니다.

• 명확히 하자면, 시드 동일성이란 시드 777을 사용할 때마다 대장장이 집 2채가 있는 마을이 한 위치에 있고, 같은 시드를 사용할 때마다 그 마을이 두 채의 대장장이 집과 함께 그 위치에 유지되는 것입니다. 이 최적화 구성을 켜고 같은 시드를 사용하면, 그 마을은 여전히 같은 위치에 있습니다. 하지만 이번에는 대장장이 집이 1채일 수 있습니다. 그리고 이 구성을 켠 채 같은 시드를 사용할 때마다 마을은 계속 대장장이 집 1채로 생성됩니다. 레이아웃은 시드에 대해 안정적입니다. 다만 구성이 꺼진 경우와 더 이상 같지 않을 뿐입니다.

• (v1.1.0+의 1.21.4): 캐시된 StructureTemplate를 생성하지 않을 때 메모리 사용량을 줄이기 위해 StructureTemplate$Palette의 StructureBlockInfo 객체 목록을 StructureBlockInfo 객체의 팔레트로 교체합니다.

• 이 최적화는 1.16.1용 contaria의 Glacier 모드에서 수정된 형태입니다. 이 최적화의 기반으로 코드를 사용하도록 허락해 준 그들에게 특별히 감사드립니다!

• 기본적으로 바닐라에서는 구조물 nbt 파일이 로드될 때마다 StructureTemplate 객체로 변환되어 캐시됩니다. 그 객체 안에는 해당 nbt 파일의 모든 위치와 각 위치의 블록 및 nbt 태그가 짝지어진 목록이 숨어 있습니다. 이것이 StructureTemplate 객체의 가장 큰 메모리 소비원입니다. 이 모드가 하는 일은 이 목록을 내부적으로 목록인 척하는 특별한 팔레트 데이터 구조 객체로 교체하는 것입니다. 팔레트의 메모리 크기는 목록보다 훨씬 작습니다! 그런 다음 월드젠에서 쿼리될 때 WeakReference로 목록을 다시 구성하여 월드젠이 빠르고 제대로 작동하도록 유지합니다. 그리고 월드젠이 끝나면 이 목록은 가비지 컬렉션되어 메모리를 다시 확보하므로, 각 StructureTemplate는 월드젠을 수행할 때만 필요한 전체 메모리를 사용하고 장기적으로는 더 작은 형태로 캐시에 유지됩니다. 단점은 이 목록이 add, remove, clear 호출로 수정될 수 없고 수정되어서도 안 되며, 그렇게 하면 예외를 던진다는 것입니다

• ModernFix에는 StructureTemplate 객체 자체를 SoftReference로 만들어 게임 메모리가 가득 찰 때 메모리에서 완전히 제거하는 mixin이 있습니다. 이는 유효한 해결책이며, 장기 플레이에서 절대 비워지지 않는 캐시에 구조물 nbts를 로드하는 메모리 누수를 막는 것을 목표로 합니다. 단점은 메모리에서 제거된 경우 조각을 파일에서 다시 직접 로드해야 한다는 것입니다. 이 mixin은 제 모드의 최적화와 함께 잘 작동합니다. 아마 일어날 일은 제 모드가 StructureTemplate의 메모리를 더 작게 만들어 ModernFix가 더 많은 StructureTemplate를 메모리에서 완전히 제거하지 않고 유지할 수 있게 하는 것입니다. 이론적으로는 장기적으로 더 많은 캐시 적중을 허용할 것입니다.