Comments (19)
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.
Related Issues (20)
- Is there any way to use this as an es6 module? HOT 10
- Support gamepad input
- Outdated comment + note on blockMesh registration HOT 2
- Alpha blended mesh ordering issue HOT 2
- Terrain remeshing bug when block is neither solid nor opaque HOT 3
- Custom voxel occasionally leaves one side after removal. HOT 4
- UV offsets wrapping at edges of blocks HOT 2
- object meshing bug HOT 6
- Meshing with non-opaque blocks is incredibly slow + block textures with alpha dont work HOT 4
- custom renderMaterial performance (for animated textures) HOT 2
- Supporting noa HOT 2
- Does NOA support child meshes? HOT 3
- webgpu? HOT 2
- How to define new objects in NOA engine. HOT 5
- Optimal octreeBlockSize
- What is the best way to manually build worlds? HOT 2
- render all blocks even if covered HOT 1
- How to import an obj model?
- refresh the registry on the go HOT 2
- Making a set world.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from noa.