Rotate blocks (0, 90, 180, 270 degrees) about noa HOT 19 CLOSED

Hi, this is a really good idea. So good in fact, that I'm hammering a bit trying out just getting rid of the packed bit flags, and storing voxel IDs as a plain uint16, and doing lookups everywhere the bit flag was previously used. That would allow 65k voxel IDs, and also simplify several bits of the engine somewhat. The performance hit, at first blush, seems to be about 10% slower terrain meshing, and negligible elsewhere.

10% slower meshing isn't ideal, but meshing is fast enough that it shouldn't really cause FPS drops, just lower overall throughput on world generation. I'm going to hammer a bit more but I may just check this in and hope for the best.

from noa.

Hi, thanks for the input here - I went ahead and merged this into #develop.

Changes:

• voxel IDs are now plain Uint16Array elements, they're not packed into the low bits anymore
• the maximum voxel ID is now 65535

Impacts:

• ~10% slower terrain chunk meshing (on my project/machine, average 0.8ms → 0.9ms or so)
• noa._constants is removed
• Anyone who was bypassing APIs and directly accessing chunk data arrays will need to change stuff

That should be it, no public APIs changed, and no other performance impacts I found. LMK if you have issues, thanks!

from noa.

Hey - this is not in the engine at present. I had thought about it, and there is room in the internals to assign several bits of "variation" per voxel like this, but I haven't thought out all the details.

For example, I'm not sure how the client would specify voxel variations at chunk-creation time. The technically straightforward way would be to have the client pack variations into the high bits of the int values, same as the engine does, but ideally the client wasn't supposed to need to know implementation details like that. But the alternatives wouldn't be very clean either.

I think it could be wrangled, but it would take some thinking and at the moment it's not super-high on my list, sorry! In my content, I'm basically only using block rotations for "custom blocks" (where the voxel has a non-block shape), and for those I apply the rotation in the custom block handlers at block creation.

from noa.

I found a way to make static properties like for example the hardness for a block, but it'll be cool if we had dynamic variation, like the direction of a block. This variation will be very handy if added.

from noa.

I think the way Minecraft does it now from 1.13 onwards is to register each possible variation of each block as a "blockstate". Maybe you could edit constants.js to use the the variation as extra block ID bits and register each like a separate block? That seems to be the way Minecraft does it now.

from noa.

Yes, that's the way something like this would properly be done - by using 2 bits in the voxel ID as state data, and then having the mesher look at that state when building terrain. However it's complicated how this could be implemented API-wise: the game client gives the engine plain voxel IDs, and the engine does meshing shortly afterwards, so there would need to be some new way of letting the client pass in block state flags during the interim. Anyway this is possible but I don't have plans to do it very soon!

from noa.

Minecraft 1.13+ registers each possible rotation/state as a separate ID, so there can be any number of states and no redundant bits, which can already be done in noa. Minecraft 1.12 and below had a fixed 4 bits of data for each block, like noa has now.

from noa.

Ah sorry, I misunderstood you before. That's really useful to know, thanks! I don't suppose you know why they changed the format?

(To be clear, noa doesn't do anything with the extra bits of voxel state, it just sets aside space for them to be used someday. But it sounds like I should forget that and increase the maximum voxel ID instead.)

from noa.

They run out of free block ids if I remember correctly.

from noa.

Yep, doing it that way is more compact so it frees up IDs. It also lets them use more than 16 combinations, which they probably needed to store waterlogging data for Update Aquatic (you need to store water data and block data).

from noa.

https://minecraft.gamepedia.com/Block_states#Daylight_Detector for example has over 16 possible states

from noa.

If you did want to move to a blockstate system, I think you should have a way of defining a JS object with values for variation (like the ones on the wiki page), and noa should register all of the combinations, and also you should be able to set fixed values (like "is solid") that no extra states are created for (that's just my opinion though based on how I've seen that Minecraft does it).

from noa.

But that's quite a big change so it might be better for me to try doing that in a fork or making a wrapper or something (I think it should be optional at least, even if it does end up in noa)

from noa.

@Patbox @Heath123 Thanks for all the info, it's really helpful.

Personally I think it's definitely best to just add those 4 bits to the voxel ID, which would raise the limit on unique voxels to 8191.

That said, I imagine minecraft probably has more IDs than that nowadays? An added option would be to start using Uint32Array for voxel data, effectively allowing unlimited voxel IDs. I haven't tried it, but I'd imagine this would have little effect on CPU performance, but noticeably increase memory usage for medium to large draw distances.

from noa.

@Patbox @Heath123 Thanks for all the info, it's really helpful.

Personally I think it's definitely best to just add those 4 bits to the voxel ID, which would raise the limit on unique voxels to 8191.

That said, I imagine minecraft probably has more IDs than that nowadays? An added option would be to start using Uint32Array for voxel data, effectively allowing unlimited voxel IDs. I haven't tried it, but I'd imagine this would have little effect on CPU performance, but noticeably increase memory usage for medium to large draw distances.

I think Minecraft has 4096 blockstates available at the moment (they're not all used). For what I'm using it for I'd need to eventually store lighting data too, but that only needs to be done for non-solid blocks and there are probably enough spare states for that (or I could use a separate array).

from noa.

There's information about how Minecraft does it here:
https://wiki.vg/Chunk_Format#Global_and_section_palettes
This is a list of block states in 1.15.2:
https://pokechu22.github.io/Burger/1.15.2.html

from noa.

Never mind, there are 11,337 in Minecraft (wow)

from noa.

Would registering that many blocks cause lag?

from noa.

I don't really know too much about JS and optimising it, but can one of the solidity, opacity or object marker bits be sacrificed and looked up based on the ID? That could get the voxel IDs up to 16,384 which is probably enough for most things because it's the same as Minecraft's block states. Is that feasible?

from noa.