Structure Layout Optimizer

Оптимизирует создание общей структуры Jigsaw, насколько это возможно. По сути, цель этого мода вообще не изменить внешний вид построек. Это работает только для того, чтобы попытаться заставить структуры создаваться быстрее и эффективнее. Вот и все.

Вот более технические подробности проделанной оптимизации. Пожалуйста, сообщайте о любых конфликтах или проблемах, обнаруженных при запуске этого мода, в ваших модпаках!

• Заменяет неоптимизированные вызовы VertexShape на BoxOctree, чтобы части проверяли на пересечения только близлежащие части, а не всю структуру.

— По умолчанию vanilla использует VoxelShape для хранения границ частей, которые она собирает для макета структуры. Когда дело доходит до добавления нового фрагмента, ему необходимо посмотреть, впишется ли он в макет, не пересекаясь с другими фрагментами.

Проблема в том, что VoxelShape не подходит для этой цели, поскольку при проверке пересечения VoxelShape с другим VoxelShape сравниваются ВСЕ вершины. В структурах Jigsaw с большим количеством частей эта проверка пересечения сильно замедляется по мере того, как в макет добавляется больше допустимых частей. Может вызвать резкий скачок задержки при создании большого количества частей для рекурсивных структур Jigsaw.

При оптимизации здесь обычный VoxelShape заменяется фиктивным VoxelShape, который содержит реализацию BoxOctree внутри, чтобы передать BoxOctree туда, где он должен быть. Это BoxOctree при проверке пересечений будет проверять только те части, которые находятся рядом с входящей ограничивающей рамкой. Таким образом предотвращается безудержный рост времени проверки пересечений, поскольку большинство фигур будет игнорироваться, поскольку они находятся слишком далеко, чтобы иметь значение для проверки.

• Проверьте, полностью ли заблокирован блок головоломки, чтобы знать, когда следует пропустить проверку дочерних жестких деталей.

• В ванильной версии каждый блок-головоломка в родительской части будет проверять каждый блок-головоломку в дочерней части, чтобы знать, когда попытаться соединить две части. Проблема в том, что если блок-головоломка родительской части обращен к краю границы структуры ИЛИ обращен к другой отдельной части, то в этом блоке-головоломке нет места для создания жесткой части структуры. Следовательно, мы можем сказать игре, чтобы она пропустила проверку этой жесткой дочерней части и вместо этого проверила следующую. Это избавляет нас от множества дорогостоящих проверок соответствия блоков Jigsaw. Особенно в конструкциях с огромным количеством блоков-головоломк.

• (26.2 и ниже) Заменяет соответствие цели/лица Jigsaw немного более оптимизированной версией.

• Уменьшает количество захватов свойств блока вдвое. Vanilla вызывает getValue дважды для каждого JigsawBlock, чтобы получить верхнее и переднее значения из одного и того же свойства, тогда как можно просто захватить его один раз и получить все необходимые значения. Немного улучшена скорость получения значений соединений, целей и строк имен из NBT Jigsaw Blocks.
  
  Также упростите совместную проверку данных, чтобы не было необходимости преобразовывать ее в Enum с byName (неэффективно), и переупорядочивайте проверки, чтобы уменьшить объем логики, которую необходимо часто выполнять.
  
  Это поможет со структурами-пазлами, которые содержат очень большое количество блоков-пазлов, поскольку каждый блок-пазл проходит через этот соответствующий код для всех блоков-пазлов в других частях структуры.

• Сделано так, что любая гигантская структура NBT, у которой нет FinalizeProcessing StructureProcessor, теперь загружается намного быстрее.

• Когда часть структуры NBT генерируется в фрагменте, ВЕСЬ фрагмент NBT загружается в память, а затем повторяется по всем позициям несколько раз для применения процессорами структуры, а затем позже игнорирует все позиции за пределами генерируемого в данный момент фрагмента. Это не очень эффективно (действительно расточительно) и приводит к увеличению времени загрузки гигантских файлов NBT.
  
  Оптимизация этого мода работает путем ранней проверки границ, чтобы удалить все позиции, которые нам не нужны, прежде чем передавать их в StructureProcessors. Однако любой StructureProcessor, который переопределяет метод FinalizeProcessing, может потребовать, чтобы все позиции NBT функционировали правильно, поэтому эта оптимизация отключена для любых частей с такими типами StructureProcessors, а структур будет очень мало. В ванильной версии только Trail Ruins не получит такой оптимизации из-за использования Capped StructureProcessor, который переопределяет метод FinalizeProcessing.

• (1.21.1+) Заменена логика перетасовки и расстановки приоритетов списка блоков Jigsaw в SinglePoolElement на немного более быструю версию.

