Optimizes general Jigsaw structure generation as best I can. Here are the details of the optimizations done. Please report any conflicts or issues that is discovered when running this mod in your modpacks! - **Replaces VertexShape unoptimized calls with a BoxOctree to make pieces only check nearby pieces for intersections instead of entire structure.** - By default, vanilla uses a VoxelShape to store the bounds of pieces it is assembling for the structure layout. When it goes to add a new piece, it needs to see if it will fit into the layout without intersection any other pieces.

The issue is VoxelShape is not good for this purpose as when checking if a VoxelShape intersects another VoxelShape, ALL the vertices are compared. In Jigsaw structures with lots and lots of pieces, this intersection check slows down greatly the more valid pieces are added to the layout. Can cause a lag spike when generating high number of pieces for recursive Jigsaw structures.

The optimization here replaces the normal VoxelShape with a dummy VoxelShape that holds a BoxOctree implementation inside in order to pass around the BoxOctree to where it needs to be. This BoxOctree, when checking for intersections, will check only the nearby pieces to the incoming bounding box. Thus preventing the runaway growth in intersection checking time as it'll ignore the majority of pieces as they are too far away to matter for the check.
- **Replaces Jigsaw target/facing match up with a slightly more optimized version.** - Reduces the number of block properties grabbing by half. Vanilla calls getValue twice for each JigsawBlock to get top and front values from the same property when it could just grab it once and get all values it needs. Slightly improved the speed of getting the joints, targets, and name string values from the Jigsaw Blocks's NBT as well.

Also simplify joint data checking to not need to be converted to an Enum with byName (not performant) and reordering checks to reduce amount of logic that needs to run often.

This will help with Jigsaw structures that have a very high amount of Jigsaw Blocks in them as each Jigsaw Block runs through this matching code for all Jigsaw Blocks in the other structure pieces.
- **Made any giant structure NBT that has no finalizeProcessing StructureProcessor now load much faster.** - When a NBT structure piece goes to generate in a chunk, the ENTIRE NBT piece is loaded into memory, and then iterated over all the positions multiple times for StructureProcessors to apply and then later ignores all the positions outside the currently generating chunk. This is not very efficient (really wasteful) and causes large load times for giant NBT files.

This mod's optimization works by doing the bounds check early to strip out all positions that we don't need before passing it to the StructureProcessors. However, any StructureProcessor that overrides finalizeProcessing method could require all the NBT positions to function correctly so this optimization is disabled for any pieces with these kinds of StructureProcessors which will be very few structures. In vanilla, only Trail Ruins will not get this optimization due to its use of the Capped StructureProcessor that overrides finalizeProcessing method.
- (1.21.1+) **Replaced the Jigsaw Block list shuffling and prioritization logic in SinglePoolElement with a slightly faster version.** - Main benefit is slightly faster `selection_priority` data grabbing from NBT by using a new method that grabs the entry once instead of twice. Vanilla does it twice to check the data type first before returning the value. A bit odd and wasteful.

Also tried a new sorting system for the prioritization, but only helps the few structures that actually makes use of `selection_priority` like Trials Chamber. Overall, this is probably the weakest optimization but it does quite a bit of help for Jigsaw structures that has an absolutely ridiculous amount of Jigsaw Blocks. So it is worth keeping this optimization.

Might break parity with vanilla seeds in regard to what order the Jigsaw Block are ran in, but I could not find evidence of this yet.
- **Skip running logic for SinglePoolElements we already checked and could not spawn at the current spot.** - So this optimization comes from the fact that vanilla StructureTemplatePool holds a list of all the SinglePoolElements with duplicates of the elements based on their weight value. So if in a Template Pool, you specify weight 100 for a house, that house will be put into this list 100 times! And when generating the layout, the game will make a copy of this list, shuffle it, and iterate over the list to try and spawn the first piece it finds that fits. This means it will rerun the checking logic for duplicate entries in this list even if it was found to not fit before at the spot. The optimization I do is skip the logic for pieces we already checked before and continue to the next piece in the list. This gives a nice performance boost for structures that uses a lot of high weight values in their Template Pools. - Furthermore, you can turn on the `deduplicateShuffledTemplatePoolElementList` config option to get even more performance out of high weight elements in Template Pools. The issue is this config comes at a cost of changing the layout of the structure. The layout is still valid and good. It would just be different than if the config option is kept off. Basically it breaks seed parity for structure layouts specifically to get that extra performance boost. - *To be clear, seed parity is every time you use the seed 777 and there is a village at a spot with 2 blacksmith houses, every time you use that same seed, that village will remain at that spot with the two blacksmith houses. With this optimization config turned on and same seed, that village will still be at same spot. But it may have 1 blacksmith house this time. And every time you use the same seed with this config on, the village will continue to generate with the 1 blacksmith house. The layout is seed stable. But just no longer is the same as if the config is turned off.

Structure Layout Optimizer

External resources

Project members

Technical information