This Week In Veloren 69

This week, we had our 0.7 meeting. @zesterer gives us a run down on how chunk generation and loading works. @imbris discusses progress on switching to iced for the main menu.

- AngelOnFira, TWiV Editor

Contributor Work

Thanks to this week's contributors, @Treeco, @Pfau, @Songtronix, @AngelOnFira, @zesterer, and @Sharp!

This week, Gaming On Linux wrote an article about our 0.6 release. @imbris has been working on the UI library switch to iced. He is working on moving over small pieces of the codebase at a time. @CapsizeGlimmer has been working NPC speech bubble functionality. @Slipped has been working on some animation fixes.

0.7 Intro Meeting

We had the 0.7 intro meeting last Sunday. You can find the meeting notes here. We decided that 0.7 development will start on June 1st, and release August 1st. Like always, we wrote up a definition of 0.7 of what we would like to see from the perspective of a player:

As a player, I want to get quests from NPCs in settlements. I want to be sent to kill enemies, collect objects, or complete dungeons. I want to be sent from village to village and become familiar with the region.

I want to be able to open the map and get information where I need to go for a quest. I want to be able to easily find where dungeons, villages, and other points of interest are. I want to be able to open a trade window with NPCs in villages and buy and sell items. I want to be able to craft items with ingredients that I have.

I want to be able to see and hear more while in combat. I want to feel good while doing combat. I want to see particle effects from magic, and hear swords clashing together. I want to be able to add people to my combat party and interact with the game UI to do this.

We also discussed version numbers as we approach the higher numbers of 0.X.0. We decided that after 0.9.0 would come 0.10.0, followed by 0.11.0. This will allow us more versions to make the game we've dreamed of without feeling pressured. Also, we would have to make 0.7, 0.8, and 0.9 much larger to accommodate for 1.0 right after. As we saw with 0.6, large versions are best to stay away from. We also wrote down systems that are likely to be included, as well as experimental systems that could be explored further:

# Things it could include
- Quest system
- World sim
- More interactions in settlements
- More advanced UI
- Implementing design team features
- Story elements
- Audio system for combat to add more layers of music

# Experimental systems to look at
- Modding support (Mun, other scripting languages)
- LoD
- Settlement sim
- Animation system extensions
- SFX framework
- Networking system

We also officially announced the rollout of our OpenCollective account. For those who want to donate to development, this is the way to do it. It will help us support the cost of infrastructure for now. However, in the future, it may be used to compensate core developers for full-time work. You can check out our Open Collective account here.

Work on iced with @imbris

Was it a pain to get working? Or was it easier than to work with conrod?

In my opinion, iced is a lot easier to work with. A lot of the effort I put in was trying to get the scaling with window resizes to look nice. With conrod I would just scale everything down but iced's layout offers the potential for smarter scaling which first compresses empty spaces before shrinking the UI elements.

There are some issue though. For example, the text widget does not have a way to adjust its size based on the available space. So I had to make a custom widget that does this. I think once I get all the foundations worked out it will be really nice to work with. Another pain was figuring out text rendering. That's not an iced issue though.

Chunk Generation by @zesterer

There are a bunch of things going on behind the scenes that enable chunk generation to be relatively quick. In something resembling an ordering that goes from the 'core' of the engine out to the periphery of it:

1. We have a very efficient in-memory chunk storage format that not only allows us to use very little memory when storing chunks, but also allows chunk data to be very cache-friendly (more information here).
2. The world generation code has been optimised to cache important data at various stages (although there's still a lot of work to be done here) as well as only performing generation calculations for ranges of blocks that it knows in advance are noteworthy (no point wasting time generating blocks that are 100 metres in the air, for example).

   

3. When sending chunk data to clients, the data is always compressed due to point (1) but gets compressed even further by running it through the LZ4 compression algorithm. After all of this, chunks that might easily require 300 KB of memory with a naive approach to storage now require perhaps only a 10th of that on average.
4. Clients have a thread pool that is used to quickly siphon heavy-duty work such as meshing off the main thread and on to to a worker thread running on (hopefully) another core. This means that the rendering thread can continue to run smoothly without interruption.

   

5. When handing chunk data off to clients, we use a COW (Copy On Write) system to immutably reference chunk data during meshing. This allows multiple threads to refer to the same chunk data at once (including the main thread) without copying the data (in most cases).
6. The meshing code is very optimised. For each chunk, we carefully pre-calculate the range of blocks that need checking when performing surface extraction to avoid doing work for blocks that we know in advance do not have exposed faces. In addition, we move through the chunk data through the primary axis, z, to allow for good cache coherency. In the process we also do our best to avoid accessing block data multiple times, caching block solidity information between each face test.
7. Chunk meshes have a very compressed vertex format. We're able to squeeze x, y, z, r, g, b, AO, volumetric lighting, and surface normal information all into just 8 bytes per vertex. There's still a lot more to be done in this space of course, but this means that the chunk vertex buffers are fast to upload to the GPU and also fast to render once on the GPU since we can fit more vertices within the cache.