big combined updates.
- Add a timer to the stats persistence system and change the frequency
that it runs to 10s
- Seperate the loading of character data for the character list during
selection, and the full data we will grab during state creation. Ideally
additional persisted bits can get returned at the same point and added
to the ecs within the same block.
- Update client code to use persisted stats
- Add a system for stats persistence
- Add a basic scheduler to control duration between execution of
persistence systems
- Make the character screen load with an empty character list from the server, send event to the server for character creation with data, but not yet saving them to the DB.
- Working but messy character saving to DB
- Add the character_data to the client, rather than keep it in the GLobalState.
Horizon mapping is a method of shadow mapping specific to height maps.
It can handle any angle between 0 and 90 degrees from the ground, as
long as know the horizontal direction in advance, by remembering only a
single angle (the "horizon angle" of the shadow map). More is explained
in common/src/msg/server.rs. We also remember the approximate height of
the largest occluder, to try to be able to generate soft shadows and
create a vertical position where the shadows can't go higher.
Additionally, map generation has been reworked. Instead of computing
everything from explicit samples, we pass in sampling functions that
return exactly what the map generator needs. This allows us to cleanly
separate the way we sample things like altitudes and colors from the map
generation process. We exploit this to generate maps *partially* on the
server (with colors and rivers, but not shading). We can then send the
partially completed map to the client, which can combine it with shadow
information to generate the final map. This is useful for two reasons:
first, it makes sure the client can apply shadow information by itself,
and second, it lets us pass the unshaded map for use with level of
detail functionality.
For similar reasons, river generation is split
out into its own layer, but for now we opt to still generate rivers on
the server (since the river wire format is more complicated to compress
and may require some extra work to make sure we have enough precision to
draw rivers well enough for LoD).
Finally, the mostly ad-hoc lighting we were performing has been (mostly)
replaced with explicit Phong reflection shading (including specular
highlights). Regularizing this seems useful and helps clarify the
"meaning" of the various light intensities, and helps us keep a more
physically plausible basis. However, its interaction with soft shadows
is still imperfect, and it's not yet clear to me what we need to do to
turn this into something useful for LoD.
Adds removing extra components and deleting entities clientside when
going back to the character screen. Also, simplifies ClientState by
removing the Dead variant and removing ClientMsg::StateRequest in favor
of more specific ClientMsg variants.
fix(overflow): Stops including block updates that fail (since chunks
don't exist on the client) in `TerrainUpdates` (which would trigger
meshing of those nonexistent chunks). Furthermore, removes
remeshing of chunks with block updates if those chunks don't have all their
neighbours (since those wouldn't be meshed in the first place).
- Clarify caffeine fueled comment
- Be better at comparing Instant's, and catch the 0 seconds case to say
Goodbye to the user
- Switch println for 'info!'
- Bugfix: Check whether the server response (pong) is greater than the timeout period, rather than the ping (which will always fire regardless of connection status) This was causing the timeout error event to never fire.
- Feature: Send the player notifications to the chat window that they will be kicked due to disconnection for 6 seconds before kicking them back to the main menu.
Currently we only do this when no players are in range of the chunk. We
also send the first client who posted the chunk a message indicating
that it's canceled, the hope being that this will be a performance win
in single player mode since you don't have to wait three seconds to
realize that the server won't generate the chunk for you.
We now check an atomic flag for every column sample in a chunk. We
could probably do this less frequently, but since it's a relaxed load it
has essentially no performance impact on Intel architectures.
Currently we only do this when no players are in range of the chunk. We
also send the first client who posted the chunk a message indicating
that it's canceled, the hope being that this will be a performance win
in single player mode since you don't have to wait three seconds to
realize that the server won't generate the chunk for you.
We now check an atomic flag for every column sample in a chunk. We
could probably do this less frequently, but since it's a relaxed load it
has essentially no performance impact on Intel architectures.
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.
See the doc comments in `common/src/vol.rs` for more information on
the API itself.
The changes include:
* Consistent `Err`/`Error` naming.
* Types are named `...Error`.
* `enum` variants are named `...Err`.
* Rename `VolMap{2d, 3d}` -> `VolGrid{2d, 3d}`. This is in preparation
to an upcoming change where a “map” in the game related sense will
be added.
* Add volume iterators. There are two types of them:
* _Position_ iterators obtained from the trait `IntoPosIterator`
using the method
`fn pos_iter(self, lower_bound: Vec3<i32>, upper_bound: Vec3<i32>) -> ...`
which returns an iterator over `Vec3<i32>`.
* _Volume_ iterators obtained from the trait `IntoVolIterator`
using the method
`fn vol_iter(self, lower_bound: Vec3<i32>, upper_bound: Vec3<i32>) -> ...`
which returns an iterator over `(Vec3<i32>, &Self::Vox)`.
Those traits will usually be implemented by references to volume
types (i.e. `impl IntoVolIterator<'a> for &'a T` where `T` is some
type which usually implements several volume traits, such as `Chunk`).
* _Position_ iterators iterate over the positions valid for that
volume.
* _Volume_ iterators do the same but return not only the position
but also the voxel at that position, in each iteration.
* Introduce trait `RectSizedVol` for the use case which we have with
`Chonk`: A `Chonk` is sized only in x and y direction.
* Introduce traits `RasterableVol`, `RectRasterableVol`
* `RasterableVol` represents a volume that is compile-time sized and has
its lower bound at `(0, 0, 0)`. The name `RasterableVol` was chosen
because such a volume can be used with `VolGrid3d`.
* `RectRasterableVol` represents a volume that is compile-time sized at
least in x and y direction and has its lower bound at `(0, 0, z)`.
There's no requirement on he lower bound or size in z direction.
The name `RectRasterableVol` was chosen because such a volume can be
used with `VolGrid2d`.
