Carmack's QuakeCon Keynote Detailed

TheRaindog writes "In addition to announcing the Quake III source code's impending release, John Carmack's QuakeCon 2005 keynote also covered the programmer's thoughts on Microsoft and Sony's next-gen consoles, physics acceleration in games, and what he'd like to see from new graphics hardware."

Comments

Procedural textures

[mnemonic_]

I was a bit taken aback by Carmack's opposition to procedural textures. No, they can't do everything but they can be real timesavers when you need to add some overall realistic looking details. Things like dirt, "roughness" and stains can be done effectively using Brownian noise and the like, and you've got the infinite resolution, low-memory features of procedurally generated data. It's efficient and looks good, especially when I used it to create realistic terrain.

Of course procedural textures can never replace hand-painted detail, but layering on some infinite-resolution noise-detail onto a finite sized bitmap texture really brings materials to life.

Re:Procedural textures

[MaestroSartori]

The argument generally is, as far as I know, that it's overkill for the current generation of hardware. Rather than procedural noise generated realtime, a few pregenerated detail noise textures can do the job with a fraction of the gpu time. It's pretty hard to tell the difference with a decent artist doing the noise maps, really.

Maybe during the next-gen consoles' lifespan we'll start seeing more procedural stuff. It'll become more important as we start pushing more polys and going down the High Definition route, I think.

(I'm more interested in offline procedural content generation, personally - automatically generated cities, it's the way of the future! :D)

Re:Procedural textures

[MaestroSartori]

Nice shader example that I quite like:

Renderman water shader

There's plenty. Try watching any film with decent CG effects, it'll be full of procedural shaders which are fairly realistic.

See, the thing about shaders is they can be as realistic as you're willing to let them get. The problem is how long it takes to calculate them - realtime games use more shortcuts, hacks and estimates to get something that looks "good enough". Not just in shaders, either. That's why we don't do realtime raytraced games, instead we use lightmaps or whatever to approximate them.

Re:Procedural textures

[MaestroSartori]

Oh, that game :D

I should probably explain further. My approach would be to generate the basic street layouts, buildings, and maybe even internal floor & room layouts procedurally, say in a Maya/Max plugin. This would act as the basis for artists/designers to then tweak and adjust to produce something good, hopefully in a fraction of the time.

Using control maps (for population density, affluence, terrain, etc) it should be possible to have fairly fine control over how the city is generated. Add to that a decent set of rules to govern the generation, and a big stock library textures/shaders to give a nice looking generic output, that should give a decent start point.

I know some of the guys who worked on GTA3/VC/SA, and one of their big problems was generating the sheer amount of content to make these large play areas. Starting with a pre-populated one and using it as a base might let them concentrate on making it good...

physics is here to stay

[canozmen]

Although Mr.Carmack says physics in game engines isn't easily scalable for level of detail, there is ongoing research about this producing good results. I remember a video from last years SIGGRAPH that had hundreds of plastic chairs falling from the sky, and bouncing realistically. The important part was it employed a level-of-detail hierarchy for interacting parts (i.e. an object doesn't have much physical detail if you don't touch it), but it will be some time before we can see such techniques in real time games.

Re:physics is here to stay

[aarku]

As a game developer, I'll say it'll come sooner than you think. Engines such as Unity will support Aegia's PPU when it comes out as it already uses the Novodex engine. From there it would take about 15 minutes to set up, tops. Expect some awesome things to come from little Indie developers.

Re:Dual-core CPU not that easy to take advantage o

[robnauta]

This is considerably more difficult than one would think. Games typically have to perform tasks in a particular order, for example (extremely simplified): get inputs, move player, move AI players, move other objects, check for collisions, update parameters, display the next frame, loop.

Quite where we add this 2nd thread is difficult. Everything must happen in the same order in order for things like collision detection to function correctly.

Not neccesarily. One big problem with games is that the typical order (beginscene/render/endscene/present) is implemented with a busy-wait loop in the present part. This is the part where all data has been sent to the graphics card and the driver waits in a loop until it gets a 'scene completed' message from the card. This is why games always run at 100% CPU.

Games that don't use threading well (only threading for network/input/sound) put stuff in the loop you describe. Draw a scene, the driver waits for an 'OK', then you update the player, update the AI characters, do collision, calculate all new positions and start drawing. Because the drawing takes eg. 10 ms per frame for 100 FPS developers limit the AI/collision part to run in something like 1 ms or else the frame rate starts dropping. So the real AT would be limited to say 10% of the CPU time.

For example the 'move AI' part could be a bunch of threads, calculating new positions based on direction, collision etc.

Right now games like DOOM3 typically only display a few NPC's at the same time because of the timing problem. If the move AI thread can just keep running on the second CPU while the first CPU waits within the driver a game could support a few 100 enemies on-screen.

Strategy games with complicated pathfinding with hundreds of units on-screen like Warcraft 3 or Age of Mythology would profit enormously, if programmed for multithreading.