You know curves and a good curve editor are pretty underrated. Once you start to use them you find ways to use them everywhere. So I wanted to get them in early so we could take advantage of that.

I think it has everything that most reasonable people would expect, and using it in game is simply just 

curve.Evaluate( time )

.

I took a lot of care when coding the editor so that all the components are separated. The next step for curves us to have the random point between two curves structure, so I wanted to leave the door open for that.. but also I can imagine there's a bunch of other scenarios where editing multiple curves on top of each other is useful.

The transformation system has been a pain point for us, it was difficult to maintain and could cause some major rendering problems in some GPU vendors if used even sightly differently. It's used for animating, instancing and positioning models.

We've previously moved that system to Constant Buffers but that also caused it's own set of problems on editor tools and things that need a lot of transformation slots at once like cloth.

I've decided to rip it all apart and rework it using structured buffers, it gives much better stability in complex scenes.

It also makes it much easier for us now if we need to maintain it, but I think it's in a point where we don't even need to iterate much on it anymore.

All bakscratch ever asks from me is to clone Dota 2 Hammer features, so here's a couple of the useful ones.

I've started adding hotkey hints to the tool UIs, there's loads of useful hotkeys nobody really knows about - this should make it more intuitive to learn.

I've added several new alignment commands for aligning targets to other targets or the workplane, or vice versa.

A bunch of new clothing this month. Ranging from medieval helmets to cardboard armour! 

I think this month has been mostly behind the scenes and adjustments / fixes rather than anything too showy or flashy like previous months. Although we've gotten some fun new outfit pieces this month!

Tactical Helmet has been added, contributing to a possible outfit combo.

Cardboard armour has been added, contributing to another possible outfit combo.

New Additions - Tactical Helmet, Cardboard Chest, Cardboard Legs, Medieval Helmet

Texture Adjustments - Tanktop, Long Sleeve Shirt, V Neck Shirt, Blue Shirt, Office Blazer

On top of that, a bunch of adjustments have been made to clothing, including retextures and skinning, so everything works all nicely together. Still a few pieces to fix and adjust but we're going in the right direction to having awesome clothes that layer on top of each other for fun combo outfits!

Next month should be a lot more tasty, with lots more outfit pieces coming. 

The post-processing editor was a bit annoying to use and was a little outdated in its feature set. Some quality of life features were added like context menus, the ability to duplicate layers across each other, and better visibility.

 

Whilst working on a simple VR game the performance was really unplayable.

So this month Sam and I have reduced the VR frame time by as much as half in some circumstances, my simple VR game went from ~9ms to ~4ms on average.

Memory usage should be also much more manageable on VR

Frame time is super important in VR, if we can't do it fast enough we're gonna end up reprojecting - not nice.

I ripped a load of over-complicated shit out, mainly multi GPU because nobody is going to ever use that. Simplifying the render pipeline lets us identify pain points a lot easier as well as makes maintenance much more manageable.

multiview instancing

We broke multi-view instancing early on in development with a push on desktop rendering. Sam has recently redone the transform system again making transform instances much easier to do, so he also spent time fixing that.

This means VR rendering draws on both eyes simultaneously for each draw call command instead of having to draw for each eye.

He's also refactored most of the code for it so any custom shader should be able to use it without much thought, as long as they keep within the correct contract from the base shader.

oculus hidden areas

Most VR headsets have a fair amount of the display that your eyes will never see, this is called a hidden area. We can avoid rendering these for a nice performance boost.

We were already doing this for non-Oculus devices, unfortunately SteamVR doesn't provide the hidden meshes for Oculus devices.

So I created a quick tool and with the help of the community dumped the hidden area meshes.

These hidden area meshes manage to reduce the amount needed to draw anywhere between 9-14%, on an Oculus Quest 2 the rendering area is reduced by 9.13% - that's 633,000 less pixels the GPU has to slave away rendering.

Refractions never seemed to work on particles until now! You can now distort to your heart's content

I continue to add props to flesh out Construct and provide more fun things for players to spawn and build with. There is a bit of a construction theme with the road barriers, wooden pallet, crate and sandbags. Along with the construction props, I also made various lights. These should hopefully be useful for a lot of maps, not just Construct.

Something I'd noticed is people struggled to know if they were getting errors.

I've added log category filters and counts to the editor console, so you can quickly and easily see your errors or warnings.

Me and Sam decided to baptize this and next month almost entirely to be focused on rendering optimizations, Sam suggested us to try to use integrated GPU during development to try to better profile how the result of experience would be for the most common player, and that's going to be our benchmark. 

We're taking the time to rehaul a lot of features & add improvements on top of them to boost everyone's FPS. 

We've seen jumps of upwards of 40-50+ FPS this month and we have plenty of tricks up our sleeve to make this better! Stay tuned

WIth the whole rework to upgrade Steam Audio, this introduced a bunch of cool new things we can do to speed up the old process. Reverb & pathing now can be baked into maps using your GPU. No longer do you have to wait 30 minutes just to bake your audio, it only takes a few seconds to a minute on decent-sized maps now!

This month, I went back to the Citizen meshes, and did another skinning pass to fix & improve a few things, in the interest of providing the cleanest possible base for everyone (and especially Dan) to work on. For those who don't have access to the game's developer preview, an updated file is available on the wiki.

The LOD meshes were also improved, with one significant change worth mentioning here: now, the first LOD level doesn't change the body mesh at all. This means fewer headaches needing to sync with a new underlying topology.

By reorganizing the hierarchy around helper bones, there is now better support for limb scaling. Well, to be clear, this isn't actual per-bone scaling; that's not supported by the engine. In short, it means that things will now look much better when an animation changes the length of a limb. (There's a more detailed technical explanation on the wiki if you're curious.)

In this video, I push lengths to about 150%, and the model still holds up reasonably well. My own animations and poses rarely leave the ±10% range.

Speaking of animations, I've been focusing on making the Citizen animgraph to be easier to maintain, extend and understand. Part of this has involved refactoring the "weapon branches". This is an ongoing effort that doesn't cover all of them yet, but hopefully the many added comments help you wrap your head around all these nodes and how they work together.

I've been working on bringing addon templates into the editor. They're basic right now, but functionally it's all there.

You can add your own local templates with common features that you'll use across projects. It supports any type of addon, not just games.

I'll probably work on a shooter template next, and see from there. I really want to look into varying templates, and not just having FPS games left right and center.

I ripped out the c++ soundscape system and re-wrote it in game code. So good news, you don't have to edit text files to make soundscapes any more!

From the mapper's perspective the soundscapes work the same. Make the entity and select the soundscape. The only difference is that soundscapes are assets - so you get to pick the soundscape from a list instead of typing a name in there.

There's also a debug overlay so you can see what's playing and when the stings will next play.

We had games compiled in tools already - now they will automatically recompile without being in-game too.

This is pretty useful for modifying Hammer entities or GameResources.

We're trying to get to a place of stability right now. Render performance isn't that acceptable right now, especially considering the tiny amount of things we're rendering. We're getting weird rendering bugs all the time that don't seem to get fixed, or when they do get fixed, they introduces 3 more. So I'm trying to encourage the team to slow down, stop chasing the pretty things that are fun to work out, and lets all work together to solve some of these issues.

This stuff is inherent in what we're doing. We're renovating an old house, we're taking down walls and ripping down ceilings. We should work as carefully as we can but every now and then we need to take the time to clean up all of mess and sweep the floors.. 

Overall I think we did a decent job of sweeping the floors this month. There was some disturbance, but we have left things nicer than when we started.. ??