Trees.

[Argmaster]

Trees.

---

Related-to: #1172

[Argmaster]

There are few very important things to change:

• branch segment sequences should be loaded from zon.
• branch segments should use tree like structure to allow different continuations for junctions
• tree segments should be loaded from zon as list of objects, instead of fixed set of segments.
• add step for Z branch positioning attempts to disallow branches from trying to spawn directly above each other.

[ikabod-kee]

I think there should be two different tree types instead of one.

[ikabod-kee]

[Argmaster]

Zon file modifications are as proof of concept only, they should be removed before merge (assuming we ever merge this atrocity).

[ikabod-kee]

Suggestions from ArchBird:

Suggestions from me:

An editor isn't required if you can do Archbird's suggestion, but it would still be handy

[ikabod-kee]

Reasoning for storing trees as a structure:

[Argmaster]

I agree with storing configuration of individual structures as separate files, this was not necessary when there were just few f32 options, but with this tree model duplication of single tree design is not viable. The questions remain:

• how do we signalize that we want to use an predefined structure - as we definitely don't want to fully replace existing "inlined" structure configurations in biomes. I would consider an additional field called use (or preset) which could contain structure configuration ID generated same way as biome, block or item IDs. When present other options would be ignored and structure configuration would be taken from structure configuration file.
• do we load structure configurations eagerly like other assets (and probably with the same code) or lazily, since they are required only if used?

@IntegratedQuantum what do you think about the whole tree thing?

• How they look?
• How they are configured?
• Do they fit in the game design?
• Do we need separate structure configurations?

There is nothing stopping us from creating piece of code that would generate good branch series automagically on the fly. All you have to do is create tree structure of BranchSegments and pass it into branch generation code instead of using branch segment series from zon. All my previous attempts to create procedural branches failed (as in they too often looked bad), so I abandoned this idea, but sb else may have more luck with that. Such generation even if not good enough to be used unmanaged, can be used to generate branch samples and manually curate them before pasting them into zon.

[ikabod-kee]

how do we signalize that we want to use an predefined structure - as we definitely don't want to fully replace existing "inlined" structure configurations in biomes. I would consider an additional field called use (or preset) which could contain structure configuration ID generated same way as biome, block or item IDs. When present other options would be ignored and structure configuration would be taken from structure configuration file.

	.structures = .{
		.{
			.id = "cubyz:prefab",
			.loadFrom = "cubyz:trees/oak1",
			.variable1 = 2
			.variable2 = 5
		},
	},

Something like this perhaps?

[ikabod-kee]

Do they fit in the game design?

A standard oak tree should take no more than a minute to chop, in my opinion.

[Argmaster]

Do they fit in the game design?

A standard oak tree should take no more than a minute to chop, in my opinion.

Size of the trees is not part of the PR. This PR contains tree generator and if discusing tree designs we should focus on whether the range of trees that can be generated with it is wide enough.

How you use it in practice is separate matter.

[IntegratedQuantum]

After looking at the code, I think that this model is too complicated to configure, yet too restrictive.
The trees, apart from some minor variations look almost identical because they use a small set of predefined branches.
This is because they use a predefined sequence of branches without any sort of randomness applied to the individual branches.

