Why do we still use 3 bytes per block?

[ltmauve]

A hepta-wedge is a hepta, with a wedge removed from it.

Why do we need that?

A half-corner is a corner diagonally sliced through(the full square is diagonally sliced through)

Ah that piece.

A 2 tetra is NOT an anti-hepta-panel, as unlike in the case of the anti-hepta-panel, the tetras are not in opposing sides of the cube.

Okay, what is an anti-hepta panel, as opposed to a tetra-panel or a hepta-panel?

 

[Megacrafter127]

Okay, what is an anti-hepta panel, as opposed to a tetra-panel or a hepta-panel?

an anti-hepta-panel is simply a full cube, with a hepta-panel removed from it. So, well, 2 tetras in opposite corners of the cube.

 

[ltmauve]

So that would be a reverse 2-tetra. Or an octa. Whatever. Or maybe a hepta-slab.

 

[Malacodor]

We also need wuppda slices and half tibbles.

 

[Lecic]

Since I'm not really well versed in code, I'm not going to comment on that part, besides saying that it'd certainly be nice.

But as for these dozens and dozens of different block shapes people are suggesting- wouldn't it get a bit cluttered?

 

[Viridis00]

wouldn't it get a bit cluttered?

It's already cluttered as is. I for one like as many options as possible, as long as we have good item management which can always be improved. Item type stacks already made things a magnitude more manageable.

 

[Monchoman45]

More block IDs gives you the ability to add more block types, not necessarily a requirement to do so. If schema thinks he can fit all the vanilla blocks in a 4096 ID space, he can take all those IDs for himself and open up the higher 61k to mods, which can have plasma particle photon torpedo phaser cannons and animated purple dinosaur statues for all anyone cares.

I should also point out that with so many ids, you don't have to squish everything into the orientation space - you can leave the lower bits for orientation and save the high bits for some other thing you might want to do later.

All I really want is for "we're running out of IDs" to not be a thing anymore. It seems like a silly problem to me; our technology is at a point where we shouldn't be worrying about that.

 

[Mariux]

Sounds interesting. Not really a pro at coding (only do a bit of C++) but this sounds like a really nice idea. I mean, the game had recently received some serious optimization, for me, at least, so it might be a good idea to spend some of that extra performance for a couple of nice blocks. Can't wait for an official response.

 

[Ithirahad]

We also need wuppda slices and half tibbles.

Half tribbles? Jeez... whatever you you have against tribbles, and why do they need to be cut in half?

 

[ltmauve]

Yeah, there were 16 or 17 shape suggestions, though we only have room for about 12. Even so, 12 different shapes. Adv. build mode for selecting is a must.
WASDQE rotate in adv build mode, scroll wheel and the 1 to = keys select shape.

 

[lordserapis]

Half tribbles? Jeez... whatever you you have against tribbles, and why do they need to be cut in half?

Well, you have to stop them from multiplying somehow. Division works, but I find that either a flamethrower or gatling shotgun works just as well, and it nullifies any potential mathematical puns.

 

[jayman38]

