DTO 2.0 Devblog 1 - A change of hands

DTO 2.0 Devblog 1 - A change of hands
No! Down To One is not changing hands as you might be thinking, but this devblog details some of the changes I've been making to the various systems in DTO for its biggest overhaul yet, including graphics, viewmodel (including your hands!), and new main gamemode.
 
Viewmodels in Unity
One of the biggest issues with Down To One 1.0 is the characters hands. In DTO v1, I used a multi-camera setup, with a second camera that only renders the characters hands and weapon. The disadvantages of this:

• Post-Processing that relies on depth buffers (like Ambient Occlusion) doesn't work with a multi-cam setup without an incredible amount of hacks.
• Post-Processing on the second camera in general isn't plug-and-play, and required edits to shader code, which broke anytime any of my Post-Processing effects (like PRISM, the one I make) had to update.
• Extra overhead of rendering 2 cameras can really hit Unity. Unity is not built for 2-camera, large world setups, particularly when trying to use deferred rendering. Unless they've fixed it recently, there are still some 2-camera gotchas that mean each camera loops through lists of every renderer in the scene multiple times even if they're not needed to be rendered. In a game as big as DTO, this has an impact.
• Objects rendered by the second camera don't receive shadows and look 'floaty'
• Objects rendered by the second camera don't cast shadows by default

After experimenting with command buffers and tweaking the multi-camera setup, I ended up with DTO V2's solution to this problem: A 'simple' shader edit. Now, whenever a renderer needs to be rendered in front of anything else, a few things happen:

• It is registered in a dictionary on the main camera as a "First Person Renderer"
• All materials in that renderer are set to use a "FIRST_PERSON" shader keyword until they are unregistered
• This keyword enables code in the vertex shader that forces the model to use a custom view matrix (ie. a set Field Of View), and also offsets the depth the model is rendered at, so that it is always rendered in front of anything else.

An issue popped up with this: The characters feet would render on top of everything as well. This was fixed by the addition of a script that can be added to any renderer+material to tell the material never to get "first-person'ed".
Also, the custom projection matrix was not as easy as calling GL.GetGPUProjectionMatrix in Unity, as for whatever reason, it does not return the actual values that the shader uses. So, a C#-side conversion from OpenGL into DirectX Viewmodel has to be made to un-flip it and correct it:

public void SetCustomProjMatrix(Camera fromThisCamera)
{
                var projectionMatrix = GL.GetGPUProjectionMatrix(fromThisCamera.projectionMatrix,false);// fromThisCamera.projectionMatrix;
                if(isDirectX)
                {
                                for (int i = 0; i < 4; i++) {
                                                projectionMatrix[2, i] = projectionMatrix[2, i] * 0.5f + projectionMatrix[3, i] * 0.5f;
                                }
                }
                Shader.SetGlobalMatrix("_CustomProjMatrix", projectionMatrix);
}

Now, let's look at the benefits of this approach:

• Super cheap, only performance impact is a tiny vertex shader change
• Works on any shader as long as we add the "FIRST_PERSON" shader feature into it (one line of code)
• The FoV of the gun is always completely independent of the camera FoV
• First-Person models don't need any hacks to work with post-processing. They're all rendered on the main camera.
• Everything casts shadows properly
• Everything receives shadows properly (and looks a lot less 'floaty')

So, it's definitely a win. Also, something that could've technically been done in DTO v1 was the FoV of the first-person camera changed to be smaller, which really makes it look like a proper FPS:
New

Old

Stay up to date on Twitter for more devblogs @DownToOneGame.
:dtoDanger: