Devblog 169

I did a tonne of work on the Bradley this week. Sadly not enough to get it in game. I tightened up the physics and added patrol paths so we can plot areas to move between on the launch site. I did a bunch of AI logic for speeding up and slowing down when approaching tight turns to keep it on track. I also implemented the first bit of the weapons systems including the main cannon. Check out some media from this week: The suspension isn't perfect, nor is the track movement, but its good enough for me to forget about. I'm working on getting a MVP out and we can improve it from there. Stay tuned!

I've continued my adventures into navmeshes this week. The navmesh is now divided into a grid, so that NPCs that are in close proximity will share navmesh and we only generate navmesh patches where we need them. I've yet to solve AI walking between navmesh patches, so some work remains here before it is ready. I also set aside some time to look at scientists this week. I set up a cover system that will generate cover points in an area. Scientists will prefer to take partial cover when shooting, seek cover if shot by an unseen attacker, and generally use cover in smarter ways.

We're considering removing support for a couple of things in the near future.

Windows 32

We don't build/ship 32 bit versions of OSX or Linux. We probably shouldn't be shipping 32 bit versions for Windows either. The obvious motivating factor is that over 99% of our Windows users are on 64 bit. Here's some stats from a single day this week: It sucks that we might possibly leave that < 1% of people in the dark, unable to play Rust until they upgrade to a 64bit OS, but the minimum specs for Rust have shown 64 bit since before we switched over to experimental. Anyway, we haven't done any of this yet, but consider this advice: upgrade to Windows 64. Please.

DirectX 9

DirectX 9 is nearly 10 years old. Unity is going to stop supporting it completely soon, so it's probably about time we did too. Life would be great if we just shipped Vulkan only on all plaforms, but I don't think Unity are there yet. This will remove support for Windows XP. Here's some stats from a single day this week: This is something we're considering just to make our lives easier, really. If you have a good reason we shouldn't do this yet then get in touch and let us know.

I eliminated the last bit of overhead from the foliage displacement system by removing the need for a second camera altogether. Rendering a camera comes with a lot of overhead in Unity, even when its culling mask is set to ignore all objects in the scene and all UI is stripped from it via hacky workarounds. So what we ended up doing is to render the foliage displacement mask entirely in a command buffer on the main camera with custom view and projection matrices. This eliminates around 0.5ms of overhead per frame when foliage displacement is enabled. I highly recommend enabling it in the options if you had it disabled due to performance concerns before.

Alistair identified a pretty big performance issue this week. When we spawn an impact effect, like footprints or projectile hits, we load a random effect from a surface type folder. The list of effect prefabs in that folder is retrieved the first time a particular surface type is accessed. This could be extremely slow, which was a pretty big issue as it tended to happen during firefights. I fixed this by generating the effect cache at build time and storing it in the game manifest file.

I redid the ore nodes visuals and their various stages of picking this week. This change will come to you by the next wipe. The nodes visuals are more in-line with the collectable stones and ore I had done before, and should look less confusing to new players as to what they yield.

For the past week I've been working on polishing and optimizing launch site. I have merged several objects in the rocket factory for performance reasons, and to prevent the visual pop-in and other LOD-ing issues. Afterwards, I began working on the remaining greybox assets, such as the AC units found on the rocket factory and offices rooftops. My goal for the next few day is to help Vincent with texturing office furniture that will be placed in the Cobalt Space Center offices.

Progress update! I've finished up on the high poly, low poly and textures, all that is left is to make the LODs and unity prefab but before then i'm just opitmising the mesh for the lodding process. Here's how it's looking now! And as usual, take a spin below too. The arm straps will be pressed against body of the bag so that it doesn't look odd when dropped.

I went back to texture optimizations this week to finish material packing tools. Deployed an automated texture packer so that when the artists modify the original textures, the system will automatically generate the packed versions. Unfortunately, I was unable to pack more materials on time for this patch but I already have two dozen packed materials ready to submit to staging right after the pach. We have hundreds to optimize so I'll keep submitting more to staging over the course of next week. At least by then we'll have a solid idea of the performance margin gained by these changes. Another thing I worked on is a texture density tool for artists and myself. It allows us to immediately identify surfaces that have much higher texel density than the surrounding area. Based on that information we can decide whether to scale down those textures or not based on, for example, our ability to get close or zoom in. Here's what the view looks like using this tool: It displays the number of texels per meter based on the specified reference number, 512 in this case. Blue tones have lower density and yellow/red tones have a higher density. In the image above we can clearly see that the sewer cap could be reduced to a quarter size without losing that much detail, from 16MB to 4MB. Finally, I also reduced the lowest quality mode, aka Potato or q=0, textures to 1/16th size and q=1 to 1/4th. This change seems to free up about 1GB of VRAM in q=0 and about 2GB in q=1. Might reduce q=2 as well depending on the feedback.

I sorted the issues I was having with our version control last week (I ended up having to manually copy/paste all the changes over to a new branch), and the new music stuff is in! I've done some testing on staging this week and found and fixed a few little bugs but everything seems to be working pretty well in game now. There is one spot where stuff isn't 100% yet, which is on the loading screen. Occasionally on the load screen the framerate is low enough that new music clips don't get queued up in time. You'll mostly notice this with clips that are short and repeated quickly like some of the 1 bar bassline loops. I've got a few ideas for solutions to this though so I'll come back around to this after I spend some time back on regular sound work. I've made the scale of the volume sliders for music much more reasonable. Having music volume set to 0.3 doesn't make the music louder than everything else in game anymore, so you'll probably want to adjust your music volume.

I also fixed a few minor issues with footsteps this week that have been bugging me for a bit. Footsteps should play more reliably when you're moving down a steep incline. The choice between walking and running footsteps is based on how fast you're moving now instead of whether you're holding down sprint or not, so more appropriate footsteps will be played if you're moving slowly up a hill. Walking on ore nodes is not longer silent too. I've also done some leve adjustments and mix tweaks to a handful of sounds this week.

I've been (excitedly) digging in to work on sounds for the Bradley this week. Dynamic engine sounds are tough to get right. Pitch shifting loops up and down for speed changes sounds like shit. Fading between loops and trying to splice aceleration and deceleration sounds between loops isn't super flexible and can still sound phony a lot of the time, so I'm experimenting with getting granular synthesis implemented in Unity and hoping we can go that route for the engine sounds. With granular synthesis, you play tiny overlapping slices of audio from a given point in a file (usually randomizing the start time a tiny bit so you're not playing the exact same piece of the file for every grain). The goal here will be to create a sound file that contains a long slow acceleration and then map the grain starting position to the speed of the Bradley. There's some cool sounds that a Bradley makes that won't be doable with only this approach, but I think we'll be able to layer those details over the base engine sound we get from the granular synthesis. When it accelerates really quickly it does this great low-mid range roar that I really want to get right. I've found some solid source material to use for the guns and all that too, but I'm focusing on getting the engine sounding great first.

And all that in video form, via Shadowfrax.