… and the web site is updated. See it here: http://indie-fund.com/
Earlier this year, some friends and I, all successful independent game developers, put together the Indie Fund in order to help support newer folks with good ideas. All the hoops involved in setting up such an organization have been passed through, and we are now open for general submissions. If you are an independent developer who needs money for a project-in-progress, go check out the Apply page to see what kinds of games we are looking for.
Thanks, and good luck!
The addition of the recently-discussed terrain editing code means that we can start giving the island more shape and character, in a natural way. This is early yet…
In The Witness we decided that it’s a good idea to have a heightfield terrain making up the bulk of the island surface. The advantages of this are in rendering performance and in ease of texturing (it is relatively easy, with one continuously-parameterized terrain block, to get rid of seams; if your terrain is a bunch of otherwise-unrelated meshes, then what do you do?) Read the full article »
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.
Read the full article »
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.
Read the full article »
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:
- 32×32 cube maps, adaptive sampling, quality = 0.5. Time to compute: 197 seconds.
- 32×32 cube maps, non-adaptive sampling. Time to compute: 648 seconds.
- 64×64 cube maps, non-adaptive sampling. Time to compute: 738 seconds.
- 128×128 cube maps, non-adaptive sampling. Time to compute: 1570 seconds.
(Click for full size).
Front Door:
32×32 adaptive
32×32
64×64
128×128
Read the full article »
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.
Read the full article »
Subscribe
