This Week In Veloren 37

This week, we released 0.4! We hear back from @Vercidium with another graphics analysis. We also take a look at the server usage from the launch party, as we had over 40 players connected at once. There has also been a lot of work done for asset creation.

Contributor Work

Thanks to this week's contributors, @Timo, @KyoZM, @Acrimon, @AngelOnFira, @xMAC94x, @imbris, @Zesterer, @Pfau and @lfauvel!

Many artists have been working on weapon models this week. @Jollyfish, @Duko, @Shimox, and @Silentium were some of the many to do this. We've also had many other artists working on other components, such as @gallostrart and @Zornithorinque working on trees, and @Lawtonfogle working on hot loading armor.

@Felixader has been keeping up with expanding lore, this week was about the background of orcs. @Sharp has just completed their river, lake, and erosion work. This is in the process of getting reviewed, and should be merged in the next few days! @Zesterer and @Sharp have been in talks about world simulation, and there will likely be groundwork done on this in the next few days. @Zesterer also worked on lots of improvements and cleaning up the code. @Qutrin is working on implementing stat points to give your character benefits, such as health or weapon damage.

Render Analysis #2 by @Vercidium

I've been asked by Yuri to analyse the game's performance again so here we go :)

I had 60 FPS while playing the game for a couple minutes and all seemed good, but then it dropped to 30 FPS. I captured a single frame and noticed there were still large gaps in the rendering pipeline where the CPU wasn't sending any work to the GPU (see the red lines on the image). I think this is still caused by GFX though.

The map was taking 13.82ms to render and the water was taking 16.15ms to render, but I hadn't seen any water yet. After restarting the game I was running at 60 FPS again, however there were still gaps in the pipeline:

I'm not sure how the water shader works but it seems like it's not doing any work at all. After finding some water and analyzing the telemetry, I wasn't sure why 519372 water vertices were being rendered. Especially since the shader looked like it was just creating flat triangles. The shader appears to be spending 62.65% of the time doing nothing. I'd recommend aligning water chunks to map chunks and only rendering the water chunk if that map chunk is rendered (frustum culling).

The map is still drawn in a random order with no frustum culling. Frustum culling is a must! There are a lot of chunks completely outside the view that are still being drawn. There were 162 chunks rendered that didn't end up on the screen. On top of that, there were 1175 rendering calls (mostly water) that didn't end up rendering any colour pixels to the screen. This is because there are lots of water rendering calls that are asking the GPU to draw 0 triangles.

Map rendering at 25 view distance spends 19.75% of the time doing nothing on the GPU. I think that's still a GFX issue but damn 6.7 million vertices per frame is a lot. Top limiting factor in the rendering pipeline is Viewport Culling at 33.9%, followed by Vertex Attribute Fetch (loading a bazillion triangles) at 30.2%. Rendering the chunks is quite fast with SM Active is at 62.2, it's just that there's a lot of fluff GFX does (16726 redundant OpenGL calls a frame) before it actually tells the GPU to render the chunk.

That's all from me, I hope it helps!

Launch party

This week, we officially released 0.4!

Thanks to all of the great contributors to this version, @Zesterer, @Timo, @imbris, @Acrimon, @Sharp, @Destinghim, @Slipped, @AngelOnFira, @Pfau, @Geno, @scott-c, @haslersn, @Qutrin, @Vechro, @xMAC94x, @KyoZM, @Andrewpritchard, @Songtronix, @Shanehandley, @telastrus, @christofferlantz, @stevedagiraffe, @Vercidium, @Demonic, @tommy, @arashout, @nick12, @lfauvel, @wusyong, @cauthmann, @yashaslokesh, @artem, @carbonhell, @appcrashwin7, @LunarEclipse, and @keller! Also thanks to everyone else who added something of their own to Veloren, the community is really what pushes this project forward :)

The launch party went great, with over 40 people joining at its peak. With over 3000 people in the Discord server now, we reach a lot more people with @everyone :P You might have noticed that the download link was through Airshipper. Although future versions of Airshipper will have clients that you can install on your computer, you can rely on this link to get you the latest version for now.

Now let's take a look at some of the server graphs! Above you can see the tick time broken down, as well as the CPU task parallelization. For the launch party, we specifically reserved a powerful server to make sure our load would be handled. Turns out it was more than handled.

The server used was an AWS EC2 instance, c5.9xlarge. This instance has 36 vCPUs, which have 141 ECU of compute power. It also has 72 GB of ram, but we were really not limited here. The instance cost ~$1.8 CAD an hour, however the real cost was from bandwidth, more to come on this below.

As you can see in the CPU usage graph, we were using around 20% of the server's compute capacity with the 40 players. Projections would show that we should be able to handle at least four times the number of players. Maybe more depending on the standard overhead that the Veloren server has.

Above you can see graphs of the players on the server, and the number of chunks loaded, and the memory usage of the server over time. The number of chunks grew over time as players explored further away from spawn. The memory usage also increased quite proportionally to the number of chunks.

The real killer of the launch party was the bandwidth. At it's peak, the server was sending out about 50 MB/s, or 400 megabits per second. That equated to around 1 megabyte per second for each player. This will have to be a domain of heavy work in the next few versions. Over the entire launch party, 110 GB of data was sent out from the server. AWS really charges hard for bandwidth use, and so this incurred a cost of ~$8 CAD alone. In the future, we'll likely host through a different service.