Autotiling and tile randomizing for voxels.

[Shadowblitz16]

Is your feature request related to a problem? Please describe.
I want to make a game where you build your spaceships out of voxels, but cubic voxels don't look good by default.

Describe the solution you'd like
Something simular to tilemap2d's system for cubic voxels, where you have have textures connect and have edges as well as have random variations per block.

Describe alternatives you've considered
Everything.

Additional context
I am trying to create rigid body ships out of voxels simulare to starmade or space engineers, however I want to do something simular to starbound's sloped and non sloped tiles for the visuals.

[Zylann]

That sounds cool however you are barely describing anything here...

Long story short, I have no plan for this yet, but here are my thoughts on that:

I thought of autotiling a few times when playing with the Create mod in Minecraft, which adds connecting glass, columns, and other kinds of blocks like vaults or fluid tanks, which are blocks that change appearance to "connect" to their neighbors up to some degree.
Something to note about how these work is important:

• There are multiple ways things are done, and can go from something generic to very custom. Your title mentions only "tiles", but "have edges as well as have random variations per block" is a whole other level on top.
• "Connectivity" can either happen on textures of blocks, or involve the entire shape of the blocks. Either of which may use different approaches.
• In voxel data, some are not just "1 model". They are many models for every combination of connectivity they can have. Placing the block triggers some custom logic that changes the ID of the voxel and those around it to become variants that connect with the new configuration. And in fact, in some edge cases, connectivity depends on placement order, because of ambiguous cases or deliberate design choices. So "connectivity" is actually baked into voxel data, rather than being a visual thing. This has also a nice side-effect: remeshing the chunk does not require to calculate connectivity again. It is only required when modifying said voxels.
• [I can't confirm this, needs investigation], some blocks might be custom-meshed during chunk meshing if combinations are too much, or if no extra state is necessary. In this case, connectivity variants have to be figured out every single time the chunk is remeshed, even if those voxels have not changed. This comes at a performance cost. This is the case of flowing water (for its 4 top vertices), which is actually a connecting block, even if it doesn't sound like one (but instead of connecting textures it has connecting geometry, which is a similar but different feature).

Right now if you want blocks with connecting textures and whatnot with the way this module works, you have to either implement either of these things yourself in the module (modifying the mesher?), or generate many variants of what you call a "block" (in this module, each variant means a different Model = voxel ID) and permute them yourself when editing terrain. It is indeed daunting, but that's how it's done in Minecraft. It might be possible to automate that with a script.

As for actually adding this to the module:
This can be A LOT considering all the kinds of connectivity you can think of, and there are also other upcoming ideas that could affect what is possible to do (such as quadmesh rendering as opposed to classic meshing). So if it ever gets added, it will likely be bit by bit. A lot of the rest still being up to you to implement.
I only thought about connecting textures and randomization so far. They might be added to cubic models somehow, I'm not sure of how it will be implemented yet. Autotiling can get quite complicated and I'm not sure which of the two approaches I'm gonna use.
More importantly, development is slow, I'm also not working in this area at the moment, and have no project needing it. So I can't tell when I might have a closer look at this. Might be a while.