Oak and Birch Tree Generators

[ikabod-kee]

Now, I know what it looks like with all those changes, but in reality you don't have to check half of those, as they're just blueprints.
I also included "deco" and "null," which are for small decorations and nothing respectively.

[Argmaster]

I don't like this exact structure you shown here, I seriously doubt that none of the birch models can be reused as oak models - block substitution is a planned feature - so I would suggest to prepare blueprints for that - blueprints don't exactly care if they are made of birch or oak wood, but they care if they are a stem or something else + they care about child block layout. Neither of those information is encoded clearly in ID of that asset. Take a look onto my PR blueprint layout in #1377 . I first group asset by tree type, then by what part of tree they belong too, then I have variants with just number or with encoded child block layout (applies to stems) I don't expect you to copy that 1:1, but I suggest you consider eg. separating that birch_1 into birch/1. I will give a better review and possiby more concrete suggestions tomorrow.

[Argmaster]

As for child block placement, It is really annoying that there is no simple way to view those blueprints or spawn SBBs on demand with fixed seed. Both of those features should get high priority alongside QOL features like masked set command.

[ikabod-kee]

Very well

[ikabod-kee]

I think us having different file structures for this is not really an issue (if anything, it tells you who made what structure XD)

[Argmaster]

Oh, so you don't feel like I'm only criticizing - these are really cool trees, good job! C:

[ikabod-kee]

Bless

[IntegratedQuantum]

And I also have to say: They look amazing in-game!

[Argmaster]

Birches like these:

Really remind me of Acacia more than Birch trees, but I guess it might be just the style choice, noone said Birches have to look like birches all the time.

Although I would suggest adding few hanging leaves, so they don't have that obviously flat bottoms, I have same problem in #1377, In my case I will probably try chaning some of the leafed branches into normal ones so they stand out more, but here I would suggest this:

Don't get me wrong - I don't want the leaf balls back, I just want few hanging leaves, a bit like here:

[Argmaster]

Hmm that is bad :C
What did we do wrong -_-

[Argmaster]

In plains like these:

I would rather see a 2 block thick oaks, taller ones than those in forests and also placed more sparsely. Our placement method does not preserve any minimal distance between spawns which is a bit of a shame, but we have to cope for now. But I guess thats just my opinion.

[IntegratedQuantum]

Hmm that is bad :C
What did we do wrong -_-

Yeah, the degradable concept is not really working for everything. Ideally it would probably give each block a priority instead of being just a bool.

[ikabod-kee]

I would rather see a 2 block thick oaks, taller ones than those in forests and also placed more sparsely.

I can work on that at some point.

Also oof, I didn't notice the hanging bottoms on the leaf blobs. I will be fixing that.

[ikabod-kee]

*flat bottoms

[Argmaster]

Alr so first lets tackle SBBs because in their case it is a bit simpler. Firstly, I would suggest moving all the trees into tree as trees are not only thing that can be generated with SBBs, actually, there is quite a lot of stuff (eg. large mushrooms, meteorites, ruins) so having all of that in root of assets/cubyz/sbb does't sound like fun for me.

For example: assets/cubyz/sbb/birch/... -> assets/cubyz/sbb/tree/birch/...

Now for coniferous trees I decided to build everyting with pine, but have one coniferous directory under tree as at least some of the variants can be reused in different forests than pine which should be possible with substitutions in few weeks. Equivalent in your case would be something like:

assets/cubyz/sbb/birch/... -> assets/cubyz/sbb/tree/deciduous/...

But I understand that grown up oaks can have intentionally different, unique design than birches. However, I am pretty sure that for example young trees could reuse same models or parts of same models. In such case I think it is reasonable to have unique birch and oak designs separately, but everything that is not unique and can be reused should end up in assets/cubyz/sbb/tree/deciduous/...

