* refactor meshing and trait API to replace guillotiere types
* associated config type on atlas trait
* investigate other areas of sprite performance like LOD scaling (i.e.
there are now significant gaps in between meshing)
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).
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.
