Devblog 122

Well this was quite an endeavour! I kept asking myself, 'Why is my FPS great when I join a server with no-one on it, and as soon as I join a populated server my FPS tanks down to 30?' My assumption had been that lots of people meant lots of building and that meant more stuff to render, thus lower framerates. I was wrong. Check it out: See all those black marks? Those are other players. They are either alive or sleeping, and they're Thinking, Rendering, Skinning, and doing a whole bunch of unnecessary garbage on my computer, even though I can't see nor interact with them. Players are by far the most CPU intensive entity to compute on our Clients, and even just seeing 10 would have a significant impact on frame-rate. I thought to myself, 'What if we just try and detect if the player would actually be visible to us, and if not we switch them off?' What started out as a test actually ended up leading surprising and impressive performance improvements. I’m drawing a ray between players and the local camera, and if you can’t see the player, they switch off. This has lead to a very significant performance improvement for most people I've talked to, the average improvement seems to be 20-30%! Here is an On/Off comparison (note FPS/MS counter at the bottom).

Before

After

I had to do a few edge cases to solve problems with players popping in and out of view during battles, but right now here is how it works: If none of the above edge case checks are true: There is a list of convars that can help you configure Player Culling if you are so inclined, but the default settings should be fine. Write “find playercull” in the console (F1) to see the configuration options. They have help text to let you know what they all do. If, for whatever reason, you end up having worse FPS, you can always disable player culling by typing “playercull.enabled false” in the console. I really hope everyone sees a decent performance improvement with this optimization. You’ll notice it especially in highly populated areas or perhaps after a wipe when most players are on the beach.

I found a major source of lag during gunfights which caused what some people have dubbed ‘microstutters’. Basically, any time a players 'wearables inventory' changed it would network this to all other players that could see it, and those clients would rebuild the player model so it appeared as it should with the appropriate clothing. The problem was that this rebuild would happen no matter HOW the wearables changed. Remember when we added condition to armor? Well, the condition being lowered from taking damage counts as a change, which meant the entire player model was rebuilt every time you shot someone wearing armor, which would freeze your client for a fraction of a second. I've changed it so it compares clothing before and after a network update and it only does the rebuild if it has truly changed. Although less noticeable, this lag happened when harvesting or dealing damage to player corpses as well and is also fixed.

As you all know our CPU performance has been crap for the longest time. This week, Helk and I tracked it down to one of the biggest bottlenecks: player models. In highly populated servers - between LOD selection, animators, state machines, skinning - this alone was costing us upwards of 10 ms (!!) total CPU time. Essentially we were CPU bound and having a strong graphics card would make absolutely no difference. Helk was in charge of player culling - more details in his blog post - while I went on to optimize players that are actually visible. So far, I've identified, and eliminated, an important source of overhead that was, thankfully, to be completely avoidable with some trickery: Between Helk's changes and mine, there's been a massive improvement and we are now finally GPU bound again, which is a good thing since graphics can scale very well in both quality and performance.

I played a bunch with the Double-Barrelled Shotgun and it just didn’t pack the punch it was supposed to, so I’ve increased its damage multiplier from 0.75 to 1.0. This means it does the same damage as a Waterpipe per-shot, however I have increased the spread so it’s less accurate--meaning its effective range is smaller--but I’ve also reduced the re-fire rate to 0.5 instead of 1.0 so you can get both shots off quicker. I think it’s a good, balanced trade-off.

People used to be able to throw a supply signal and know with 100% certainty that the supply drop would land exactly on the marker. People used this to ensure the supply drop would land perfectly on their little 1x1 rooftop tower with no hope of anyone else getting it. I’ve changed it up so there is a +/- 20m radius offset for the landing position of the supply drop making it still land very close to the signal, but not completely predictable. I’ve also lowered the chance of supply signals being found in crates, etc.

Continuing my work from last week, I’ve cleared out all the garbage from the Supply Drop. No more apples or torches! Ammo is the “worst” thing you can get from them now.

One problem that still exists that you may have noticed when walking around is your FPS would drop down significantly while loading in player bases for several seconds. This is an ongoing issue that we are working on and we should be in a much better place for performance when it is resolved.

Hello! I'm here as an Environment Artist, so I will be mostly working together with Vince on fleshing out the monuments and improving the quality of the world. I've finished creating a greybox for a revamped Lighthouse monument. The exterior and interior parts are both done, so the mesh is ready for detailing. This new version is much larger than the old one and includes both a Lighthouse and a bunker-like structure. The more complex layout should make it more interesting to explore and the Lighthouse itself could be a good sniping spot. I spoke with Vince about adding a second variant, which would consist of only the tower itself, and we both agreed it would help in adding more variety.

