Kero Devlog #1 - June 2020

Obligatory first-in-series preface

Kero is a project I’ve been working off-and-on on for about a year; but has its roots from around 2 and a half years ago when I first picked up Golang, and started writing libraries for parsing the many formats that Valve either used or created for their Source Engine. Turns out there are a lot, and as best as I could find, there was noone who had tackled any of them with Go (probably for good reason!).

Over time as my collection of libraries grew (bsp, vtf, studiomodel, vmf, keyvalues, filesystem, vmt etc.), I wanted to do something meaningful with these, and so in late 2018-early 2019 a project I called Gource (Go: Source) then later renamed to Lambda-Client (because Gource is already the name of piece of popular software). This was my first attempt at writing a BSP renderer for the Source Engine, and suffice to say that the project code is exceedingly low quality (although it did more-or-less work!).

Given the difficulty in managing Lambda-Client, and the difficulty I was having refactoring my own project, August 2019 was the turning point where I decided to scrap my <1 year old project and write a more reliable, higher quality renderer that might one day lead to being a full drop-in game engine (or at least a Source TV client). That project is called Kero;

Introduction

Now that Kero is a year old, and I’m fairly happy with the state of the core codebase, I’ve decided to have a stab at writing a development log. For my first log though, its probably most valuable to have a think about where the project is now, rather than recent progress without any prior context.

So in that vein, expect a big list of things that work, and things that don’t, mostly in the context of game data loading and rendering.

Current status

I’ll try to break this down into sort semblence of grouping/categorisation, of both things that work, and things that don’t. To summarise though; I essentially have a BSP renderer that can read a Source Engine game’s file structure and can render maps without lighting, entities and minimal material support.

Game configuration

• GameInfo.txt
  • gameinfo.txt is discovered and parsed in game installation directories. Information derived from this is used to configure the filesystem (see below). Other defined properties are parsed, but unused.

Filesystem

• Install directory
  • A filesystem implementation exists; creation requires a gamedata.txt to extract valid gamedata paths.
  • Detected paths that exist outside of the game directory (e.g. games that use HL2 content) or that use a special keywork prefix will not work for custom install locations. e.g all games are expected to exist in the same install folder (<steamapps/common> being the default). Default setups behave as expected.
• Pakfile
  • Bsp pakfile is supported, in the same way as any other directory
• Vpk’s
  • Game VPK’s listed in gameinfo.txt are supported and usable just as the main filesystem is
• Content priority
  • Priority of filesystem paths follows known documented priority: pakfile->filesystem->vpk

BSP

• Geometry
  • BSP geometry is supported.
• Displacements
  • Displacements are supported
  • Texture painting/blending is not currently supported.
• VisData
  • Visdata is fully loaded and utilised for world geometry and static props.
  • Displacements do not currently utilise any visibility data.
• Skybox Skybox material is fully supported.
• Lighting Baked lighting is unsupported.

Props

• Loading
  • Staticprop lump is fully loaded.
  • Many props have rendering issues; these appear to be multi-part / multi-material props. Single-material props appear to render correctly.
  • Multiple materials are not supported. They are loaded, but only the first referenced material is actually used.
  • Skins are not supported.
  • Instanced rendering is not supported.
  • Models with bones are not suppored.
  • Collision models are not supported.

Materials

• Vmt
  • Vmt’s can be fully parsed, although there are bugs in the keyvalue parser libarary (separate, but written and maintained by myself); rare cases of valid textures that can’t be parsed correctly.
  • Only BaseTexture and Translucent properties are used for rendering.
• Vtf
  • Vtf parsing and loading is fully supported.
  • Only “normal” data formats are supported (various RGB888/RGBA8888 permutations and DXT variants). Its highly unlikely to come across any other valid format for rendering.
• Error texture
  • It wouldnt be Source Engine with purple/black chequered error texture; this exists as a fallback, just as expected.

Gui

• General
  • Imgui (specifically inkyblackness/imgui-go) is used for the UI.
  • No support for any Source Engine UI; existing UI is for ease of use only.

Entities

• General
  • Endata is fully loaded
  • Only worldspawn is used, for fetching the skybox name

Rendering (NOTE: some crossover from previous sections)

• BSP
  • Geometry is fully rendered; with visdata and frustum culling used for performance.
  • Skybox material is rendered
  • Skybox geometry is not rendered
• Displacements
  • Frustum culled
  • Not visdata culled; leading to cases of incorrectly rendering displacements that should be culled
• Materials
  • Only ‘$baseTexture’ (aka Blinn/Diffuse) texture is used for rendering
  • $translucent property is supported
    • Texture-level transparency is ignored. Currently only supported method of allowing material transparency
• Props
  • Staticprops are rendered and culled using visdata.
  • Some props (appears limited to multi-part and multi-material props) are broken during rendering.
  • Each prop only has the first material applied to it; leading to incorrect rendering.
  • Support for staticprop fade max-distance.
    • Fading not supported; only binary do/don’t render

If all that was too frustrating, here is a visualisation of what Kero can render right now:

What’s next?

The honest answer is, I’m not 100% certain. There are 2 things that are first and foremost on my mind (1 major bug, 1 feature):

• Fixing broken prop rendering
• Lighting support

I’m fairly confident that those are my next tasks, but since this is just for fun, who knows where I’ll go next. I intend any future posts to be in a more understandable format.