Mirrored_Repos/veloren
1
0
Fork 0
mirror of https://gitlab.com/veloren/veloren.git synced 2024-08-30 18:12:32 +00:00
Code Issues Packages Projects Releases Wiki Activity
2,129 Commits 151 Branches 18 Tags 2.1 GiB
Rust 84.1%
Fluent 13.6%
GLSL 2.2%
b26043b0e6
Go to file
haslersn b26043b0e6 common: Rework Chunk and Chonk implementation 
Previously, voxels in sparsely populated chunks were stored in a `HashMap`.
However, during usage oftentimes block accesses are followed by subsequent
nearby voxel accesses. Therefore it's possible to provide cache friendliness,
but not with `HashMap`.

The previous merge request [!469](https://gitlab.com/veloren/veloren/merge_requests/469)
proposed to order voxels by their morton order (see https://en.wikipedia.org/wiki/Z-order_curve ).
This provided excellent cache friendliness. However, benchmarks showed that
the required indexing calculations are quite expensive. Particular results
on my _Intel(R) Core(TM) i7-7500U CPU @ 2.70 GHz_ were:

| Benchmark                                | Before this commit @ d322384bec | Morton Order @ ec8a7caf42 | This commit          |
| ---------------------------------------- | --------------------------------- | --------------------------- | -------------------- |
| `full read` (81920 voxels)               | 17.7ns per voxel                  | 8.9ns per voxel             | **3.6ns** per voxel  |
| `constrained read` (4913 voxels)         | 67.0ns per voxel                  | 40.1ns per voxel            | **14.1ns** per voxel |
| `local read` (125 voxels)                | 17.5ns per voxel                  | 14.7ns per voxel            | **3.8ns** per voxel  |
| `X-direction read` (17 voxels)           | 17.8ns per voxel                  | 25.9ns per voxel            | **4.2ns** per voxel  |
| `Y-direction read` (17 voxels)           | 18.4ns per voxel                  | 33.3ns per voxel            | **4.5ns** per voxel  |
| `Z-direction read` (17 voxels)           | 18.6ns per voxel                  | 38.2ns per voxel            | **5.4ns** per voxel  |
| `long Z-direction read` (65 voxels)      | 18.0ns per voxel                  | 37.7ns per voxel            | **5.1ns** per voxel  |
| `full write (dense)` (81920 voxels)      | 17.9ns per voxel                  | **10.3ns** per voxel        | 12.4ns per voxel     |

This commit (instead of utilizing morton order) replaces `HashMap` in the
`Chunk` implementation by the following data structure:

The volume is spatially subdivided into groups of `4*4*4` blocks. Since a
`Chunk` is of total size `32*32*16`, this implies that there are `8*8*4`
groups. (These numbers are generic in the actual code such that there are
always `256` groups. I.e. the group size is chosen depending on the desired
total size of the `Chunk`.)

There's a single vector `self.vox` which consecutively stores these groups.
Each group might or might not be contained in `self.vox`. A group that is
not contained represents that the full group consists only of `self.default`
voxels. This saves a lot of memory because oftentimes a `Chunk` consists of
either a lot of air or a lot of stone.

To track whether a group is contained in `self.vox`, there's an index buffer
`self.indices : [u8; 256]`. It contains for each group

* (a) the order in which it has been inserted into `self.vox`, if the group
    is contained in `self.vox` or
* (b) 255, otherwise. That case represents that the whole group consists
    only of `self.default` voxels.

(Note that 255 is a valid insertion order for case (a) only if `self.vox` is
full and then no other group has the index 255. Therefore there's no
ambiguity.)

Rationale:

The index buffer should be small because:

* Small size increases the probability that it will always be in cache.
* The index buffer is allocated for every `Chunk` and an almost empty `Chunk`
    shall not consume too much memory.

The number of 256 groups is particularly nice because it means that the index
buffer can consist of `u8`s. This keeps the space requirement for the index
buffer as low as 4 cache lines.
2019-09-06 18:20:15 +02:00
assets Merge branch 'desttinghim/sound-effects' into 'master' 2019-09-06 11:19:32 +00:00
chat-cli Disabled unsafe using lint level. 2019-08-19 14:39:23 +02:00
client common: Rework Chunk and Chonk implementation 2019-09-06 18:20:15 +02:00
common common: Rework Chunk and Chonk implementation 2019-09-06 18:20:15 +02:00
server common: Rework volume API 2019-09-06 15:43:31 +02:00
server-cli Added modular building generation 2019-08-31 11:44:52 +01:00
voxygen voxygen: Make the Terrain struct generic 2019-09-06 15:43:31 +02:00
world common: Rework volume API 2019-09-06 15:43:31 +02:00
.gitattributes Added LFS config, removed modules 2019-05-03 13:18:14 -04:00
.gitignore gitignore: Add .envrc (direnv config file) 2019-08-14 14:58:41 +02:00
.gitlab-ci.yml Remove all warnings 2019-09-04 19:03:49 -04:00
Cargo.lock common: Add benchmark for Chonk 2019-09-06 15:44:36 +02:00
Cargo.toml Improved performance and compilation speed for debug builds 2019-05-12 18:43:55 +01:00
CONTRIBUTING.md Add CONTRIBUTING 2019-05-17 01:34:07 +00:00
LICENSE Fix license repo name 2019-04-22 20:32:40 +02:00
README.md Clarify supported platforms in README 2019-06-29 11:45:10 +02:00
rust-toolchain Fix CI problems 2019-07-06 18:03:29 +00:00

README.md

Veloren logo on a screenshot

pipeline status coverage report license discord

Welcome To Veloren!

Veloren is a multiplayer voxel RPG written in Rust. Veloren takes inspiration from games such as Cube World, Minecraft and Dwarf Fortress. The game is currently under heavy development, but is playable.

Development

Currently the communication of contributors happens mainly on our official Discord server. You can join it to keep up with the development, talk to us or contribute something yourself. Anyone who shows genuine effort to help is welcome in our team. You don't have to know how to program to contribute!

Useful Links

The Book - A collection of all important information relating to Veloren. It includes information on how to compile Veloren and how to contribute.

Future Plans - Go here for information about Veloren's development roadmap and what we're currently working on.

Official social media and websites

Get Veloren

You can download up-to-date builds for Windows and Linux from Gitlab CI pipelines (refer to the Download chapter in the book for more information). As of 0.2, due to rapid developement stable versions are outdated and incompatible with the public server.

If you want to compile Veloren yourself, take a look at the How to Compile Guide in the book.

F.A.Q.

Q: How is this game licensed?

A: It's free to play, modify and distribute. Forever. Since it is a community project, we decided to license it under the GNU GPL 3.0 license which means it will always stay free and open source.

Q: What platforms are supported?

A: Veloren can run on Windows, Linux and Mac OS on all architectures (although x86_64 is our main focus). It's probably possible to compile Veloren on/for BSD, Fuchsia and others as well.

Q: Do you accept donations?

A: To keep Veloren a passion project free from financial incentives we will only accept donations to cover server hosting expenses. There is no way to donate yet.

Credit

Many thanks to everyone that has contributed to Veloren's development, provided ideas, crafted art, composed music, hunted bugs, created tools and supported the project.