Progress on the tunnels art is going well. I’m in the process of revamping the military tunnels dungeon as well. The current layout felt uninteresting, and thanks to addition of a few new pieces of tunnels (such as one slope going a level up/down) I'll be able to expand into more compelling layouts. One thing that also came to my mind was that while the tunnels are cool for the map, they’re big and probably should not be in more than one or two places on the server. I am thinking of adding old style mining tunnels made of timber; these would offer a nice alternative to big concrete structures. It would also be an ideal size to blend into sewers and natural cave networks while large concrete tunnels need equally large caves and reasons to connect into those. We’ll see how it turns out.

I dug deep into the rabbit hole with this one. In Rust any interaction you do with a weapon is verified in one way or another on the server to make sure clients aren’t just doing whatever they like. These checks have been added by about three different people over the entire lifetime of the Rust reboot. Things get lost and forgotten and regressions are pretty much guaranteed. The worst thing is that most of the really old checks didn’t log any server message whatsoever but instead silently rejected the action the player attempted. For projectile weapons this usually meant that at some later point a “X fired invalid projectile: Missing ID” message was logged, but then it was already too late to see where the problem actually originated from. I combed through the code base looking for those kinds of checks, unified all of them and added warnings whenever player actions were deemed invalid and would therefore be rejected. Then I put it on our staging servers and Alistair and I kept an eye on the logs. We identified a fair number of issues where melee attacks were incorrectly rejected or projectiles were lost on the server and at this point it looks like we finally fixed all of them. Now since some of those problems are difficult to reproduce in a test environment it’s entirely possible that there are still some problems that we didn’t find. However, at least we have detailed server logs now that should tell us what went wrong as soon as it goes wrong.

This was another highly annoying bug that’s been around since forever: it was only possible to interact with the code lock on external gates from one side of the gate. The solution turned out to be really simple, but getting it fixed made me feel nice and cozy inside.

Most of the stuff I looked at this week isn't going to make the update due to needing some coder love first. I did manage to update the Beancan Grenade view-model animations though. The deploy started in the wrong pose, causing a visual glitch when enabling, and there were no animations for the loop. Also made the other animations look more in line with the F1 Grenade.

Before

After

I've finished off the low-poly bake for the bone armour. It's a really complicated piece, but I'm really pleased with how the bake has come out. I'm still working on the human skull helmet, and I think I'll also make the bad-ass deer skull helmet Paul concepted to add a little variety to the set. You can take a spin around it here, to get a feel for what it looks like from all angles:

I finished the high-poly version of the LR300 Assault Rifle. I tried to go with some nice color variety instead of keeping the gun all black, as I find that can be a bit boring. And here you can see a 3D model of it:

I did a first pass at sounds for the Double-Barrelled Shotgun this week. There was a really good reaction to how deep and cannon-like the placeholder sounds were, so I tried to carry that through to the new sounds too! I’m pretty happy with how these came out, but I think some of the foley during the reload animations sounds a little light compared to the gunshot sound, so I’m on the hunt for some larger hunks of metal that are connected in interesting ways to record for meatier reload sounds.

Now that we’ve got the base of the music system set up I’m working on filling in the gaps. Right now the harvesting-trees-and-rocks-in-a-sunny-field music is the stuff we’re lacking the most, so I’ve been writing more and focusing on that vibe this week. I’m focusing on the zero intensity playback before diving into any of the tension layers. Writing has felt much more natural since the music playback system has been fleshed out, but it’s still tricky to keep the mysterious/dangerous Rust vibe and capture the calm farming zen feel at the same time. Here’s a preview of one of the bits I’ve been working on:

Here’s a preview of some concept work for a craftable vending machine that players can place down at their bases and use to offer items for trade with others. This is just visual development for the look and how they would place and sit in a wall frame. We're going for a improvised look: using an old soda vending machine modified with a crude keypad and screen interface that you would use to select a trade, and a large tray at the bottom that you would place your items and then receive what you wanted back. It'll be pretty interesting to see what kind of economy comes from this, and how players value certain things like weapons for stacks of resources in the game.

The header screenshot is another look at the graphics overhaul I'm working on. Here's some more.

Just a note that I’m still working on adding a form of researching back into the game. It is taking a little longer than expected, and took a bit of the back-seat to the performance optimizations this week. I’m aiming for next week, and I'll keep you all posted on Reddit.