Slashdot Mirror

← Back to Stories (view on slashdot.org)

Carmack's QuakeCon Keynote Detailed

Posted by ScuttleMonkey on from the more-than-just-games dept.

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."

8 of 309 comments (clear)

  1. Procedural textures by mnemonic_ · · Score: 5, Interesting

    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.

    1. Re:Procedural textures by MaestroSartori · · Score: 5, Interesting

      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)

      --
      Game dev and music blog
    2. Re:Procedural textures by MaestroSartori · · Score: 5, Interesting

      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.

      --
      Game dev and music blog
    3. Re:Procedural textures by MaestroSartori · · Score: 4, Interesting

      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...

      --
      Game dev and music blog
    4. Re:Procedural textures by captaineo · · Score: 3, Interesting

      I think Carmack's opposition to procedural textures is for practical, not technical reasons. Developing good-looking shaders requires math and programming skills that most artists do not have. You'd have to tie up a software developer to write the shaders (and possibly an artist too, if the developer doesn't have a good artistic "eye"). So from a manpower perspective, it makes more sense just to have a bunch of artists cranking out texture maps in Photoshop.

  2. physics is here to stay by canozmen · · Score: 4, Interesting

    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.

    1. Re:physics is here to stay by aarku · · Score: 4, Interesting

      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.

  3. Re:Dual-core CPU not that easy to take advantage o by robnauta · · Score: 5, Interesting
    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.