Block Positioning And Rotation

[Xaldafax]

@lucadeltodecso was nice enough to explain the issue around block placement and some options on solving it. (His description is listed below the poll for context Edit: Added updated post from devs).

A survey would give some data to the developers to help them decide what people would like for viewing a block. Please answer the following survey for some data. This way it allows @James and the developers to see if a more simple solution is available for rotation so that we can maybe get a tool that allows us an easier time to place blocks and know what the rotation will be like.

This is not about “priority” of development. Just on what the functionality is for future reference.

When placing a block and trying to rotate it how many sides are important to line up and match with other blocks around them.

• One side of the block texture is what I am focusing the rotation on and the other side textures DO NOT matter as much
• One side of the block texture is what I am focusing the rotation on but the other side textures DO matter as well
• Two sides of the block texture is what I am focusing the rotation on and the other side textures DO NOT matter as much
• Two sides of the block texture is what I am focusing the rotation on but the other side textures DO matter as well
• Three sides of the block texture is what I am focusing the rotation on and the other side textures DO NOT matter as much
• Three sides of the block texture is what I am focusing the rotation on but the other side textures DO matter as well
• Four sides of the block texture is what I am focusing the rotation on and the other side textures DO NOT matter as much
• Four sides of the block texture is what I am focusing the rotation on but the other side textures DO matter as well
• All sides of the block texture is what I am focusing the rotation on.

@lucadeltodecso

Personally, I dont think any “really” needs 24 rotations of blocks. What I would like to champion, is instead that a large sub-group of the block types have their textures “randomnly” orientated (currently top/bottom are the same, and each of the 4 sides is the same orientation), we could set the orientations such that you can have the “pattern” of the block be at any rotation you want on any particular single facing direction (you just cannot control what orientation the other 5 faces end up as), and requires 4 rotations of the block to achieve that.

Aka we dont need a humongous migration of data, or to suddenly lose a MASSIVE scope of block-ids, and we dont have to actually change any system. AND this can even have a rotation tool which rotates the face of the block you click on so for whichever face you choose, you can set its rotation to whatever you like (but again, you cannot control what happens to the other 5 faces at the same time).

Technically, this wouldn’t actually be “rotations” but a re-arranging of the faces so that it works out as being able to rotate a single particular face (without caring what happens to other 5 faces).

Downside being that there is no way to “migrate” worlds to this new format in a way that would be pleasing to the eye in all cases, large amounts of the world would “visually” suddenly get rotated, and existing manually rotated patterns would get jumbled up in most cases, so people would have to use the rotation tool to patch up anyway that changed badly from their viewpoint.

As to why we are not doing work to allow all possible rotations on blocks right now:

The game supports 4 rotations of blocks. Being able to have any rotation (a pre-requisite of even having a tool that can manipulate the rotation in any way that any user has every suggested) would mean having 24 rotations (off the top of my head) or 48 if you include mirrorings rather than pure rotations.

We already have “no” space whatsoever left in the block metadata, and the 4 rotations of blocks are actually implemented by using 4 entirely seperate block-type ids instead. square/bevel chisseled block-variations are also another block-id too, so in fact most of our blocks currently use 12 block-ids each (4 rotations of 3 sub-shape types)

We have 15bit blocktypes (so max id is 32767), and currently use 10748 of them.

Not “every” block is rotated eg grass blocks which occupy over 9000 block-type ids already (each combination of dirt/dirt-color/grass is an independent blockid and even different height of grass is in the blockids, as the block-meta is already saturated by slope-type data, and the block-color already occupied by the grass color, so defining which dirt and which color of dirt is under the grass has to be put into the block-type id), so in terms of rotateable blocks we currently have roughly 1748 block-ids in use (so about 145 block types) .

Going up to 24 rotations, would mean those 145 block types suddenly require 10488 block-ids instead of 1748, which would take our current maximum allocated block id up to 19488.

Now 19488 “is” still in range, but we have suddenly lost " A LOT " of space for new blocks to occupy, and would only be able to have another 184 blocks roughly assuming each is rotated/chisellable. … but if you wanted mirroring of the blocks, and not just rotations, we woudl need 48 * 3 blockids for every block… and now we dont even have space for them all any more without even adding new blocks!!

Now, actually making this all work requires a humongous migration of the every chunk/item/inventory in the game as every single blockId suddenly gets massively re-distributed, and we’ve even had to do this twice already during the introduction of the bevel/square chisels, so not impossible, but a large amount of work, and quite frankly, we have more important work to do right now! (And as I say, I would much rather have the more limited system I suggest at the top which apart from being minimal in implentation time, doesnt waste such a huge amount of block-ids).

