I figured it would be fun to post occasional screenshots of the island so people can see it gradually come together over time. Here's the first one.
Keep in mind that this is all a rough draft for gameplay purposes, and none of this is supposed to look remotely like final game visuals.
Despite not looking fancy yet, there's already more than 5 hours of gameplay. So that's pretty good.
(Click image for full size.)
In the previous part, I talked about my reasons for wanting to use Cascading Shadow Maps (one of the biggest: image stability), then said that we had implemented Michal Valient's version of the algorithm, and mostly liked it, but wanted to reduce the memory usage.
This time I'll show how to reduce the memory usage by 25% on machines that support non-power-of-two textures; or, on machines that don't, how to fit 5 shadow maps in the space previously used for 4.
Ignacio has implemented the first version of the handling for light sources that change (doors that open or close, lights that can be switched on or off, etc). The idea is that we just precompute different lightmaps for each of these cases and blend between them at runtime. In the future (not the future of this game, but the general computer graphics future) when we have realtime global illumination, this would not be necessary; but for now this is much faster to compute and much easier to implement. The drawback is that we have to think about the different cases in advance (things can't be too dynamic) and the amount of lightmap storage space grows rapidly as the number of variables grows.
We don't yet smoothly interpolate between the maps in the shader; we just switch the maps outright. Interpolation is coming soon. But in screenshots you can't see changing conditions anyway, so it's time for some screenshots.
First is the house with the door closed, then with the door open. After that comes the sculpture room, with two light sources toggled in various ways (see the captions on each picture). For now you'll have to forgive the light leaking in the corners and the shadow speckles on the walls; they are due to issues with the dynamic shadow system (which is not really related to what is being shown here) and those issues have yet to be resolved!
As explained by Jon in his previous post, we are using precomputed global illumination in The Witness, and one of my first tasks was to work on that system.
I have developed some interesting technology to compute automatic paramaterizations, to formulate the lighting computations in a way that can be easily mapped to the GPU, and to speed them up performing them at a lower frequency by using irradiance caching. None of these things are very cutting edge, but I run into some interesting problems that are usually overlooked in the literature and came up with some creative solutions that I think would be interesting to share. However, in retrospect, I think I also made some mistakes, but I hope that being honest about them will help me avoid them in the future.
In this first post I will describe the lightmap parameterization algorithm that I have implemented and in the next few posts I'll cover other details of our lighting system such as our approach to perform final gathering using hemicubes and our implementation of irradiance caching.
It seems like time to post some images from the in-progress precoputed lighting tech that Ignacio is working on. See here for a description of the basics behind what we are doing for lighting. The lightmaps are now 16-bit and these shots use a simple exponential tone mapper.
First, I've taken shots from 3 positions inside a house, with four different lighting settings. For all four settings, we are computing only the first lighting bounce. The parameters are:
(Click for full size).
Front Door:
32x32 adaptive
32x32
64x64
128x128
The Witness contains a mixture of indoor and outdoor scenes, but much of the game takes place outdoors with a very long view distance (you can see the entire island at once if you have a good vantage point). So I wanted to implement a shadow system that would work robustly, provide high visual quality, and allow the player to see everything at once. I have some experience with shadow systems of this type, but the last one I designed was for computers and graphics cards circa 2004, so I was interested to see how much more would be possible today.
We've implemented such a modern shadow map system for The Witness. In the process, we've made some improvements to shadow mapping algorithms beyond anything we've seen published, so we are going to detail the improvements here. Also, our shadow map system is still being improved, so I'll talk about what we have yet to try and why we think it's a good idea.
Before we get to those details, though, I'd like to establish some context so that the motivation for these design decisions is clearly explained.
The Literature
I have a somewhat cynical attitude toward graphics research literature: most of it describes techniques that don't generally work, but the authors of the papers do the best they can to "sell" the technique to you anyway (using cherry-picked examples, glossing over or completely ignoring failure cases that would be obvious to anyone who understands the algorithm, etc). As the reader, eventually you come to understand all the problems, but not after investing a lot of your time and energy (possibly months) implementing and understanding an algorithm that behaves so poorly that you never would have bothered if you had known the truth from the outset.
Today we are announcing a fund that provides very good terms for talented indie developers working on high-quality games. Our terms are much friendlier than what publishers offer. Our goal is to help indies become stronger while retaining their independence.
The past couple of years have been good for independent game developers. Through download services like Xbox Live Arcade, the PlayStation Network, WiiWare, and Steam, independent developers have found a very large audience. Some of us have been lucky enough to develop hit indie games that were very financially successful.
Braid was one of those games. The success of Braid has allowed me to undertake more-ambitious projects like The Witness. At the same time, I felt that I wanted to do something with the profits that would help other indies with their own games. More recently, while talking to publishers about The Witness, I felt that the business climate around publishing and funding these smaller games had not caught up with reality: it's a model where the standard terms are tuned for budgets in the tens of millions of dollars. Because publishers want to stick to this model even for low-budget games, it was very hard for indie developers to get a fair deal.
It turns out that other successful indies felt the same way, so we have pooled our resources and launched this fund. We will be announcing further details soon. At the GDC, Ron Carmel will be giving a talk about the problems that exist in the current publishing model for indie-budget games.
We've had the timing of this announcement planned for a while, but it seems like some kind of strange synchronicity that we're revealing our existence just as all this trouble is happening at Infinity Ward. When you're a mainstream developer, and you've made one of the most successful and profitable games of all time, and then just a few months later your publisher and parent company is willing to so bald-facedly mutilate your company, well, what conclusions can be drawn from that? If publishers of that size are so megalomaniacal as to be incapable of seeing the importance of a developer's talent -- instead believing that the game's success is somehow due primarily to their brilliant marketing strategy or their CEO's charming personality -- then how will this ever change?
If Infinity Ward can't be treated with respect, then who can?
Independent developers can. That's one answer, at least. Indie Fund is here to help make that independent existence a reality for as many talented developers as we can.
Here's a link to the main Indie Fund site, with an email you can use to contact us.
You can now be notified of new blog postings via RSS, Twitter or Facebook. See the icons in the upper-right corner!
At the moment of writing this post, The Witness has no Twitter followers and no Facebook fans, so you could be the first!
For the past 15 years or so, graphics technology in games has been driven by shooters. Most shooters generate visual interest in their scenes by having lots of dynamic lights, with extreme use of bump mapping, and moving shadows, and particle effects.
For The Witness, I wanted to develop a graphical style that values simplicity. It would be suited to mellower environments, with both indoor and outdoor settings. Some kind of global illumination solution seemed like the right idea here. (Global illumination is when you simulate light bouncing around in a scene; the resulting look is usually much richer and subtler than the direct lighting that games usually do.)
Clearly, full real-time global illumination would be the most versatile solution. I investigated some licensable packages that provide this, such as Geomerics' SDK. However, these solutions will invariably use a lot of texture space, and consume a bunch of processing time, and they seem like overkill for this game (The Witness does not have many moving light sources, relative to other types of games).
So, some form of precomputed global illumination seemed like the right thing. 3D modeling packages have plugins to compute global illumination, but they are very difficult to interface with, and they could not even come close to handling a full game scene. The only thing that knows where all the objects in the world are at once is the game itself (and the in-game editor), so it seemed appropriate to develop our own in-game system for global illumination. It could have been radiosity, could have been something like Monte Carlo Path Tracing, but Charles Bloom suggested the very simple solution of just rendering the scene for every pixel in a lightmap, and that seemed like a good idea. With an approach like that, you don't have to do a bunch of monkeying around to make radiosity or ray tracing match the completely different algorithm that is used to render your realtime game scene; light transport is computed by that same algorithm, so it will automatically match unless you mess things up.
For several months, Ignacio Castaño has been working on this system. He is writing up a highly technical explanation of how the system works, which I think he'll be done with in a few days, but in the meantime, here is a lighter-weight overview.
Continue reading
In order to begin discussing the game, it seemed more appropriate to show some concept art, because the game is very visual.
Click for full-sized versions. The gallery seems to hang some versions of Google Chrome. Sorry about that. It works fine in Firefox and Internet Explorer.
These concepts (and many more) were all done by Eric Urquhart, who has been working on the game for some months now.