I'm not sure if the OP could ever be done, because I imagine the current bit system is addressed at innumerable locations throughout code, but if it were, I think this would be an interesting way to lay out the different bits:
1 activation bit (absolutely anything can be involved in logic)
5 orientation bits as we have now (you only seriously need 24 different orientations in a block-based voxel environment. I suppose you could require 32 more if you had 4 orientations for each of the 8 diagonal corners, but at that point, rotation starts to get ridiculous, as players start demanding 30 degree turns, then 15, then single degree, and on and on....)
8 block HP bits (no change; still an upper HP limit of 255)
5 shape bits (this is an interesting idea I had, which can lead to block-shaping from a single block ID. Saves some numbers of block IDs, so that ALL blocks can have the different shapes - up to 31 different shapes! Still, it might be better to mix this in with the Block ID count, since each additional bit doubles the number of available block IDs.)
13 block ID bits (over 8000 block IDs, and you don't need to use more than one for different shapes now!)

 

[ltmauve]

The problem is that not all shapes need 24 orientations. So you wind up wasting space. Having your shapes mixed in with the orientations means you get more bang for your buck.

 

[jayman38]

The problem is that not all shapes need 24 orientations. So you wind up wasting space. Having your shapes mixed in with the orientations means you get more bang for your buck.

Thank you! Yeah, so it would be better to set the bits in this order: (Edit: reduced the orientation bits from 5 to 4 to give another bit to Block IDs, which, with the additional bit, can make up for the missing orientations with raw blocks)
1 activation bit
7 HP bits (most blocks won't need more than 100 HP)
4 orientation bits that could be split off/mixed with either the HP bit count or as a sub-type for the Block ID bits, depending on the Block ID.
20 Block ID bits (over 500,000 Block IDs to cover all shapes!).

For the minority of blocks with greater than 127 health, the increased Block ID count will allow us to send one orientation bit to the HP bit count, while four six Block IDs will simulate the missing orientation bits by giving us four six different block rotations for each of the six faces four rotations. 6 block Ids x 3 armor types (HP > 100) x 8 colors = nearly 150 Block IDs (not a whole lot out of the total available Block ID space).

Similarly, if a block has less than 127 HP and doesn't need 15 different orientations, you could have 2 or 4 subtypes associated with that one Block ID. (E.g. Four different floating crystal meshes or eight different glass blocks that each look almost the same no matter which way they are rotated.)

Edit: Heck, at this rate, just move one of the rotation bits back into the current-HP count and mix the 3 remaining rotation bits in with the block ID bits for a total of 2^22 Block IDs and have an average of 24 Block IDs for every block type to give all orientations. Depending on how many blocks can get away with less than 24 orientations, the average Block ID count per current block would be more like 20.

Edit 2: Even if the bit count stays at 24, it might be equally efficient to move the orientation bits into the Block ID space giving 15 bits, equally 2^14 Block IDs, which is over 16,000 Block IDs, and then be very selective on which blocks get multiple orientations. If we take the current block count of 600 and some, and multiply by an average orientation count of 20 or 21, that uses up only about 12,000-15,000 of the available 16k Block ID space. Even if there are exactly 16,000 Block IDs in use, that still leaves over 380 Block IDs for custom blocks.

 

[PizzaPress]

I saw this elsewhere and couldn't find it in the search, so credit goes to ???(I think I know who it was, triangle/illuminato portrait guy?):using orientation bits for logic? Don't know if it's possible, just throwing it out.
Said it could allow to compress logic systems quite a bit.
Edit: That's right, it was NeonSturm

 

[ltmauve]

Pizza, that would be Neonstrum, an experimental AI that visits the forums often.


I suppose how we allocate bits to orientation/ID should depend on how well they can be optimized. Letting use build/remove blocks that actually have multiple IDs would be trivial. The problem would be that not all blocks need the same orientations. Hull blocks only need 1 cube orientation. (Not that hard, but still) System blocks only need 1 orientation, period. That means that you have a bunch of bits doing nothing. What do you do with them? How will system blocks be distinguished from other blocks? By an ID grouping? Lookup table?

 

[WaffulMann]

This is awesome. I like this.
Will we be able to get more colors though, because I can't build gradients or any sort of meaningful digital camo without my ship looking like a rainbow

 

[QuantumAnomaly]

Either way, we need either more space for furniture and decorative bits, or microblocks so we can make them ourselves and blueprint em. I would make the BEST toilets!!! XD

 

[BDLS]

Would be cool for a Schine response to threads like these.

 

[NeonSturm]

I remember somebody said that 3 bytes are the upper limit of block bytes that can be used in a shader. (like RGB + Alpha-Channel doing some other engine-stuff)


If you have 8 shape bits = 2x2x2 sub blocks, you don't need rotation anymore.

Perhaps wasting 8 bit for HP per block is a waste.
Not all blocks use 8 HP bits either. Almost all blocks have below 128 hp which is 7 bit, and most even have below 64 which is just 6 bit.


Also you don't even need 10 ID bits. 8 per block are more than enough if you define 3 different available block IDs (+empty) for a 2x2x2 macro block.

• You have 2 bits per block to select ID 0..1..2..3 with 0 being Air/Space
  
• +3* 20 ID bits for the whole 2x2x2 blocks.
• == about 76 instead of 80 bits in total + 1000 times as many total IDs at the cost of only 3 different per 2x2x2 block group

Alternatively

• 4 bits for 4x4x4 group for 15 different IDs + ID0 /empty, saving 6 bits per block.
• 6 bits per block = 384 bits = 48 byte for 15 IDs =or= 25 bit per ID + some extra bits for other data

If you take that a step further and use HP for one 2x2x2block, you can optimize even more:

• As each 2x2x2 block can only ever have 4 different IDs, you only need to store 4 HP values with 3 bit more each.
• Instead of 8*8=64 bit, you store 4*(8+3)=44 bit in total.

As full blocks neither need 2 orientation bits, nor shape and pure logic also can spare up to 2 HP bits, it has 4 bits + 1 activation bit (=5) for logic.

As it would make sense if logic stops working if damaged, you effectively only need 1 HP bit (damaged or not).​

All that above only depends on how you manage memory.

And I would certainly try to implement this as it offers way more features (including wedges from top-left and bottom-right view point) and more bits for other stuff.