Now lets go lower, to tree parts and trees themselves. Every part that is reusable, again, yeet to assets/cubyz/sbb/tree/deciduous/... but now there is a trick, please group stuff under directory explaining what part of the tree it is, there is no need to duplicate that information in every name of file, I would advise against it (quite strongly!) It will make it harder to rename those assets if we find better name for that group.

So, for example:

assets/cubyz/sbb/birch/1/root_1.zig.zon -> assets/cubyz/sbb/tree/birch/root/0.zig.zon

Mind few things:

• that root design is not exclusive to birch variant 1, even if it looks best paired with it, it may be reused at some point with different tree design,
• please start counting from 0, we do that everywhere in code, lets keep it consistent,
• don't call things blob - my guess this is of leaves, please name it leaves.

When you are declaring full tree design, I would suggest grouping them in full and then under size category, eg. tall followed by variant number eg. 0 (still a directory) and inside it you can place all the segments that make single tree.

For example:

assets/cubyz/sbb/birch/1/tree_1.zig.zon -> assets/cubyz/sbb/tree/birch/full/tall/0/0.zig.zon

Now why?

Because we should have variable trunk height and simplest way to achieve that is have variable height trunk segments, so you specify tree as few segments: trunk+roots, trunk+small_branches, trunk+large_branches where middle segment can have variable length. Now you can choose different nomenclature and have crown designs separately, but still simplest way to bump tree height is to insert intermedia trunk segment, eg.

• assets/cubyz/sbb/tree/birch/full/tall/0/0.zig.zon
• assets/cubyz/sbb/tree/birch/full/tall/0/1.zig.zon

I know that my coniferous trees make much better use of that, becuause they are build around that idea that you stack identical trunk segments on top of each other, but in your case it will also allow for quickly adding 1-3 block variation to tree height without actually modifying assets.

Just leave yourself as much options for doing stuff via zon whenever it is possible.

Now for blueprints, I would apply same rules where possible, if you have common part of name for multiple assets, extract that to be directory name, bacause you will have easier time chaning it later. Group stuff as much as possible, preferably mirroring structure of SBBs.

[ikabod-kee]

Now, I understand where you're coming from with that file structure, and I have to agree that it's very organized and everything... but.

That is way too many file paths.

Keep in mind that I have to type that all in manually every single time. That is a lot my brother. Plus it would be very intimidating for anyone who wants to dabble into custom structures. Plus, don't get me started on all the dependencies if we ever have to change one blueprint.

[ikabod-kee]

I will try my own file structure later, see if we can't meet in the middle somewhere about it.

[Argmaster]

• you are going to type most of the paths anyway, whether you chose to go with blob_1 or blob/1 doesnt even change char count
• autocompletion will work better with directories, implementing directory level completion is easier than implementing partial file name completion
• its our internal choice, it imposes no requirements on 3rd party extensions
• SBB system is tricky to get into for different reasons - for example you have no idea how those blueprints look like - I could find few others, but what matters is that number of directories on the way to asset is waaay less important.
• you should be using IDE to work with assets, and then it doesn't matter how many directories are on the way, since they are displayed as tree. If you are not using IDE, there are plenty of reasons to do so.

[ikabod-kee]

I would kind of like to separate trees by style as well.

[Argmaster]

Thats up to you. But don't duplicate identical componets if only difference is block type used.

[Argmaster]

Or rather, be ready to remove duplicates, because I suppose until we have substitution we should keep different variants...?

For substitutions I need masks, then I can work on generating necessary assets during loading, since I already have set method,

[ikabod-kee]

I don't have duplicates XD

[ikabod-kee]

You can check this file structure out. My reasoning for not putting these in folders is because I save my blueprints as "???_1" when saving them, so it's easier to go in and do small changes.

[ikabod-kee]

I will go in shortly to remove the "tree" prefix from some of these blueprints, as those are leftovers from experimenting

[ikabod-kee]

If you want to change the file structure yourself, you're free to do a PR (I cannot wrap my head around it)

