Add Structure Building Blocks based Generator #1227
Conversation
|
Would you mind adding your example structures to a biome, to show it works, so that @ikabod-kee could try and play around with it to see if there are any problems? |
src/blueprint.zig
Outdated
| if(sbb.isOriginBlock(block) or sbb.isChildBlock(block)) continue; | ||
|
|
||
| if(substitutions) |map| { | ||
| if(map.get(block.typ)) |entry| { |
There was a problem hiding this comment.
We must not do a hashmap lookup for every block of structures with this features.
A better solution would be to palette-compress the blueprint (which would make sense anyways) and then only swap the palette entries once beforehand (those could even be cached). Either way, I think that would be out of scope for this PR.
I generally would prefer if you could add substitutions as a whole in a future PR so we can focus on making the core system good first.
There was a problem hiding this comment.
Then we could also avoid the hashing problems entirely.
There was a problem hiding this comment.
We already discussed why palette compression and decompression can result in bad time complexity. Since replacements are known at instantiation time we can apply them once and create a modified copy of the blueprint(s) for that purpose (I hope so at least) This would also make it viable to do more complicated replacements like with masks from #1284 and patterns from the /set command. Blueprints could be stored globally if we append hash or sth of replacement map to the ID to avoid duplicating child blueprints. That's an optimization tho, maybe not necessary.
I was thinking about the relation between commands like /set and /undo and I came to conclusion that (since we have to capture and store blueprint of world before editing) it would be better to have all the WE functions as methods on Blueprint. This would make the pattern for each command the same (capture, store, modify, paste) instead of requiring dedicated undo implementation for each command. With the current state you also can't use WE commands programatically since they are tied to the command system. With that change Blueprint would have the replace function which would return a modified copy which we could use here to generate modified blueprints.
That said I agree that substitutions will be better off added separately.
There was a problem hiding this comment.
We already discussed why palette compression and decompression can result in bad time complexity.
I cannot remember that discussion, in fact palette compression is so good that we use it for chunks already.
Since replacements are known at instantiation time we can apply them once and create a modified copy of the blueprint(s)
Well this has quite a big memory footprint, to the point where palette compression might be a requirement anyways.
This would also make it viable to do more complicated replacements like with masks from #1284 and patterns from the /set command.
Masks could be done by modifying only the palette as well, I think.
As for patterns, they don't seem particularly useful when caching the structure, so we should not need to worry about it in this discussion.
I was thinking about the relation between commands like /set and /undo
I think that world edit commands have fundamentally different performance requirements, they are only executed once so they can get away with doing a lot more stuff.
Chunk generation on the other hand makes up 50% of the chunk generation+loading time which is one of the main bottlenecks for render distance currently. So we have to make it as fast as possible.
And I think it's safe to assume that this system will be used for a majority of structures in the game, starting with trees.
There was a problem hiding this comment.
Ok, I am not sure, we discussed something about using palettes for IO possibly in first blueprint PR but there are a lot of comments there so its hard to find.
I might have also misunderstood intended use of palette compression here.
Mind that unlike chunks blueprints don't have compile time known size limitations so this would involve implementation of dynamically sized PaletteCompressedRegion.
There was a problem hiding this comment.
yes indeed, shouldn't be too difficult though.
Co-authored-by: IntegratedQuantum <43880493+IntegratedQuantum@users.noreply.github.com>
|
Applied suggestions to Y and Z, please review. |
|
Also since we are getting close to the merge, please test one last time if it works and then remove the test structures. |
|
Looks like it still works, test structure removed. |
* Revert "Remove SBBGen" This reverts commit b490484. * Revert "Remove example SBB" This reverts commit afc5d6f. * Revert "Remove blueprint code" This reverts commit 2553950. * Fix compilation errors * Fix compilation errors #2 * Fix test errors * Fix rotateZ * Resolve structure reference while instantiating SBBGen * Fix formatting issues * Add new trees to forest * Add new trees to grassland * Decrease forest density so you can find new trees * Add degradable paste mode * Remove substitutions * Apply review suggestions * Use lookup table for alignment * Apply suggestions from code review * Update src/server/terrain/simple_structures/_list.zig Co-authored-by: IntegratedQuantum <43880493+IntegratedQuantum@users.noreply.github.com> * Fix inital SBB offset * Never place air in placeInGeneration * Integrate void block with paste * Revert "Move hashInt and hashCombine to utils" This reverts commit 9bb276f. * Make PasteMode comptime * Fix remaining issues with void block integration * Fix formatting * Apply review change requests * Remove origin and child blocks while resolving sbbs * Apply review change requests * I hate indexing * Fix example tree models * Use single index for chunk and blueprint in pasteInGeneration * Fix formatting * Extract blueprintOffset * Fix formatting * Apply suggestions from code review Co-authored-by: IntegratedQuantum <43880493+IntegratedQuantum@users.noreply.github.com> * Apply Quantums suggestion for Y and Z * No cast * Use pos instead of chunkOffset * Remove test tree * Apply suggestions from code review --------- Co-authored-by: IntegratedQuantum <43880493+IntegratedQuantum@users.noreply.github.com>
2 participants
This pull request adds generator type which uses Structure Building Blocks and blueprints to generate structures.
discord
Depends on: #1141
Depends on: #1197
Depends on: #1207
Depends on: #1240
Depends on: #1226
Depends on: #1241
Depends on: #1253
Depends on: #1333
Related to: #67
Related to: #194
Related to: #1029
Related to: #1172