• Основное преимущество заключается в немного более быстром получении данных selection_priority из NBT за счет использования нового метода, который захватывает запись один раз, а не дважды. Vanilla делает это дважды, чтобы сначала проверить тип данных, прежде чем возвращать значение. Немного странно и расточительно.
  
  Также попробовал новую систему сортировки по приоритетам, но помогает только тем немногим структурам, которые действительно используют selection_priority, таким как Судебная палата. В целом, это, пожалуй, самая слабая оптимизация, но она очень помогает структурам Jigsaw, имеющим совершенно нелепое количество блоков Jigsaw. Так что стоит сохранить эту оптимизацию.
  
  Может быть нарушение паритета с ванильными семенами в отношении того, в каком порядке обкатываются блоки-головоломки, но я пока не смог найти доказательств этого.

• Пропустить логику выполнения для SinglePoolElements, которые мы уже проверили и не смогли появиться в текущем месте.

• Итак, эта оптимизация происходит из-за того, что ванильный StructureTemplatePool содержит список всех SinglePoolElements с дубликатами элементов на основе их значения веса. То есть, если в пуле шаблонов вы укажете для дома вес 100, этот дом будет добавлен в этот список 100 раз! И при создании макета игра сделает копию этого списка, перетасует его и будет перебирать список, пытаясь создать первый фрагмент, который она найдет подходящим. Это означает, что он повторно запустит логику проверки повторяющихся записей в этом списке, даже если ранее было обнаружено, что он не подходит на месте. Оптимизация, которую я делаю, заключается в пропуске логики для частей, которые мы уже проверяли ранее, и переходе к следующей части в списке. Это дает хороший прирост производительности для структур, которые используют много значений большого веса в своих пулах шаблонов.

• Кроме того, вы можете включить опцию конфигурации deduplicateShuffledTemplatePoolElementList, чтобы получить еще большую производительность от элементов с большим весом в пулах шаблонов. Проблема в том, что эта конфигурация требует изменения макета структуры. Планировка по-прежнему действительна и хороша. Это будет отличаться от того, если бы опция конфигурации была отключена. По сути, это нарушает начальную четность для структурных макетов специально для дополнительного повышения производительности.

• *Для ясности: паритет семени - это каждый раз, когда вы используете семя 777 и в месте с двумя кузнечными домами есть деревня, каждый раз, когда вы используете одно и то же семя, эта деревня останется на этом месте с двумя кузнечными домами. Если эта конфигурация оптимизации включена и используется тот же начальный код, деревня все равно будет находиться на том же месте. Но на этот раз там может быть 1 кузница. И каждый раз, когда вы используете одно и то же семя с этой конфигурацией, деревня будет продолжать генерировать 1 дом кузнеца. Макет стабильный. Но просто уже не то же самое, как если бы конфиг был выключен.
  

• (1.21.4 с версией 1.1.0+): вместо этого замените список объектов StructureTemplate$Palette на палитру объектов StructureBlockInfo для уменьшения использования памяти, если этот кэшированный StructureTemplate не генерируется.

• Эта оптимизация представляет собой модифицированную форму мода Glacier от Contaria для версии 1.16.1. Особая благодарность им за то, что позволили мне использовать их код в качестве основы для этой оптимизации!

• По сути, в vanilla каждый раз, когда загружается файл структуры nbt, он преобразуется в объект StructureTemplate и кэшируется. В этом объекте скрыт список ВСЕХ позиций из этого файла nbt в сочетании с блоками и тегом nbt в каждой позиции. Это самый большой расход памяти для объектов StructureTemplate. Что этот мод будет делать, так это заменять этот список специальным объектом структуры данных палитры под капотом, который притворяется списком. Объем памяти палитры значительно меньше списка! Затем при запросе worldgen он снова создаст список как WeakReference, поэтому worldgen остается быстрым и работает правильно. И когда создание мира будет завершено, этот список будет собирать мусор, чтобы снова освободить память, позволяя каждому StructureTemplate использовать только полный объем памяти, необходимый ему при создании мира, но оставаться в кэше в меньшей форме в течение длительного времени. Обратной стороной является то, что этот список не может и не должен быть изменен с помощью вызовов добавления, удаления и очистки, и если это будет сделано, он будет генерировать и исключать. К счастью, я не думаю, что какой-либо мод изменяет этот список непосредственно в StructureTemplate, но если они это сделают, пожалуйста, дайте мне знать.

• В ModernFix есть примесь, которая превращает сами объекты StructureTemplate в SoftReference и полностью удаляет их из памяти, когда игра переполняет память. Это допустимое решение, направленное на предотвращение утечки памяти при загрузке структуры nbts в кеш, который никогда не очищается в долгосрочном игровом процессе. Обратной стороной этого является то, что фрагмент приходится заново загружать непосредственно из файла, если он был очищен из памяти. Этот миксин будет отлично работать вместе с оптимизацией моего мода. Что, вероятно, произойдет, так это то, что мой мод уменьшит размер StructureTemplate в памяти, что позволит ModernFix хранить больше StructureTemplates в памяти без их полного удаления из памяти. Это должно позволить увеличить количество обращений к кешу в долгосрочной перспективе. В теории.