Block IDs vs. Shape/Material/Colour field

[Valck]

Could somebody please explain in layman's terms why (or even if) it is preferable to have a block ID for every new block variation, as opposed to having one field determining shape (cube, wedge, slab1234, ...), one field for the material (hull, armour, glass, light, rock etc.), and a third field for colour or tint?

Currently there are cube, wedge, tetra, hepta, corner and three slabs for 8 shapes, about as many materials if you count terrain blocks as well, and on the order of ten colours. Shouldn't that be possible to fit in about 5+5+5=16 bits (for good measure and with room to spare)? Another few bits are needed for rotation and meta information, but they are required with the current system anyway.

Somehow I feel it would be a more flexible, extensible, and future proof approach to decouple shape, material and colour from each other.

I understand that the current engine is doing things the way it is, and it would probably require a rewrite of major parts of it. But what if you would start from scratch, or determine the amount of work were acceptable?

 

[Malacodor]

+5 bits for orientation and 8 bits for damage. That's already more than the 3 bytes currently available per block. And 5 bits for material isn't enough, think about all the weapons, effects, decorative blocks, logic, plants, etc.

 

[Valck]

+5 bits for orientation and 8 bits for damage. That's already more than the 3 bytes currently available per block. And 5 bits for material isn't enough, think about all the weapons, effects, decorative blocks, logic, plants, etc.

Granted, but rotation and damage/metadata are required with either system.

Would it change anything if an additional byte were available, as has been hinted at?
I'm just curious why every boxel game seems to do it this way, it seems counterintuitive to me to have to add on the order of ten(s of) block IDs just to add another colour/material.

 

[Malacodor]

I guess it would be more economic to use a possible additional byte entirely for more IDs since most blocks wouldn't use the color field anyway. With 8 more bits we'd get 1 million IDs.

 

[kiraen]

How many blocks on your ship? Now multiply that number by 3 bytes.
No add in your station. Your friend's ship. The pirate attacking you. The planets.
That is the current network/processing/memory traffic of the game.

Now go back to the start and change it to 4 bytes. So yeah, an additional byte will change things.

 

[Valck]

I guess it would be more economic to use a possible additional byte entirely for more IDs since most blocks wouldn't use the color field anyway. With 8 more bits we'd get 1 million IDs.

Alright, that seems to makes sense at least from a storage/bandwidth point of view.

Thanks for taking the time!

How many blocks on your ship? Now multiply that number by 3 bytes.
No add in your station. Your friend's ship. The pirate attacking you. The planets.
That is the current network/processing/memory traffic of the game.

Now go back to the start and change it to 4 bytes. So yeah, an additional byte will change things.

Of course it would make a network/processing/memory bandwidth difference. The question was, would it make a difference to the feasibility of using shape/type/colour fields as opposed to block IDs.

 

[jayman38]

...I'm just curious why every boxel game seems to do it this way, it seems counterintuitive to me to have to add on the order of ten(s of) block IDs just to add another colour/material.

Primarily, I would say it comes down to texturing/artwork. If a block's texture were to be procedurally generated (I kinda like that notion!), then having separate fields might work out. However, having more, fewer-bit fields is less efficient in a binary number system.

Example:
With the current state of the game, shape, material, etc. would each require approximately 9 unique numbers plus the zero for "none". 7 numbers requires 4 bits, so more than that up to 15 requires 5 bits. How many colors would you like to have? Let's say we want up to 15 color options. That is 5 bits. We are already up to 15 bits, not counting orientation or health. (Theoretically, in this scheme, we could set the 15th "shape" as system blocks, and use code to figure out which colors of that 15th shape would be thrusters, shield generators, reactor blocks, etc.)

On the other hand, we have just 12 bits for the block ID range, we get the current Block ID count of 2047 plus zero.

Now here's the rub. If you want to have more than 15 color options, you have to throw another bit to give it 6 bits, for a total of 31 color options. If you were to throw that bit at the block ID range, you'd double the current block ID range. Increasing the Block ID range becomes increasingly more efficient as you move to higher bit counts.

In another thread, I was talking about not requiring all the different available colors for a specific block type (namely, the hazard block), so having the full color number would be a waste on this type of block. On the other hand, if you were using Block IDs instead, you could put in only the hazard blocks you need, leaving space for other types of blocks.

 

[Valck]

more, fewer-bit fields is less efficient in a binary number system

and

that bit [...] double

Yup, that's what I was missing, obvious as it may be, and stupid as it may sound :]

EDIT:
Just noticed that other thread, in case anyone wants to read on: Read by Council - Block ID workaround (for more colours)
In my defense, I started my post before that thread, but got called away... sometimes there are just amazing coincidences.

 

[Achriel]

Maybe it's an idea who's time has just come.. I go the idea from the rejection of Tan/Biege/Brown in Suggestions

 

[NeonSturm]

Granted, but rotation and damage/metadata are required with either system.

Would it change anything if an additional byte were available, as has been hinted at?
I'm just curious why every boxel game seems to do it this way, it seems counterintuitive to me to have to add on the order of ten(s of) block IDs just to add another colour/material.

Damage is not just meta-data. You may store damage per block in meta-data, but then you have to additionally use 3 bits for 000 to 111 (4+2+1=0…7) for cracked-blocks visuals or mix meta-data with block-data before doing damage-calculations.

So as long as you have 1111'1111 = (128+64+…+2+1=0…255) 256 distinctive values for damage and 8 or 16 different block damage visuals both, it's more economic to store it in one value in the block-data.

.

Maybe you want to look at how ZIP-compression works, making fields available depending on used ID-range.

Example: Armour has many colours and no logic. Logic-Blocks have much logic but no colour.

Disclaimer: But then you would tap into a topic that few can discuss. You would be alone with your knowledge like most dedicated programmers are in a just-gaming forum. It would be difficult to pass that knowledge to peoples without looking like my famous NeonSturm-again posts.