[ikabod-kee]

I think your file structure method is good for general trees, but my trees are more stylized and particular

[ikabod-kee]

Oh no... I forgot which of these are which.

[ikabod-kee]

Flat bottoms are now fixed

[IntegratedQuantum]

Oh no... I forgot which of these are which.

@Argmaster another argument for #1387

[Argmaster]

I guess, but for now I have few other things queued up and limited time.

[IntegratedQuantum]

one thing to change, the rest are just suggestions for future changes to the underlying system.

If @Argmaster doesn't have any other complaints then we can merge this.

[IntegratedQuantum]

@Argmaster should we add some kind of wildcard system?
Then here it would just be a single entry:

.{.structure = "cubyz:tree/oak/1/trunk_*"},

[Argmaster]

Alright, but what are the rules?
The obvious matches:

cubyz:tree/oak/1/trunk_0
cubyz:tree/oak/1/trunk_1
cubyz:tree/oak/1/trunk_453

But, does that match to?

cubyz:tree/oak/1/trunk_/0
cubyz:tree/oak/1/trunk_/1
cubyz:tree/oak/1/trunk_/234

Do we go full glob with ? and **?
What do we do with cubyz:tree/oak/1/trunk_*/foobar_1, do we even allow this?
Where is the wiki explaining what is and what is not allowed C:
Maybe instead of wildcards we would allow specifying directory-like syntax and we would take everything starting with cubyz:tree/oak/1/trunk/

[Argmaster]

The last one creates grouping that is visible both in code and in directory structure with no tricks and minimal amount of edge cases. That trailing slash is mandatory do remove all the ambiguities.

[Argmaster]

Generally speaking I am not happy with the generator structure types, they are clever trick but not indented use, it would be best to solve both those problems at once.

[IntegratedQuantum]

Alright, but what are the rules?

In my opinion it should only match one directory at a time, just like in bash.

Do we go full glob with ? and **?

Let's stick to the simple things, and extend when we need it.

What do we do with cubyz:tree/oak/1/trunk_*/foobar_1, do we even allow this?

Sure, that doesn't seem too difficult.

Maybe instead of wildcards we would allow specifying directory-like syntax and we would take everything starting with cubyz:tree/oak/1/trunk/

That would be another option, I guess. It does however limit your freedom for organizing things.

[Argmaster]

You know what I think about freedom.

[Argmaster]

I really dislike redundancy present in file names, stuff like branch_1, branch_2, branch_3 should be instead a directory branch containing 1, 2, 3. This is what directories are for, to avoid duplicating same information in every file name. And if you are refusing to follow that guideline, at least do this consistently with birch/1 being instead birch_1. So if I have to clean this up with Python script I don't have to make special cases.

@IntegratedQuantum can we create a contribution guideline for whatever path style you and @ikabod-kee choose for those particular assets so to stop every new contributor from inventing their own path style?

[ikabod-kee]

Working on this as we speak.

[ikabod-kee]

There, I did the changes you wanted @Argmaster

[IntegratedQuantum]

There, I did the changes you wanted

Please also then make a PR with the corresponding changes to the contributing guidelines.

[ikabod-kee]

Where is that?

[IntegratedQuantum]

If you can't find it, then tell me where you searched for it, so we can put a link there.

Also https://github.com/PixelGuys/Cubyz/blob/master/CONTRIBUTING.md

[ikabod-kee]

I'm not exactly sure what to make of this.

[Argmaster]

There are few small things, but I consider them negligible for that PR:

• .children = .{}, should be omitted, but #1403 is more general fix for that, so lets not waste more time on that
• contribution guidelines should be updated to inform what is the preferred layout of SBBs and blueprints. Techincally also could be affected by #1403, not sure yet, lets have this as separate PR too

You have my blessing, now its @IntegratedQuantum turn.

[IntegratedQuantum]

Alright, let's do it then! Time for some new lag biomes trees!