This Friday we discuss the outcome of last week's investor demo and answer your questions about NS2 playtesting, the map viewer and micro-investments. We also have new podcast music from our friend Jeff over at Chasing the Sun Productions!
I previously wrote about a tool we're developing to speed up texture production. This tool is a Source map/model viewer with the ability to "hot load" textures, materials and models. The idea behind this tool is that an artist can keep it open while working on an asset in Photoshop, and as soon as they make a change, they can see it updated in a 3D environment that closely matches what it would look like in-game.
The core functionality was in place the last time I blogged about it, but the "closely matches" part was somewhat unfulfilled. Since then I've added quite a bit, including support for loading models, fixing the shaders, support for self-shadowed radiosity normal mapping, rendering the sky (both the sky box and the 3D "sky model"), and loading files directly from Steam's GCF archives.
Here's what a Team Fortress 2 level looks like loaded in our viewer:
As you can see, it is indeed getting pretty close. Not everything is exactly as it appears in Source, but I'll leave it as an exercise for the reader to figure out the parts that aren't quite perfect yet.
I also did some optimization so that levels load and render faster in the viewer; this is one area where I'm particular optimistic about transferring my experience back into the Natural Selection 2 code base. One of my pet-peeves about most modern games is slow load times, and I hope that we can significantly raise the bar in that area.
The other side effect of working on something like this is that I've learned a few things about the Source engine. In fact, I originally wasn't planning on adding support for meshes -- it didn't seem necessary for the original purpose of the tool -- but I decided to implement it specifically to learn more about how they work. This is something I found necessary for low level access to world meshes that our dynamic infestation feature requires.
A number of people asked in response to the last blog whether or not the viewer supports hot loading of VMT files. VMT files are text files that describe the material properties for a surface in Source, including the diffuse texture, normal map, specularity, etc. Hot loading of these files wasn't part of the original functionality, but I've since added it (check out the last podcast for more on this).
Meshes can also be hot loaded, but they must be compiled using the Source tools before they are reloaded. For texture files, our viewer can directly load Photoshop PSD files, eliminating the need for artists to compile textures as they work on them. Every time they save in Photoshop, the viewer is automatically updated with the changes. The same system doesn't work for models because 3D Studio MAX files are very difficult, if not impossible, to load outside the environment of 3D Studio MAX. In the past I've found a way around this problem, but due to the complexities of the Source MDL format I don't think it would be worth the effort involved.
There are a few more things I'd like to add before I'm ready to call the viewer done, but I'm pretty happy with the state it's in now. In future blog entries we'll discuss our art pipeline and how this tool integrates into it.
This week Max and I talk about what we've done for the past year (!) and the state of NS2 today. We describe our overall development philosophy of "growing momentum" and what you would see if you ran NS2 today.
This week Max and I answer your questions from the forums on the texture preview tool and Combat in NS2. We also discuss games that influenced the design of Natural Selection and our all-time favorites.
In the latest podcast we talked a bit about hot loading and a tool we're developing to make texture creation a bit easier and quicker. Hot loading is when you reload something while the application is running.
The tool we've developed is a level viewer that loads Half-Life 2 BSP files. It monitors disk activity and when it detects that a texture file has been modified it automatically performs that hot loading. That makes it easy to quickly preview what a texture file will look like in-game without having to manually reload anything.
In addition to this hot loading, the viewer can also load texture files in the Photoshop (PSD) format. Artists like to work with PSD files because they can store information - like layers, effects, etc. - that other formats discard. However, to get textures in-engine with Source, you have to export to TGA files and then run the command-line tools to convert them to Valve's VTF texture format. Since our viewer can use PSD files directly, artists can bypass those steps until they've finished creating the texture and are ready for it to be used to levels.
This pipeline allows you to have Photoshop open in one window, the viewer in another, and immediately see changes in a 3D environment as you make them. The viewer is really lightweight application, so it starts up immediately and having it open with Photoshop and other memory-intensive programs is no problem.
Here's a video of what the tool looks like in action. The environment you is just a texture test level (the blue and cyan checkerboards are missing files) and the capture quality is not the best, but it should convey the idea.
The viewer application is built on top of our own technology and doesn't utilize any part of the Source engine. This engine is something I've been working on for years and I use it whenever I want to prototype something in 3D. Since I've designed it to be really easy-to-use, it's generally much faster for me to do prototyping (which requires a lot of iteration) using it rather than a big complex engine like Source. I originally added Half-Life 2 BSP rendering to prototype the dynamic infestation ideas shown in this blog entry.
(In an odd coincidence, when I was writing the BSP loading code, I referenced this article which in turn references an article I wrote many years ago on loading Quake 2 BSP files).
I've also experimented with how to render Half-Life 2 BSPs with Phong illumination in this engine. Those who follow these types of things may know that the Source engine includes Phong on models in the Episode 2 code base, but highlights on the environment are still handled with environment maps. The challenge with Phong comes from how the light maps are used in Source, but I found that using the light maps to approximate actual lights in the Phong calculations worked well.
I mention this business with Phong because this is the reason that the level in the video looks so shiny. Before this tool is actually useful to our artists, I need to modify the shaders on the walls render the same as they do in the Source engine. I'm also considering implementing the same Phong illumination shader in Source to really visually set Natural Selection 2 apart from other Source games, but that's a topic for another blog entry.
In this week's podcast we talk about our first Post Mortem meeting, the four pillars of NS2, funding and creating a vertical slice of the game.