Also added a function that has extensive details about what the
projection options mean, and set our near plane much closer (0.25 to
0.0625) and far plane much farther (100000.25 to 524288.0625). In the
future we may completely remove the far plane (opting for an infinite
one) and may possibly improve accuracy elsewhere using analysis of other
floating point values.
Firstly, most importantly, improves the heuristic used for deciding
which chunks to mesh (which matters more even at low view distances
with meshing being so expensive now, but has an even more obvious
improvement at large view distances). Essentially, instead of always
prioritizing whatever chunk was fetched earliest from the server,
instead we prioritize chunks *closest* to the player first, then chunk
order.
This greatly improves the apparent latency for things like
picking up a sprite, as well as cases where the player moves out of the
loaded range but (due to slow loading from the server or a large VD
range) there are many remaining chunks left to be meshed still within
the VD but nowhere near the player. By properly priotizing chunks near
the player, we minimize the time / likelihood of a player being on or
very near an unmeshed chunk, and make high VDs and faster travel
speeds more viable.
We make a few other minor improvements as well:
Avoid duplicate meshing of neighbors when first inserting chunks, if
they are already in the todo list and the chunk being inserted was not
directly modified.
Also avoid remeshing neighbors if only a solid block's color changed,
which could sometimes be useful for non-sprite modifications (for
example flame-induced changes to non-destructible terrain color).
The previous fix accidentally caused meshing to not perform an update if
a chunk was already actively meshing; this change fixes this behavior to
go back to the old behavior. It also fixes a subtle bug where sprites
would be using old lighting if a chunk was being actively meshed on the
same tick that a sprite change happened (this should only affect things
in a handful of circumstances and could be avoided if, e.g., only color
was changing, but this can be addressed better at another time).
This results in an extremely visually noticeable improvement in latency
when adding or removing sprite data and makes the game feel more
responsive.
This happens, for instance, when picking up a sprite like an apple or
flower from the environment. We check to make sure that for items
with lighting (like Velorite) or changes that otherwise affect meshing
(like changing from fluid to nonfluid) this doesn't trigger.
This makes the delay afetr selecting a character before logging into the
game much shorter, in the common case. It still doesn't handle things
perfectly (it blocks creating Terrain::new if it's not finished, and it
could be faster due to working in the background), but it's still a lot
better than it was before.
To improve sprite meshing performance, we also apply the terrain
flat_get optimizations to sprites. Though I didn't initially know how
much of an impact it would have, it feels significantly faster to me,
though being able to parallelize it would be ideal.
This solves the problem of not being able to set the view distance too
high, especially in pathological cases like giant trees. For
simplicity, we just freeze any atlas where allocation failed and start
allocating to a new texture and atlas, letting reference counting
destroy the old one when there are no more references to it. Because of
the spatial locality of chunk allocations, chunks allocated together
will virtually always have similar lifetimes, so the odds of this
causing significant fragmentation are very low, meaning this simple
solution should not do much worse than a much fancier one.
- now last digit version is compatible 0.6.0 will connect to 0.6.1
- the TCP DATA Frames no longer contain START field, as it's not needed
- the TCP OPENSTREAM Frames will now contain the BANDWIDTH field
- MID is not Protocol internal
Update network
- update API with Bandwidth
Update veloren
- introduce better runtime and `async` things that are IO bound.
- Remove `uvth` and instead use `tokio::runtime::Runtime::spawn_blocking`
- remove futures_execute from client and server use tokio::runtime::Runtime instead
- give threads a Name
So first off all we had to update the toolchain, i think everything in september is okay, but we got with this current version.
Then we had to update several dependencies, which broke:
- need a specific fix of winit, i think we want to get rid of this with iced, hopefully, because its buggy as hell. update wayland client to 0.27
- use a updated version of glutin which has wayland-client 0.27 and no longer the broke version 0.23
- update conrod to use modern copypasta 0.7
- use `packed_simd_2` instead of `packed_simd` as the owner of the create abandoned the project.
- adjust all the coding to work with the newer glutin and winit version. that also includes fixing a macro in one of the dependencies that did some crazy conversion from 1 event type to another event type.
It was called `convert_event`
- make a `simd` feature which is default and introduce conditional compiling.
AS I HAVE NO IDEA OF SIMD AND THE CODE. AND I DIDN'T INTRODUCE THE ERROR IN THE FIRST PLACE, WE PANIC FOR NON SIMD CASE FOR NOW. BUT IT WORKS FOR TESTS.
- tarpaulin doesnt support no-default-features. so we have to `sed` them away. semms fair.
In the process, also try to address a few edge cases related to block
detection, such as adding back previously solid sprites and removing
filters that may be vestiges of earlier logic.
