Devblog 164

Shadowfrax has the update for you.

I don't know if you guys remember this, but some time ago I had some concept art whipped up for Scientist NPCs. Last week I spent some time programming some rudimentary bots to help me test weapon balance against actual human targets in Rust. As I was programming the bots, I realized that a lot of this work would be needed if we wanted to add humanoid NPCs to the game--something we've wanted to do for a long time now--and it could be recycled for the main game. So I pushed ahead and made great progress. The bad news is it took up all of my time and it's not ready for this week, and we're trying not to release total garbage that crashes servers so this deserves some significant testing. Check out a video of them in action: Whoops - This will take a few hours, I'll tweet it out when complete. I'm thinking I'm going to create a few different tiers with different weapons (and perhaps different colored uniforms) and I'm going to spawn them at certain radtowns. You're not going to get exactly what they have when you loot them, but you will get some interesting, new loot types. They'll be quite a bit more intelligent than the shitty animal AI that we have. They currently know how to chase, flank, take cover etc. I think it'll be a fun addition to the game, and will finally give people something to go out and slaughter other than naked people who just bought the game (however if that is how you get your jollies then you can keep on keeping on). Maybe I'll find a way to reveal some of the canon Rust lore through these guys too... We're also going to have to concept up a new radsuit, as the current model was designed for these NPCs, maybe we'll do something patchwork... definitely without frog boots, though.

I fixed the two biggest annoyances when picking up items. The first one was that seeds were always trying to go straight to the belt hotbar, even if there were other seeds in the inventory. This is now fixed so seeds (and any other stackable items for that matter) prefer the container that has other items of their type in it. The second one was that consumables like mushrooms worked essentially inverse to seeds in that they never went to the belt hotbar, no matter if it contained other mushrooms or not. These consumables now prefer the belt hotbar, but will just like any other stacked item still move to the inventory if it contains other items of their type.

I'm back on the new foliage system after keeping it on hold over the last couple of months due to more pressing issues. I've added randomized tinting, scaling and distance fadeout to bring it up to feature parity with the old grass system and the SpeedTree shaders. I've also added placement rules based on value noise which will allow artists to get some pretty convincing results when mixing multiple grass and foliage meshes. Another thing I've started to explore is rendering it with instancing instead of batching, which would greatly reduce CPU load and memory usage. The plan is for Vince to take a stab at some new grass when he's back from vacation. Until then all of these changes will remain disabled and therefore invisible to you guys.

Skins are still a major cause of performance issues for a lot of people, particularly when encountering a lot of new skins that haven't been cached yet. As a short term solution I've added a system that downloads and processes all visible skins in the loading screen when spawning or respawning. This eliminates the significant performance drops right after waking up and especially helps people with slow internet connections since they were experiencing major lag when loading the initial batch of skins. This functionality can be toggled with the "skinwarmup" convar, so if something's not working right just set it to 0 to disable this completely. As a long term solution we've decided to implement our own thread safe backend to load the skin textures from the PNG files on disk and compress them to DXT. This isn't done yet, but when it is it will finally completely eliminate the remaining 30-60ms lag spikes the Unity texture loading and compression methods cause on every call. Up until now we were hoping Unity might take care of this for us and add async methods that don't block the main thread, but it doesn't look like that's gonna happen any time soon, so we've decided to take things in our own hands. I'm hoping to finish this up over the weekend so we can start testing next week.

There have been a couple of things left to optimize in the deferred decal system. Some decals had instancing disabled on their materials which made rendering them much slower than the rest of the decals. Animals were incorrectly spawning a lot of footprints on all surface types even though they were barely visible. All of these are now fixed and decals seem to be in a pretty good place.

After our custom instancing implementation worked out quite nicely to speed up rendering of the deferred decals, I added instancing support to the foliage displacement pass this week. This should significantly reduce the performance impact of having foliage displacement enabled, particularly when a lot of players are around.

I've started working on a new optimization for which I'm expecting to reap considerable benefits. We started this game using Unity's standard shaders that, while quick and easy to use, were not optimized for particular cases. We've since been improving the shader backend to make it faster and prettier, but never once changed or optimized the material inputs themselves: properties and textures. Some of our materials have dozens of properties and way too many textures. This can become a huge bottleneck rather quickly, especially in regards to the latter. This work will involve packing texture data to reducing the amount of textures we use. The end result will be reduced rendering bandwidth requirements, faster shaders via reduced latency, savings in game build size and, more importantly, savings in both system and video RAM usage. It should benefit low-end hardware more than anything else, but improvements should be noticeable across all hardware levels. We implemented and shipped a similar solution a long while ago, albeit only for terrain rendering. It made sense at the time, since it was usually more than half of what was visible at any given frame, on average. We'll now extend it for everything else.

I've been meaning to work on improving our shadows for a long time but, for now, there are still some major optimizations to roll out before I can really dive into it. What I managed to do, in a relatively short time, was roll out contact shadows, which have a good effort to benefit ratio. Contact shadows are a screen-space shadow technique that work to complement regular shadow mapping. They are more precise at capturing local shadow details on surfaces. After turning them on, the first thing you'll notice is the view model now has self-shadowing: Player shadows instantly make more sense: You'll notice it in a ton of other places as well: e.g., in your constructions where sun/moon light leaking inside is mitigated or even eliminated. Unfortunately, however, this technique costs some runtime performance, and they do fail in some situations. You'll notice how grass shadows become much darker and more pronounced. You can expect improvements in this area. Contact shadows are disabled by default and the toggle can be found in the Graphics configuration menu, under the Graphics Quality, right above the Shadow Cascades option. Feel free to give it a try. I would recommend it for players running on NVIDIA GTX 970/1060 or AMD R9 380 class hardware or higher.

With Vince on vacation this week, and with the rocket factory building finished, I have moved on to work on the remaining parts of the launch site. I finished a new warehouse building and reworked the layout of the surrounding area to be more structured. In addition, I began working on the dressing pass to bring this area up to the target quality. Before leaving for his holiday, Vince has finished dressing the checkpoint areas.

Just letting you know that work continues on getting Hapis Island feeling and looking all proper. There are many improvements and some radical changes lined up (did you spot the hint in last week's blog?). I'll go into more detail as we get closer to the end of the month.

I spent a good chunk of time testing music this week and found some spots where intensity changes felt off, or songs felt wrong at certain intenisty levels. I've fixed most of these already, but there's still a couple spots where I need to write more music clips to fill gaps in the newer songs.

Feedback on the metal melee impacts was kind of mixed last week, so I did another pass over the picks this week and made them a little deeper and beefier. Now that my ears have had a break from the newer footstep sounds for a little bit I did another pass over the barefoot footsteps (and will be moving through the rest of them next). Most of you probably won't notice this very much, but they're a bit cleaner and more natural sounding now. I fixed a bug where sounds would occasionally get cut-off a tiny bit early if they were pitched down during pitch randomization. This wasn't a problem a while back because we used to have a short delay between stopping and recycling a sound. We've removed that delay, and although it wasn't really noticable most of the time, you'd occasionally hear a faint click at the tail end of a sound if it had been pitched down because we weren't taking the length changes caused by repitching a sound in to account when deciding when to recycle it. I also created a new sound for the dropbox/mailbox, and made mix & volume tweaks to a handful of sounds.