A better solution would be to export the branches from the game (oh hey there is already a PR for this ;D #1141).
Then we could use a sort of structure block system to allow recursively constructing the structure.
A structure block could have the following properties (configurable in a right-click GUI):

• A list of structures that should be chosen from, with an optional chance for each of them
  The list could also allow for selecting procedural structures, so I guess maybe you could also add it at the end of the branch to generate a randomized ball of leaves if we add a simple structure for this
• Some information on how they should be rotated relative to the origin point

This could allow @ikabod-kee to build the structures in the game and easily export them.
At the same time it would be more flexible, since it can be applied to practically anything and not just trees with a single vertical stem.

[ikabod-kee]

(And it could allow for some custom structures? :D)

[Argmaster]

What would be the indented format of export of structure building block? Blueprint?

[IntegratedQuantum]

I don't see a reason to add a second format besides blueprints for that.

[Argmaster]

Do you want to store whole trees as structure building blocks? Or benches?

[IntegratedQuantum]

The whole tree, only doing branches would be too limiting in my opinion.

[archbirdplus]

So I take it that your idea is this?

• design presets for branches, stems, and leaves
• make presets easier to export from in-game
• define connection patterns/constraints for each preset
• connect presets at runtime

[Argmaster]

Ok, so how will that help with variability, if you have only as much trees as you hand made? With current state making 6 distinct branches for tree that spawn 6 branches total gives you 36 different trees. On top of that you can randomize how leaves are placed and how branches are spawned to even further increase variability. If you manually build whole tree, even if you make 10 of each type, it will still be obvious they are often repeating.

I agree that we should have an option to automatically capture branch designs, but not whole trees and not as dumb blobs of blocks, so you can't randomize anything, as they consist of arbitrary blocks. Even capturing branches is IMO inferior and harder to maintain as now instead of human readable series of moves you have to deal with coordinate data to identify how the hell you want to offset the branch to attach it to tree body. You would need to figure out rotation code to even reuse branches on different directions than they are built in.

Using blueprints also means that you can no longer modify assets without running Cubyz, as blueprints are binary, they are black boxes for git and in reviews.

This is a great system for dungeons, villages, castles and whatever that has nothing to do with nature, things that can ignore that there is a wall and just overwrite it. On top of that I don't see how having a full trees as presets would help with variability.

This is a tree generator, not a do-every-structure generator.

[IntegratedQuantum]

So I take it that your idea is this?

• design presets for branches, stems, and leaves

Well, basically, but you wouldn't be limited to just 3 levels of recursion. You could make the base stem split multiple times, or add splits after every block in the branch

With current state making 6 distinct branches for tree that spawn 6 branches total gives you 36 different trees.

With my proposal you could define recursive structures all the way through. You could add branches that randomly split in certain locations by placing structure blocks there that reference smaller branches.
This gives you an exponentially growing number of combinations, instead of just quadratically many in your case.

but not whole trees and not as dumb blobs of blocks

That is not what I'm proposing.

instead of human readable series of moves you have to deal with coordinate data to identify how the hell you want to offset the branch to attach it to tree body. You would need to figure out rotation code to even reuse branches on different directions than they are built in.

Well the last one is something you wanted to add anyways. And offsetting coordinates really shouldn't be that hard. It's just addition after all?

Using blueprints also means that you can no longer modify assets without running Cubyz, as blueprints are binary, they are black boxes for git and in reviews.

The workflow for adding structures already involves launching the game to see how it looks, so I don't see a problem there.
Ideally (in the far far future) we'd even have an in-game preview.
And as for reviews, I always look at how it looks in-game before I merge anything anyways.

This is a tree generator, not a do-every-structure generator.

Yes, but the do-every-structure generator would be strictly more powerful and easier to use than what you have implemented here. And I think this is something I'd want to have anyways.

[Argmaster]

Ok. Since this is a paradigm shift I won't be working on that.

[archbirdplus]

Why not cook up the full wave function collapse algorithm while we're at it? That way dungeon generation could create cyclic graphs and not just trees. Also, using structure generation alone we're not guaranteed to have our nice stereotypical tree shapes, which is a restriction we might actually want. I am coming to like Argmaster's PR for allowing special cased random features like mushrooms and pine branches.

[IntegratedQuantum]

Ok. Since this is a paradigm shift I won't be working on that.

Yeah, sorry for making your work obsolete like this, but I really do think that a generic system is the best choice here. And yeah, I won't order you to work on the generic structure system. There are a few other prerequisites for it anyways, so you couldn't even start if you wanted.

Why not cook up the full wave function collapse algorithm

wave function collapse is terribly slow and I don't see how it would really fit in there.
I think for larger dungeons we should probably use a different system anyways.

Also, using structure generation alone we're not guaranteed to have our nice stereotypical tree shapes

You mean minecraft trees? I don't think we need something like that.

allowing special cased random features like mushrooms and pine branches.

The same should be possible with a generic structure system like I proposed. Except you could also add anything you want, and not just the things the programmer thought of, like vines for example.

[archbirdplus]

With stereotypical tree shapes, I mean the "pine is cone" idea. Maybe you have a better design but from the looks of it the structure system would have to manually specify the branch length at each position on the pine, even when it can be special-cased as a linearly increasing thing. I mean that is doable, of course.

[archbirdplus]

Basically, I am worried about specifying global shapes through just local interactions. We'll see how it goes.