Оптимизирует генерацию общей структуры Jigsaw наилучшим образом. По сути, этот мод не стремится изменить внешний вид структур. Он работает только над тем, чтобы попытаться сделать генерацию структур быстрее и эффективнее. И всё.
Вот более технические детали выполненных оптимизаций. Пожалуйста, сообщайте о любых конфликтах или проблемах, обнаруженных при использовании этого мода в ваших сборках!
- Заменяет неоптимизированные вызовы VertexShape на BoxOctree, чтобы части проверяли пересечения только с соседними частями, а не со всей структурой.
По умолчанию, ванильная версия использует VoxelShape для хранения границ собираемых частей при компоновке структуры. Когда требуется добавить новую часть, необходимо проверить, поместится ли она в компоновку без пересечения с другими частями.
Проблема в том, что VoxelShape плохо подходит для этой цели, поскольку при проверке пересечения одного VoxelShape с другим, сравниваются ВСЕ вершины. В структурах Jigsaw с большим количеством частей эта проверка пересечения значительно замедляется по мере добавления в компоновку новых допустимых частей. Может вызывать лаг-спайк при генерации большого количества частей для рекурсивных структур Jigsaw.
Данная оптимизация заменяет обычный VoxelShape на фиктивный VoxelShape, который внутри содержит реализацию BoxOctree, чтобы передать BoxOctree туда, где это необходимо. Этот BoxOctree при проверке пересечений будет проверять только соседние части относительно входящего ограничивающего прямоугольника. Это предотвращает неконтролируемый рост времени проверки пересечений, так как он игнорирует большинство частей, поскольку они слишком далеки, чтобы иметь значение для проверки.
- Проверяет, полностью ли заблокирован блок Jigsaw, чтобы знать, когда пропустить проверку дочерних жестких частей.
В ванильной версии каждый блок Jigsaw в родительской части проверяет каждый блок Jigsaw в дочерней части, чтобы определить, когда можно попытаться соединить две части. Проблема в том, что если блок Jigsaw родительской части смотрит на край границы структуры ИЛИ на другую отдельную часть, то у этого блока Jigsaw нет места для спавна жесткой структурной части. Следовательно, мы можем указать игре пропустить проверку этой жесткой дочерней части и перейти к проверке следующей части. Это избавляет от множества дорогостоящих проверок совместимости блоков Jigsaw. Особенно в структурах с огромным количеством блоков Jigsaw.
- Заменяет проверку соответствия цели/направления Jigsaw на слегка более оптимизированную версию.
Сокращает количество получаемых свойств блоков вдвое. Ванильная версия дважды вызывает getValue для каждого блока Jigsaw, чтобы получить значения top и front из одного и того же свойства, хотя можно было вызвать один раз и получить все необходимые значения. Также слегка ускорено получение значений joints, targets и строки имени из NBT блоков Jigsaw. Кроме того, упрощена проверка данных joint, чтобы не нужно было преобразовывать их в Enum с помощью byName (не производительно), и переупорядочены проверки для сокращения объема логики, которую часто нужно выполнять.
Это поможет структурам Jigsaw с очень большим количеством блоков Jigsaw, так как каждый блок Jigsaw проходит через этот код сопоставления для всех блоков Jigsaw в других структурных частях.
- Обеспечивает гораздо более быструю загрузку любых гигантских структур NBT, у которых нет StructureProcessor с finalizeProcessing.
Когда структурная часть NBT генерируется в чанке, ВСЯ часть NBT загружается в память, а затем выполняется итерация по всем позициям несколько раз для применения StructureProcessors, а затем игнорируются все позиции вне текущего генерируемого чанка. Это не очень эффективно (очень расточительно) и вызывает долгое время загрузки для гигантских NBT-файлов.
Оптимизация этого мода работает за счет ранней проверки границ, чтобы отсечь все позиции, которые нам не нужны, перед передачей их в StructureProcessors. Однако, любой StructureProcessor, который переопределяет метод finalizeProcessing, может требовать всех позиций NBT для корректной работы, поэтому эта оптимизация отключена для частей с такими StructureProcessors, которых будет очень мало. В ванильной версии только Trail Ruins не получит эту оптимизацию из-за использования Capped StructureProcessor, который переопределяет метод finalizeProcessing.
- (1.21.1+) Заменяет логику перемешивания и приоритизации списка блоков Jigsaw в SinglePoolElement на слегка более быструю версию.
Основное преимущество — слегка ускоренное получение данных `selection_priority` из NBT с помощью нового метода, который получает запись один раз вместо двух. Ванильная версия делает это дважды, чтобы сначала проверить тип данных перед возвратом значения. Немного странно и расточительно.
Также опробована новая система сортировки для приоритизации, но она помогает лишь немногим структурам, которые фактически используют `selection_priority`, таким как Trials Chamber. В целом, это, вероятно, самая слабая оптимизация, но она довольно сильно помогает структурам Jigsaw, которые имеют абсолютно невероятное количество блоков Jigsaw. Так что эту оптимизацию стоит сохранить.
Может нарушить соответствие с ванильными сидами в отношении порядка обработки блоков Jigsaw, но я пока не нашел этому подтверждения.
- Пропускает выполнение логики для SinglePoolElements, которые мы уже проверяли и которые не могут появиться в текущем месте.
Итак, эта оптимизация исходит из того факта, что ванильный StructureTemplatePool содержит список всех SinglePoolElements с дубликатами элементов в соответствии с их значением weight. Таким образом, если в Template Pool вы укажете weight 100 для дома, этот дом будет помещен в этот список 100 раз! И при генерации компоновки игра создаст копию этого списка, перемешает ее и будет перебирать список, пытаясь создать первую найденную часть, которая подходит. Это означает, что она повторно запустит логику проверки для дублирующихся записей в этом списке, даже если ранее было установлено, что они не подходят для этого места. Оптимизация, которую я делаю, заключается в пропуске логики для частей, которые мы уже проверяли, и переходе к следующей части в списке. Это дает хороший прирост производительности для структур, которые используют много высоких значений weight в своих Template Pools.
Кроме того, вы можете включить опцию конфигурации `deduplicateShuffledTemplatePoolElementList`, чтобы получить еще большую производительность от элементов с высоким weight в Template Pools. Проблема в том, что эта настройка comes at a cost of changing the layout of the structure. Компоновка по-прежнему действительна и хороша. Она просто будет отличаться от той, что была бы при выключенной опции. По сути, это нарушает seed parity для компоновок структур specifically to get that extra performance boost.
*Чтобы было понятно, seed parity означает, что каждый раз, когда вы используете сид 777 и в определенном месте есть деревня с 2 домами кузнецов, при каждом использовании этого же сида эта деревня будет оставаться на том же месте с двумя домами кузнецов. При включенной этой опции оптимизации и том же сиде, деревня все равно будет на том же месте. Но в этот раз в ней может быть 1 дом кузнеца. И каждый раз при использовании того же сида с включенной этой настройкой деревня будет генерироваться с 1 домом кузнеца. Компоновка стабильна относительно сида. Но она просто больше не совпадает с той, что была бы при выключенной настройке.
- (1.21.4 с v1.1.0+): Заменяет список объектов StructureBlockInfo в StructureTemplate$Palette на палитру объектов StructureBlockInfo для уменьшения использования памяти, когда этот кэшированный StructureTemplate не генерируется.
Эта оптимизация является модифицированной версией из мода Glacier от contaria для 1.16.1. Особая благодарность им за разрешение использовать их код в качестве основы для этой оптимизации!
По сути, в ванильной версии каждый раз, когда загружается nbt-файл структуры, он преобразуется в объект StructureTemplate и кэшируется. Внутри этого объекта находится список ВСЕХ позиций из этого nbt-файла в паре с блоками и nbt-тегом на каждой позиции. Это самый большой потребитель памяти для объектов StructureTemplate. Что делает этот мод, так это заменяет этот список специальной структурой данных палитры, которая притворяется списком. Объем памяти палитры значительно меньше, чем у списка! Затем, при запросе для генерации мира, он сконструирует список снова как WeakReference, чтобы генерация мира оставалась быстрой и работала правильно. И когда генерация мира завершена, этот список будет собран сборщиком мусора, чтобы снова освободить память, позволяя каждому StructureTemplate использовать полный объем памяти только при генерации мира, но оставаться в кэше в меньшей форме в долгосрочной перспективе. Недостаток в том, что этот список нельзя и не следует изменять с помощью вызовов add, remove, clear, и при попытке это сделать будет выброшено исключение. К счастью, я не думаю, что какие-либо моды изменяют этот список напрямую в StructureTemplate, но если это так, пожалуйста, дайте мне знать.
У ModernFix есть mixin, который делает сами объекты StructureTemplate SoftReference и полностью удаляет их из памяти, когда игра переполняется памятью. Это допустимое решение, направленное на остановку утечки памяти из-за загрузки nbt структур в кэш, который никогда не очищается при длительной игре. Недостаток этого в том, что часть должна быть снова загружена непосредственно из файла, если она была удалена из памяти. Этот mixin будет нормально работать вместе с оптимизацией моего мода. Что, вероятно, произойдет, так это то, что мой мод сделает StructureTemplate меньше в памяти, что позволит ModernFix хранить больше StructureTemplates в памяти без их полного удаления. Что, теоретически, должно позволить иметь больше попаданий в кэш в долгосрочной перспективе.