@lucadeltodecso

Basicly this is my suggestion: (Note, not even as random as I had said, its almost exactly the same as we have now, but some of the faces on some of the configurations are rotated a bit)

So with only 4 configurations (which basicly match the 4 configurations we have “right now”, largely speaking we still have 2 vertical ones and 2 “sideways” ones), any of the 6 faces can have any rotation of the texture pattern. And you could use a tool to hit one of the 6 directions to rotate “that” direction 90 degrees, and even the current placement system when putting the blocks down would only require a very minor change to fit with the new orientations.

Here I had an entirely non-mirror P pattern texture, but for some of the cases atleast in the game, the texture has atleast one mirroring axis already, so 4 rotations actually does give you the 2 flips as well because of the texture already being mirrored (Eg imagine the P in this diagram is a T shape instead, or is a texture with just a diagonal line in one corner)

[lucadeltodecso]

Well… even if you could fully rotate the block all 24 ways… that still wouldn’t let you control every face independently, you’d still be locked to the same configuration, it’d just be rotated. Being able to control 6 faces independently would be 4^6 = 4096 combinations… now that is just ‘waaaaaay’ too much data. Orders of magnitude too much data.

Even 6 faces isn’t enough people may say, since chisseling adds more faces than that again…

[Stormsoul]

My frame of reference here for an ‘ideal’ block rotation system is from (am I allowed to name it?) …Creativerse.

[Xaldafax]

Updated with more notes.

[Tarahyumaro]

My answer would be -Two opposite sides to be mirrored and the connecting one to be 90° rotated

easy peasy case: a pattern of blocks wich is at the same time a floor and a roof: so the pattern (and design on the faces of the blocks) should be reflected on the 2 opposite faces… otherwise i will need to do 2 layers; in this case 4 faces of the block are ignored - this is valid also for a wall wich is at least 3 blocks high

a wall wich is 1 or 2 blocks high: visible faces 3 (we do not take in cosideration starting and ending blocks)

design patterns: to have a pattern you need at least a repeated series (or module) of 2 (a straight corridor large 2 blocks) >>>>>>>> or a 2x2 pattern like <><><><>; this is the easiest especially if you are using a block with symmetrical design for 1 or 2 axis;

with all the blocks with wich you have no symmetry axis, you will need at least 2 of them to do something, and in particular you need 1 and it’s mirrored version to do it - the point is that with at least 1 symmetry axis you don’t speak about mirroring, without axis of simmetry the joint between the 2 blocks will become your axis of simmetry

a tool wich rotates the faces will not give you the mirrored version of your “P” design but only the contrary, or opposite if you prefer
but if you have an “L” design where both lines of the “L” are equals you would have it (because this “L” do have 1 axis of symmetry, bisector 45°)
or the example of passing from a “P” design to a “T” design (from zero to 1 central axis of symmetry)

in the end if you want to use ANY random design on the block face, you need a rotation and a mirroring option

as i understood we havo no space for this…

what i would suggest is to eliminate completely designs with no symmetry axis, cause as it is they are not going to be used because of the “can’t close the pattern”, wich is why i decide to make a decorated block of a kind or the other, it must make sense, or else a colored block with no design is better

and would insert at theyr places blocks with angular design of already existing blocks with straight patterns (so we can close a “frame” design around a pattern on a horizontal plane)

[Jyanin]

Not “every” block is rotated eg grass blocks which occupy over 9000 block-type ids already (each combination of dirt/dirt-color/grass is an independent blockid and even different height of grass is in the blockids, as the block-meta is already saturated by slope-type data, and the block-color already occupied by the grass color, so defining which dirt and which color of dirt is under the grass has to be put into the block-type id), so in terms of rotateable blocks we currently have roughly 1748 block-ids in use (so about 145 block types) .

I realise this quote isn’t Xaldafax’s, it is @lucadeltodecso, just the quote thing was a sub quote

I’m just wondering…what is going to happen to dirt/grass combinations when more planets exist and therefore more colours? Are planet’s colours going to be limited by what colours already exist? o.O

[willcrutchley]

Well, the colour of system is already being overhauled, so I wonder if they have found a more efficient way of doing this @lucadeltodecso

[Gorillastomp]

I don’t know if this could be possible. but think a texture rotation of the block would be better. so that way you could set the rotation you want for every faces.