search

Inspirateur / binary-greedy-meshing

A port of https://github.com/cgerikj/binary-greedy-meshing to Rust.
https://crates.io/crates/binary-greedy-meshing
MIT License
4 stars 0 forks source link

Make it take YXZ as input 🙃 #1

Closed Inspirateur closed 2 months ago

Inspirateur commented 2 months ago

So, I thought the binary greedy meshing C lib took YXZ as input with an indexing that looks like this:
y + x * chunk_size + z * chunk_size^2 this is nice because the vertical columns (Y is up) are contiguous in memory so you can fill them efficiently from a heightmap (that you would generate with 2D noise).

Note: none of this matter if you generate the terrain using exclusively 3D noise! But since it's quite common to also use 2D noise, YXZ is a good layout.

But it turns out that's not what the C library uses !

Looking at the terrain generation code they use z + x * chunk_size + y * chunk_size^2 which I would call ZXY, but it doesn't matter how you call it because in this disposition the vertical columns are not contiguous in memory so you lose the nice property described above.

So the code needs to be adapted to take what I call "YXZ" as input shape, because honestly I don't see any reason to choose anything else.

Relevant issue discussing the matter: https://github.com/cgerikj/binary-greedy-meshing/issues/21

Inspirateur commented 2 months ago

Actually... I realized that if you traverse an axis efficiently using range + step by (1/chunk_size/chunk_size^2) the shape doesn't make a difference ! I just benched it with criterion to make sure and it's true.

This is actually good news because it means I'm free to use whatever shape I want and iteration speed on any axis will be the same :)