Blueprint asset loading

[Argmaster]

This pull request implements loading blueprint and SBB configuration assets.

Depends on: #1226

[ikabod-kee]

POG!

[ikabod-kee]

Yeah, there should probably be a parameter for that

[IntegratedQuantum]

Well, for trees we currently use blue noise. We could definitely do the same thing at multiple different scales, and put larger structures into a bigger size class.

[IntegratedQuantum]

(Also, I think that's outside the scope of this PR)

[Argmaster]

Do we plan strongholds, mines etc? This algorithm doesn't really scale well for that purpose unfortunately, as noting prevents it from overwriting already existing blocks unless you basically create all segments of particular layout. If I recall correctly wave function collapse was deemed too expensive, but maybe we could have it from some of those more specialized structures?

Do we have a way to dynamically specify how many chunks structure affects? Is it possible to add such control? (ignoring exponential growth of generation cost)

[Argmaster]

(Also, I think that's outside the scope of this PR)

Indeed.

[IntegratedQuantum]

Do we plan strongholds, mines etc? This algorithm doesn't really scale well for that purpose unfortunately, as noting prevents it from overwriting already existing blocks unless you basically create all segments of particular layout.

Yeah, we definitely need a different approach there. I think it would be best to use code on the large scale (maze generators, or the room generators from roguelikes), and then use structures for individual rooms (or individual walls, depending on how finely you define the individual components).
We can also try wave function collapse in that context, though I do think that explicit generators still have an advantage over wave function collapse, which tends to generate isolated rooms if you are not careful with the input.

Do we have a way to dynamically specify how many chunks structure affects? Is it possible to add such control? (ignoring exponential growth of generation cost)

Not yet, currently it's hardcoded to 32 blocks in the SImpleStructureGen.zig
The intention is that for larger structures you'd create a new, different structure map generator that produces small (chunk-sized) structures and puts them into the structure map.
The cost should be manageable, if the structures are rare enough.

[IntegratedQuantum]

That's all the requirements done, right?
You just need to rebase and it's ready for review right?

[Argmaster]

Umm, it kind of seg faults after rebase😝
I will try to find source of the problem.

---

Ok it was caused by change of generate signature.

[Argmaster]

We should probably also have parameter for randomizing rotation of first structure, that is not included here yet

[IntegratedQuantum]

Ok it was caused by change of generate signature.

Yeah, it's kind of bad that I use ptrCast for these, maybe we can find a safer way to implement function pointer casts: #1223

that is not included here yet

Yeah, this PR is probably big enough anyways.

[IntegratedQuantum]

I'm not too happy with the overall runtime storage here.
Structures are rather expensive to generate, so we should do as much as we can during loading and use a small and simple in-memory storage format:

• Structures should be rotated during loading instead of being rotated and cached during runtime
• Particularly there should be no mutexes and reference counting going on at runtime. These are not cheap (even without contention), and shouldn't be done for every structure (and we have to assume that people will use many small structures)
• There should be no hashmap lookups during generation:
  • Things like blueprints should be stored as pointers instead of storing ids
  • children should be slices (of less than 20 elements) instead of using the block id for indexing all the time. This also allow making them not nullable, saving another 8 byte for each entry there.
• There should be no string ids left after loading is done.
• Finally the things that are stored, should probably just use an arena, since they are only loaded once and never changed as long as the world is loaded. This would also help reduce the cleanup code (and it is awful if you have to wait 20 seconds for the game to close because it needs to free every tiny allocation manually)

[Argmaster]

Ok, I did some thinking and realistically even with hundreds of models with all rotations precalculated we should fit in tens or hundreds of megabytes, which is not a big deal, definitely we should move in that direction.

[Argmaster]

Here, I cut out #1226 and #1227.
I would be also thankful if you could preserve pull request description as merge commit description instead of list of meaningless commit titles.

[IntegratedQuantum]

I would be also thankful if you could preserve pull request description as merge commit description instead of list of meaningless commit titles.

Sorry, I'm just working with the tools github gives me, and there is no option to put the PR description into the commit message. I'd have to manually copy it from the top, which seems rather annoying to do. Either way there is a link to the PR in the commit, so it shouldn't be a big deal.

[IntegratedQuantum]

Just a question adn some minor optimizations and we are good to go here.

[Argmaster]

Should be all clean now.