Lightmaps and Optimization

[BobimusPrime]

Know the limits of the average voter's computer. Great graphics, gameplay, plot, originality, or any other measure of judging does not matter if the voter can't play your game at a reasonable framerate. This means that putting in features like lightmaps is not an option for a competition like this because not all voters have hardware that will support multitexturing. Other features that won't work for a competition like this yet are lighting calculations that are accompanied by too many intersection tests and also maps that are genuine triangle meshes rather than a terrain with objects. Features like these are fun and look good but can mean death for a competition like this because every player counts. The developer needs to satisfy the tastes of every voter, not just the few who have good hardware. The mistake I made going into this competition was that I chose to write something that I would be impressed by. This does not work because if someone were to write a game that was really impressive and pushed the boundaries of modern hardware, not everyone could play the game and therefore that individual could not win a competition like this.

[reubert]

Know the limits of the average voter's computer......
Perhaps this would be more acurate as: "know the limits of the average gamers' computer."

It seems you may be resentful of the the competition, but if you exclude all but the highest range computers you are excluding much of your potential audience, and this applies equally to games meant to be sold. Shareware, Commercial and uDev developers need to take this into consideration.

I'm glad that you have learnt this from the competetion. I was lucky that I was developing on such a low end machine as this particular problem did not effect me, however my game does not look so good on high end machines.

A good balance would be to have both a low, and a high end machine, and to develop on the high, and test on the low, and then the high, however not everyone has this luxury..... maybe I will soon...:p

[David]

Just wanted to point out that from experience it is definitely possible to write a game with lightmaps and triangle mesh levels that runs at top speed on even an old g3, maybe what you learned is that you should optimize more :cool: Just fyi, objects on terrain *are* triangle meshes with lightmaps.
Perhaps someone should write an article explaining how to use fast collision detection and octrees or bsp trees.

Anyways, what I learned:
-Simpler games are usually more popular
-2d games are easier to write quickly than 3d games
-Reliable networking is *hard*
-Presentation and packaging are very important
-Find a big gap in the market, and fill it

[BobimusPrime]

David:

I would love to hear about some games from your experience that have lightmaps and triangle mesh levels that run at top speed on even an old G3. If my memory serves me correctly there really are no games with lightmaps and triangle mesh levels that run at top speed on even an old G3. I suppose if we look back to the original Unreal Tournament you could get it to run decently at low resolution. I'm not entirely sure if even with the lowest texture settings that game ever ran at top speed on an old G3. I remember getting Oni when I got my 400 MHz G4. That game never even ran *close* to top speed on my G4.

Perhaps you have written a game in your experience that uses lightmaps and triangle mesh levels and runs well on an old G3 that I haven't heard about. I would be very much impressed if you have done that.

The reason I was differentiating between objects on terrain and purely triangle meshes is that intersection tests between objects in the game and the level are much simpler in the case of objects on a terrain than in the case of a triangle mesh. For example, in a game where you have a terrain and a bunch of cubes stuck in the ground the intersection tests can be done between the cylinder (assuming your character is being represented by a cylinder) and the terrain and also between the cylinder and the various cubes that are stuck in the ground. In the case of a level being represented by a triangle mesh there need to be intersection tests between the cylinder and the triangles in the mesh. Calculating the distance from the edge of a triangle to the cylinder and also the direction of the force on the cylinder can become very taxing on the processor. Obviously the case with a terrain and objects will be much faster and simpler to implement but making indoor levels that look the way you want becomes very difficult. Also, the lighting calculations would have been *much* nicer if the levels were made up of a couple of boxes rather than 1000 triangles.

Side note:
Since when does an object on a terrain automatically have a lightmap?

[MattDiamond]

Bobimus: I think/hope it's okay to right a high-end game for the contest. Mine wasn't like yours, but it definitely pushed the hardware a bit (and was supposed to.) I think the problem is that people who are borderline or below spec will try to run the game, and won't necessarily try too hard to make it run well on their machine.

So here are 3 ideas for improvements that can be made right off the bat:

1) In-game graphics settings to make the game perform better. (I had this.)

2) Anything that can be done automatically, should be done for the player. So the game should switch resolutions down for the player and allow them to crank it up if they want. Also, the game could run a test of the system on startup and conservatively default the settings for the player. (I did neither of these, and it would have helped.)

3) Set hard limits. If the player isn't up to spec, tell them so nicely. They aren't going to read the readme or the webpage and say, hey I'm under spec.

Of course, having a scalable game that runs on a wide variety of hardware is best, but barring that, I think there are things we can do to avoid generating player ill-feeling.

[BobimusPrime]

Matt:

Yeah, I have to agree with those points you made. It would have been very smart to have an in-game settings screen. I didn't really feel like I had enough time to pull that off and in fact I'm not even sure if I could figure out how to change resolutions while the game is running :). I just went for the way David does his settings for Lugaru because I think it's a *really* smart way of doing it when the in-game menu is too much work. Unfortunately, the player needs to understand how the file works to be able to use it.

I hadn't really thought about having the settings changed automatically. That would be a good plan. One concern I still have is about whether the lightmaps stop the program in its tracks if the 3D accelerator doesn't support multitexturing or if there are a lot of other factors that all slow the program to a standstill on older computers. I would need to understand a lot more details about how the user's computer behaves to have the program automatically change itself.

[OneSadCookie]

All cards accelerated by Mac OS X support at least two textures, and multipass rendering is often faster than multitextured rendering anyway...

Quake III uses lightmaps and runs perfectly acceptably (20-40fps depending on settings) on a Rage 128. I know not everyone's a Carmack, but decent performance can be had ;)

[David]

And of course there's always Quake 1, I got something like 15 fps on my performa without a 3d card.
Anyways yeah a while back I made a 3d "polygon soup" engine with dynamic lightmaps that ran fine on my g3 400, http://wolfire.com/Rocket.jpg http://wolfire.com/Rifle.jpg

The objects (trees, rocks, cubes) in Lugaru are light-mapped triangle meshes; they just happen to be in relatively simple shapes because I haven't gotten around to making the house models and such yet. :cool: The cubes actually have a somewhat high polygon count just to test what the performance will be like once I add the final models. It's much harder to collide with a terrain *and* multiple triangle meshes, than with just one mesh.

So basically it sounds like you might just be sending the lightmaps down an inefficient path, like having a separate texture per polygon or something. Also it's relatively simple to make it render with multiple passes instead of multitexture; just render the whole scene as a vertex array with just the lightmap and then re-render it with blended textures, or vice versa.

You would also get get a massive performance increase if you add frustum and occlusion culling. It's also a good idea to use octrees or bsp trees with collision functions to speed that up.