Block IDs vs. Shape/Material/Colour field

    Joined
    Jun 27, 2013
    Messages
    896
    Reaction score
    166
    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?
     
    • Like
    Reactions: Achriel
    Joined
    Mar 2, 2014
    Messages
    1,293
    Reaction score
    230
    • Thinking Positive
    • Community Content - Bronze 1
    • Legacy Citizen 3
    +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.
     
    Joined
    Jun 27, 2013
    Messages
    896
    Reaction score
    166
    +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.
     
    Joined
    Mar 2, 2014
    Messages
    1,293
    Reaction score
    230
    • Thinking Positive
    • Community Content - Bronze 1
    • Legacy Citizen 3
    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.
     
    Joined
    Feb 22, 2015
    Messages
    869
    Reaction score
    179
    • Purchased!
    • Legacy Citizen
    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.
     
    Joined
    Jun 27, 2013
    Messages
    896
    Reaction score
    166
    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

    Precentor-Primus, pro-tempore
    Joined
    Jul 13, 2014
    Messages
    2,518
    Reaction score
    787
    • Purchased!
    • Thinking Positive
    • Legacy Citizen 4
    ...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.
     
    Joined
    Jun 27, 2013
    Messages
    896
    Reaction score
    166
    Joined
    Nov 21, 2013
    Messages
    146
    Reaction score
    153
    • Community Content - Bronze 2
    • Wired for Logic
    • Legacy Citizen 4
    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

    StormMaker
    Joined
    Dec 31, 2013
    Messages
    5,110
    Reaction score
    617
    • Wired for Logic
    • Thinking Positive
    • Legacy Citizen 5
    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.
     
    Last edited: