Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Carmack Speaks On Ray Tracing, Future id Engines

Posted by Zonk on Wed Mar 12, 2008 03:03 PM
from the how-can-you-not-listen-to-the-carmack dept.
Vigile writes "As a matter of principle, when legendary game programmer John Carmack speaks, the entire industry listens. In a recent interview he comments on a multitude of topics starting with information about Intel, their ray tracing research and upcoming Larrabee GPU. Carmack seems to think that Intel's direction using traditional ray tracing methods is not going to work and instead theorizes that using ray casting to traverse a new data structure he is developing is the best course of action. The 'sparse voxel octree' that Carmack discusses would allow for 'unique geometry down to the equivalent of the texel across everything.' He goes on to discuss other topics like the hardware necessary to efficiently process his new data structure, translation to consoles, multi-GPU PC gaming and even the world of hardware physics."
+ -
story

Related Stories

[+] Technology: Ray Tracing for Gaming Explored 266 comments
Vigile brings us a follow-up to a discussion we had recently about efforts to make ray tracing a reality for video games. Daniel Pohl, a research scientist at Intel, takes us through the nuts and bolts of how ray tracing works, and he talks about how games such as Portal can benefit from this technology. Pohl also touches on the difficulty in mixing ray tracing with current methods of rendering. Quoting: "How will ray tracing for games hit the market? Many people expect it to be a smooth transition - raster only to raster plus ray tracing combined, transitioning to completely ray traced eventually. They think that in the early stages, most of the image would be still rasterized and ray tracing would be used sparingly, only in some small areas such as on a reflecting sphere. It is a nice thought and reflects what has happened so far in the development of graphics cards. The only problem is: Technically it makes no sense."
[+] Mobile: Intel Researchers Consider Ray-Tracing for Mobile Devices 120 comments
An anonymous reader points out an Intel blog discussing the feasibility of Ray-Tracing on mobile hardware. The required processing power is reduced enough by the lower resolution on these devices that they could realistically run Ray-Traced games. We've discussed the basics of Ray-Tracing in the past. Quoting: "Moore's Law works in favor of Ray-Tracing, because it assures us that computers will get faster - much faster - while monitor resolutions will grow at a much slower pace. As computational capabilities outgrow computational requirements, the quality of rendering Ray-Tracing in real time will improve, and developers will have an opportunity to do more than ever before. We believe that with Ray-Tracing, developers will have an opportunity to deliver more content in less time, because when you render things in a physically correct environment, you can achieve high levels of quality very quickly, and with an engine that is scalable from the Ultra-Mobile to the Ultra-Powerful, Ray-Tracing may become a very popular technology in the upcoming years."
[+] Technology: NVIDIA Doubts Ray Tracing Is the Future of Games 198 comments
SizeWise writes "After Intel's prominent work in ray tracing in the both the desktop and mobile spaces, many gamers might be thinking that the move to ray-tracing engines is inevitable. NVIDIA's Chief Scientist, Dr. David Kirk, thinks otherwise as revealed in this interview on rasterization and ray tracing. Kirk counters many of Intel's claims of ray tracing's superiority, such as the inherent benefit to polygon complexity, while pointing out areas where ray-tracing engines would falter, such as basic antialiasing. The interview concludes with discussions on mixing the two rendering technologies and whether NVIDIA hardware can efficiently handle ray tracing calculations as well."
[+] Crytek Bashes Intel's Ray Tracing Plans 151 comments
Vigile writes "Despite all good intentions, Intel continues to see a lot of its work on ray tracing countered not only by their competition, as you'd expect, but also by the very developers that Intel is going to depend on for success in the gaming market. The first major developer to speak on the Intel Larrabee and ray tracing debate was id Software's John Carmack, who basically said that Intel's current plans weren't likely to be implemented soon or ever. This time Cevat Yerli, one of the Crytek developers responsible for the graphically impressive titles Far Cry and Crysis, sees at least 3-5 more years of pure rasterization technology before moving to a hybrid rendering compromise. Intel has previously eschewed the idea of mixed rendering, but with more and more developers chiming in for it, it's likely where gaming will move."
[+] Hardware: Larrabee Team Is Focused On Rasterization 87 comments
Vigile writes "Tom Forsyth, a well respected developer inside Intel's Larrabee project, has spoken to dispel rumors that the Larrabee architecture is ignoring rasterization, and in fact claims that the new GPU will perform very well with current DirectX and OpenGL titles. The recent debate between rasterization and ray tracing in the world of PC games has really been culminating around the pending arrival of Intel's discrete Larrabee GPU technology. Game industry luminaries like John Carmack, Tim Sweeney and Cevat Yerli have chimed in on the discussion saying that ray tracing being accepted as the primary rendering method for games is unlikely in the next five years."
[+] Students Evaluate Ray Tracing From Developers' Side 84 comments
Vigile writes "Much has been said about ray tracing for gaming in recent weeks: luminaries like John Carmack, Cevat Yerli and NVIDIA's David Kirk have already placed their flags in the ground but what about developers that have actually worked on fully ray traced games? PC Perspective discusses the benefits and problems in art creation, programming and design on a ray traced game engine with a group of students working on two separate projects. These are not AAA-class titles but they do offer some great insights for anyone considering the ray tracing and rasterization debate."
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • by Ferzerp (83619) on Wednesday March 12 2008, @03:07PM (#22732056)
    It as if hundreds of ray tracing fanboys cried out at once, and were silenced.
    • by AmaDaden (794446) on Wednesday March 12 2008, @03:09PM (#22732082)
      Ray Tracing has a place. New high speed FPS games are not it.
        • by luther2.1k (61950) on Wednesday March 12 2008, @03:59PM (#22732634) Homepage
          Bog standard ray tracing, which is what intel are harping on about at the moment isn't the be all and end all of global illumination algorithms, as many people who get all misty eyed about the technique would have you believe. It's terrible for diffuse interactions for one thing. Photon mapping [wikipedia.org] is a more realistic technique which simulates light more accurately.

          Tim.
            • by Goaway (82658) on Wednesday March 12 2008, @04:40PM (#22733042) Homepage
              "Ray tracing" traditionally means specifically tracing rays from the eye out into the scene. Other methods are usually referred to by different names.

              And even so, while tracing either photons or eye rays may be the most feasible method at the moment, it is by no mean the only way to solve the rendering equation, nor any kind of theoretical best.
                • by kb (43460) on Wednesday March 12 2008, @06:46PM (#22734208) Homepage Journal
                  As far is I've understood it he isn't exactly using the octree for LOD but for storing all voxel data in s parse (there we have it ;) manner. If you only have one "layer" of voxels at whatever resolution defining eg. only the surface of things, most nodes of the octree will remain empty, and so you can reduce the data set to storing only what's necessary for rendering instead of having to store a full-resolution 3D representation of your space. Of course this leans happily towards a LOD system, as storing the data in different resolutions aka mip-mapping the geometry and then accessing the right detail level would essentially be for free if you do it right. In the end it's a promising approach with of course many details to be sorted out - there's still a lot of data to be stored per-voxel (texture coordinates, normals, basically everything that now goes into a vertex) if you want the full feature set like eg. lighting and such. But given dedicated hardware and combined with his mega texture stuff (which is basically only glorified unique UV mapping, perhaps somewhat generalized and with a good resource management system behind it) this could be pretty cool.
        • by Doogie5526 (737968) on Wednesday March 12 2008, @04:27PM (#22732944) Homepage

          It's the most realistic possible way of rendering
          It only provides realistic rendering of reflections, refractions, and shadows. There are still many more properties of light that take different, also intensive algorithms reproduce like; color bleeding, caustics, sub-surface scattering, depth of field.

          I'm sure there's some market for these things, but there's so much more involved even after these algorithms are implemented. Now you have to add settings (or additional texture maps), for each object (or light). As soon add something with live reflections, you can't even throw away what's not on screen (or facing away from camera). So your memory requirements jump just because of that. There's many things that have to come in to place for these technologies are adopted widely. A lot of these algorithms have been around for over 25 years already and are just seeing wide adoption in feature films (most would be surprised at how much is faked, even today).

          I hope there's a class of games that don't use these things or take 1 or 2 of these things and use them in innovative ways. While I like the WW2 (or futuristic) FPS games, I feel all that dev time is better spent on innovative game play.

          Sorry that the brief reply I planned turned in to a rant.
          • Re: (Score:3, Insightful)

            I feel all that dev time is better spent on innovative game play.

            Innovation does not require much dev time, it requires one bright mind to come up with a good idea and many managers that won't mind spending money on an unproven concept.
            • Re: (Score:3, Insightful)

              and many managers that won't mind spending money on an unproven concept.

              as long as it's got a skateboarding turtle it's sure to be a winner.
          • by DragonWriter (970822) on Wednesday March 12 2008, @05:39PM (#22733602)

            It only provides realistic rendering of reflections, refractions, and shadows.


            Everything light does is a combination of reflections and refractions (shadows are an artifact of those).

            So, yeah, what you are in effect saying is that raytracing only provides realistic rendering of things that light actually does.

            There are still many more properties of light that take different, also intensive algorithms reproduce like; color bleeding, caustics, sub-surface scattering, depth of field.


            Color bleeding and caustics are effects of reflection, subsurface scattering is reflection and refraction, depth of field is refraction (through a lens between the viewpoint and the image). Now, its true, that there are shortcuts that provide tolerable approximations of those effects faster than actually tracing rays in most cases, and that even static raytracers often prefer those to what would be necessary to do those effects through raytracing alone. Its also true that some real effects, to do well with raytracing, would require shooting separate rays for different wavelengths of light, which while conceptually possible (and I think some very specialized systems have been made which do this), is probably utterly impractical for realtime systems for the forseeable future (this is a lot bigger load increase than anti-aliasing would be.)

            But as for realism (but not necessarily practicality, especially in a realtime setting), I think raytracing still, ultimately, wins on all of those.

            • by ultranova (717540) on Wednesday March 12 2008, @06:12PM (#22733918)

              Everything light does is a combination of reflections and refractions (shadows are an artifact of those).

              Except the double-slit experiment. It's based on the fact that light has wavefront qualities, while ray tracing treats it as particles.

              I also strongly doubt that the discreet ray approach will ever produce very good global illumination, since the number of rays bouncing between surfaces quickly grows towards infinite as the desired accuracy grows.

              You'd need to do "wavefront racing" to fix these, and I for one have no idea how to do this - solve the quantum field equations for each particle in the scene after inventing the Grand Unified Theory ?-)

              • by DragonWriter (970822) on Wednesday March 12 2008, @06:35PM (#22734108)

                Except the double-slit experiment. It's based on the fact that light has wavefront qualities, while ray tracing treats it as particles.


                Good point.

                I also strongly doubt that the discreet ray approach will ever produce very good global illumination, since the number of rays bouncing between surfaces quickly grows towards infinite as the desired accuracy grows.


                Well, yeah, the "raytracing is ideally photorealistic" argument does rely (even ignoring the wave effects that raytracing misses), essentially, on unlimited processing power and memory, and isn't necessarily applicable in any particular practical domain. My reference to shortcut techniques to directly model particular phenomena instead of tracing all the necessary rays being a feature of even static raytracing package, and to many of the idealized advantages of raytracing not being realized in practice was based on that.

                You'd need to do "wavefront racing" to fix these, and I for one have no idea how to do this - solve the quantum field equations for each particle in the scene after inventing the Grand Unified Theory ?-)


                That sounds about right, probably using a quantum computer "graphics card" (QGPU?).
            • by Swampash (1131503) on Wednesday March 12 2008, @08:38PM (#22734970)
              depth of field is refraction (through a lens between the viewpoint and the image)

              No it's not. Depth of field is a function of aperture, and has nothing to do with either lenses or refraction.
        • by flyingsquid (813711) on Wednesday March 12 2008, @05:05PM (#22733244)
          It's the most realistic possible way of rendering, so when computers get fast enough we'll be able to everything with ray tracing.

          When that happens, will it also become possible to wield a flashlight and a shotgun at the same time? Or is there some kind of fundamental law against that, like how you can't know the position and velocity of a particle at the same time?

        • Re: (Score:3, Informative)

          It's the most realistic possible way of rendering,

          No. For starters, the rays are "sparse", that is, there is space between two parallel rays which goes unexplored; furthermore, each beam either hits or doesn't hit any given object, leading to aliasing (jagged edges). A much better solution would be racing a cone from each pixel, with no space between them; however, the mathemathics of calulating reflections when the cone hits something would be horrible.

          Another problem is with global illumination. Nor

  • by davidwr (791652) on Wednesday March 12 2008, @03:10PM (#22732096) Homepage Journal
    This just came through the time vortex, dated 3 weeks from yesterday:

    Voxel? Texel? Just make my pink pony look nice and pretty.
  • by Zymergy (803632) * on Wednesday March 12 2008, @03:16PM (#22732182)
    ...*MORE SHADES OF BLACK*??!!
  • by Telvin_3d (855514) on Wednesday March 12 2008, @03:23PM (#22732254)
    My biggest concern with where he is going with this is that it does not sound like it will play very nice with physics. In page two he makes some comments on how characters and other animated elements will still likely be done with more traditional methods and then mixed with this for the static objects like the world.

    The problem with this is that we are moving more and more towards interactive environments where everything from the ground to the flowerpots are breakable, bendable or movable. It doesn't sound like this new system will play very nice with physics intensive or highly interactive environments. Now, i could be completely wrong. He doesn't address the point directly. But it is still a point for concern.
    • Re: (Score:3, Interesting)

      The problem with this is that we are moving more and more towards interactive environments where everything from the ground to the flowerpots are breakable, bendable or movable. It doesn't sound like this new system will play very nice with physics intensive or highly interactive environments. Now, i could be completely wrong. He doesn't address the point directly. But it is still a point for concern.

      I agree completely. When Carmack can implement even a low-polygon all-things-dynamic wonder like Katamari Damashii using his quartile duplex hectotree algorithm, I'll be impressed. The time of precompiling 99% of the game into a static optimized traversal graph is over. Now you've got a bag of loose models (many of which morph), the sum of which fills the screen.

      • by Chandon Seldon (43083) on Wednesday March 12 2008, @04:12PM (#22732776) Homepage

        Yea. Because interactivity trumps photorealism for every single possible type of game. Oh wait, that's false.

        You sound like the people who said that StarCraft was crap because sprites were outdated junk and every good game (like Total Annihilation) had already moved to 3D. Different engineers will make different design choices for different applications, and there is no total order of correctness among a single class of design choice.

    • by ghostlibrary (450718) on Wednesday March 12 2008, @03:59PM (#22732626) Homepage Journal
      Having developed octtree voxel methods for astrophysics sims (crashing galaxies into one another), I suggest they are ideal for physics. The idea of a tree is you group things to maintain a certain amount of accuracy. For example, if you have 3 items interacting just with gravity:

      A (longdistancetypedheretoavoidlamenessfilter) B .. C

      A non-tree method would just calculate all the interactions: A-B, A-C, B-C. But you can group B+C together when calculating their interaction with A because, at that distance, the result for (B+C)-A is the same as the result for B-A + C-A. Then the interaction between B & C must be calculated separately. So you've (even in this tiny example) reduced your calculation from 3 to 2.

      And, of course, all the 'voxels' between A & B/C that are empty need not be considered at all. If you'd set it up as an NxNxN voxel cube, you'd be wasting time on calculating empty voxels between the occupied items.

      So if you want realistic interactive environments, sparse voxel octtrees are the way to go-- you pump all the calculation time into the parts where it matters, and let the other stuff be 'smoothed' when such smoothing is indistinguishable from rounding error.

      Typically, you can traverse the tree for a given error percentage, e.g. 'walk the tree and do interactions preserving 99% energy conservation' or similar. So your have predictable error, as well, despite being able to use arbitrary geometries and spacing for your elements.
        • by ghostlibrary (450718) on Thursday March 13 2008, @06:54AM (#22737552) Homepage Journal
          > Do you have any publications you can point me towards?

          Hmm... well, I write here under a pseudonym so it's hard to look up my work. But you can look up 'TreeSPH' in google for some good references to lots of astrophysical implementation. The 'Tree' part is obviously the voxel octtrees, while the 'SPH' means they added hydrodynamics to it by making 'blobs' that have a variable kernel size for smoothing over neighbors.

          Which basically means, for hydrodynamics, if it's uniform density you can use a single large 'blob' to represent it, while in an area where the density is rapidly changing you go to smaller 'blobs' because you need more computation. You then use a kernel function, which basically means how much you smooth over neighbors to get a good distribution. With this, you spend all your hydrodynamic computation time on the rapidly changing, shocky, or active stuff. So it's another example of how to decompose a problem they way Carmack seems to be suggesting.

          Funny thing is, in astrophysics, this stuff came out in the late 80s/early 90s, and astrophysics usually lags behind physics by a half a decade, which lags behind pure math by a decade. I think the challenge for getting into gaming is converting codes intended for cluster/supercomputer massive calculations into the realm of fast PC gaming.

          Tree codes are already heavily used in computer gaming (browsing through 'Computer Developer' magazine shows they are used for dynamic line-of-sight work a lot), so none of what Carmack suggests is cutting edge comp sci in theory. In fact, he used binary space partitioning with Doom, which is in the same field. Much as with Doom etc, the key is can he come up with a fast implementation (or even approximation). I think that's his real talent-- taking existing methods and concepts and figuring out a 'real world' implementation that's fast enough for gaming. He's a programming engineer of no small talent.
    • I have argued many times, and will no doubt do so for many years hence, that there won't be one unique solution to this, that the quality possible using a full genuine ray-tracing and radiocity solution (ie: not just using shaders or other simple rendering techniques) conflicts with the requirements of fast action. The only sensible (IMAO) is to use a combination of methods, depending on rate of change. Where rate of change is below a critical threshold, then use full-blown ray-tracing (or perhaps cone-trac
  • by goatpunch (668594) on Wednesday March 12 2008, @04:01PM (#22732654)
    In other news, all games will now consist of reflective spheres moving around on checkerboards...
  • by Applekid (993327) on Wednesday March 12 2008, @04:08PM (#22732732)

    It won't be right, but it will look cool, and that's all that really matters when you're looking at something like that. We are not doing light transport simulation here, we are doing something that is supposed to look good.
    I'm the sort of guy that watches a movie and notices the compression artifacts in black, listens to music and hears mushy cymbals. I walk by a screen and notice dead pixels and that the input source isn't in the LCD's native resolution.

    Yet, when I play a game, I'll admit, I'm not playing glaring attention to these faults. The last thing that really bothered me in games was 16-bit color banding and I haven't seen any of that in, oh, like 3 or 4 years.

    The gamer side of me agrees with Carmack on things looking cool who cares if it's wrong, the geek side of me is angry and demands it be pixel-accurate.
    • Re:So, (Score:5, Funny)

      by BigJClark (1226554) on Wednesday March 12 2008, @03:13PM (#22732140)

      Don't feel bad, he has probably never heard of you either.
        • Re:So, (Score:5, Informative)

          by nschubach (922175) on Wednesday March 12 2008, @03:54PM (#22732558) Journal
          John Carmack == Commander Keen == id Software == Doom = Wolfenstein == Quake == ??

          You've never heard of any of those? the guys you mention might not even be in gaming if it weren't for Carmack and John Romero.
            • Re:So, (Score:5, Informative)

              by nschubach (922175) on Wednesday March 12 2008, @04:11PM (#22732764) Journal
              Funny. It's just freaking amazing that someone would even stoop so low as to mention Gabe Newell and not know Carmack. Hell, the original Half-Life is written on the Quake engine written by Carmack.
            • Re:So, (Score:5, Insightful)

              by omeomi (675045) on Wednesday March 12 2008, @04:41PM (#22733046) Homepage
              Now if John Carmack is as legendary as /. is making him out to be, why isn't it John Carmack's Quake/Doom?

              George Washington is pretty legendary, but we don't have a George Washington's America, do we? The name is irrelevant. How could the guy who basically invented the First Person Shooter not be legendary? When it first came out, the original Wolfenstein was the most highly optimized game I'd ever played. I still remember thinking it wouldn't run on my slow-ass computer, and being blown away when it ran fast as can be.
              • Re: (Score:3, Informative)

                Interestingly, at least with American McGee, he gave an interview with GFW podcast, where he said that it was the publisher who wanted to put his name on the box, to create brand recognition, not the other way around.
    • Re:Stunning! (Score:5, Insightful)

      by Bob of Dole (453013) on Wednesday March 12 2008, @03:17PM (#22732196) Journal
      A developer who coded the engines that nearly all PC first person shooters have run on. That's obviously not enough to accept his words without hesitation, but obviously the person knows more about high-performance 3D rendering than a random coder like myself.
    • Re:Stunning! (Score:5, Insightful)

      by Falesh (1000255) on Wednesday March 12 2008, @03:27PM (#22732302) Homepage
      Why not analyse his argument and judge it on it's merits rather then throw it out simply because he is working on an idea of his own?
      • Re:Stunning! (Score:5, Insightful)

        by DragonWriter (970822) on Wednesday March 12 2008, @04:04PM (#22732690)

        Why not analyse his argument and judge it on it's merits rather then throw it out simply because he is working on an idea of his own?


        Commenting on the fact that it is unsurprising that someone working on a different technique favors that technique over raytracing is not throwing anything out.

        Its not a comment either way on the merits.

        Were I to comment on the merits, I would point out that his position is both fairly obviously correct (in that sparse voxel octrees or something quite like them is almost beyond question the key to raytracing that's useful for reasonable quality in realtime), and entirely incorrect in his characterization of what everyone else is pushing: he pretends that "everyone" is pushing the most naive, brute force approach to raytracing, in which you don't use any kind of bounding volume structure and just do intersection tests against triangles. I've seen literally no recommendations that do that: almost all involve some form of bounding volume heirarchy, and sparse voxel octrees are just one instance of that (perhaps a fairly ideal one, and that's great). (Also, raytracing isn't limited to triangles, although most performance comparisons of raytracing to raster-based rendering methods use models constructed from triangles because it allows you to compare same-model performance of the different mechanisms; raytracing engines, however, don't generally need to decomposed curved objects into triangle-based approximations to render them in the first place, although this can sometimes be more efficient.)

        TFS further misleads by suggesting that Carmack is proposing an alternative to raytracing, when really what he is proposing is a particular approach to raytracing, and, particularly, a particular approach in one well-known problem area in raytracing to which there are currently a whole array of approaches. And his focus on what he wants to get out of raytracing is a little different. But, essentially, his piece, while there are some potentially good criticisms on some particular aspects of and arguments for Intel's specific approach to raytrace, is in accord with (not opposed to) the general idea that raytracing techniques are going to be increasingly important in gaming.

        Is that enough "on the merits" for you?
        • Re:Stunning! (Score:5, Interesting)

          by John Carmack (101025) on Wednesday March 12 2008, @05:52PM (#22733726)

          Give me a little credit here. I am not suggesting that everyone blindly intersects rays with a huge list of triangles. That would be absurd, and I assumed everyone understood that. What you might have missed is that I'm not proposing a sparse voxel octree as some form of bounding hierarchy to reduce intersection tests against triangles, I am proposing that it REPLACE hierarchies of triangles or other primitives for some data sets, and this brings about significant improvements (data size) that you wouldn't have with even infinitely fast conventional ray tracing. I'm also not trying to say that this is some novel brainstorm of mine, but I have some practical experience with the direction, and I think it has promise.

          One of my major points is that this is all still theoretical. I don't know what is going to be the right architecture for next gen systems. Neither do you, or Intel, Nvidia, Microsoft, Sony, or Nintendo. If I had to place a bet, it is that rasterization will still be dominant, but it is a Good Thing to have lots of people doing research into various alternatives. All the players have their own agendas, but we will all know the big win when we see it.

          John Carmack
          • by Anonymous Coward on Wednesday March 12 2008, @06:06PM (#22733868)
            RTFA, you didn't understand what the guy who wrote the article was saying.
            • by John Carmack (101025) on Thursday March 13 2008, @11:22AM (#22740222)
              In our current generation codebase we have moved to completely separate representations for rendering and physics, and I expect that to continue in the future. The requirements are different enough to merit different internal storage.

              John Carmack
            • by John Carmack (101025) on Thursday March 13 2008, @11:45AM (#22740492)
              Tracing into an SVO structure can be done with almost a Bresenham algorithm, and when you reach whatever depth of descent you want (a critical factor, you aren't going all the way to final detail on every trace), you pop out whatever data is stored there (probably some vector quantized BRDF sort of thingy) and run a "fragment program" on it.

              The data sets for a game world represented like this would be massive, but it is intrinsically well suited for streaming, even over the internet, which may well be the dominant media distribution channel in the timeframe we are looking at.

              John Carmack
        • by Fescen9 (1030850) on Wednesday March 12 2008, @06:49PM (#22734242)
          Dude, you got pwned by JOHN CARMACK!
    • Re:Right... (Score:5, Insightful)

      by Jerf (17166) on Wednesday March 12 2008, @03:51PM (#22732536) Journal
      Yeah!

      Plusses:
      • One of the primary fathers of the FPS genre.
      • Wolfenstien 3D
      • Doom
      • Quake 1
      • Quake 2
      • Quake 3
      • Endless articles and commentary on the field
      • A shitload of stuff I'm forgetting
      Minusses:
      • "Thought multiplicative lighting was the way to go, rather than dealing with the performance hit of additive lighting in Quake 3."
      Conclusion: Carmack sucks!

      I mean, seriously, what's your point? The man's not actually a God so we shouldn't listen to him? Is there somebody more experienced I should prefer to listen to? Is "n3tcat" the handle for somebody with thirty years experience in first-person shooter engines or something?
      • Uhhhh... (Score:4, Funny)

        by jd (1658) <imipak@y3.14ahoo.com minus pi> on Wednesday March 12 2008, @04:00PM (#22732638) Homepage Journal
        What do you mean he's not God? Isn't that heresy? (Or was that written by someone else?)
      • The Church of Carmack condemns your post, a profuse apology and confession is now your only hope to salvation. Belief in ray casting will put you down the road to truth and righteousness! But seriously, Carmack created the FPS genre and is still a leader, which makes him one of the most experienced in his field, so, you know, that kind of helps in creating a "god-like" status, or if your still skeptical, a "mini-god" status. okay, how is "almost-god" sound? At least put the word "God" and "Carmack" in
      • Re:Right... (Score:5, Insightful)

        by blahplusplus (757119) on Wednesday March 12 2008, @09:11PM (#22735164)
        "I mean, seriously, what's your point? The man's not actually a God so we shouldn't listen to him? Is there somebody more experienced I should prefer to listen to? Is "n3tcat" the handle for somebody with thirty years experience in first-person shooter engines or something?"

        Many people with years of experience still make god awful mistakes. Experience can only take you so far considering that experience is also the reason why companies stagnate because people get locked into a certain way of looking at things.
    • Re:Right... (Score:5, Interesting)

      by DeltaSigma (583342) <onu.public @ g m a i l .com> on Wednesday March 12 2008, @04:29PM (#22732964) Journal
      I doubt any mod team was hit harder by that fact than mine. Yet, I can't fault him for the decision. It's unlikely anyone on my team did/does. By supporting almost every hardware graphics accelerator on the market at the time, Quake 3 almost single-handedly fostered the feedback loop that drove mainstream adoption of dedicated graphics accelerators.

      You sound like someone that's had the same thought every serious modder/engine-licensee has ever had; "if they could have just included/modified this ONE feature, my game would be feasible/better."

      Yet you haven't encountered that phrase enough times to appreciate the fact that engine developers have to draw a performance line somewhere. Your desired feature just happened to be on the wrong side of that line.

      Further, engine-developers of John Carmack's caliber would (I promise you this) love to have supported every feature you've ever thought of (and more). John Carmack's always been on the cutting edge, usually refining it. He sometimes makes decisions that are a matter of taste that you can feel free to disagree with him on, but that particular feature wasn't one of them.
    • by rucs_hack (784150) on Wednesday March 12 2008, @04:04PM (#22732688)
      Redo quake? Why?

      I guess you haven't seen ezquake (best obtained in the nquake package). A faster, more frantic FPS game you will not find. It's also been substantially improved graphically, so there are many more colours about the place.

      Any reworking of quake 1 would be badly received by the old school (by this I mean most people who still play it). New people wouldn't see the need, since most of them have grown up on a different fps style. Why revisit quake 1?

      Personally I love the game, and play it often. If I have one criticism its that most of the servers are populated by people who are so good at the game, after playing for so long, that just living long enough to pick up a gun and kill someone can be a real challenge.

    • Wow, these articles have all been so informative. I could not possibly have predicted those outcomes.

      Meanwhile the rest of us have been enjoying these articles immensely because we get to obtain some insight about what each of the major players are thinking in regards to Real-Time Raytracing. The great thing about obtaining insight from others is that you can then use your newfound insight to come to your own conclusions.

      If you're simply looking for a consensus from the industry, don't expect one for a long while. The concept won't entirely be accepted until someone goes out there and proves it out. Just like high-quality 3D graphics were thought to be too slow on the PC. Until game creators proved out a few different methods to make them usable, that is. (Starting with Wing Commander, moving to Wolf-3D, Doom, Duke 3D, and eventually Quake. After that, the industry said, "Welp, we better make some hardware for this." And thus 3DFX was born. ;-))
    • Re: (Score:3, Informative)

      Carmack is not saying the industry won't go to ray tracing, but rather that the industry won't abandon rasterization because each has strengths and weaknesses.

      He believes the same thing I do - a hybrid approach is most likely, at least in the short term. A sparse voxel octtree (a voxel is a 3d pixel and an octtree is a uniform 3d structure to hold the voxels - they are sparse because most are empty [hold air]) and would work well for ray tracing because it sounds like you'd need to cast rays to find the vo
    • by pavon (30274) on Wednesday March 12 2008, @11:36PM (#22736086)
      As John mentioned in his post here, these are not new ideas. I remember playing around with raytracing/casting of sparse-octree voxels for fun almost ten years ago, and as a quick
      search of the literature [acm.org] shows, I was quite late to the game :) What is cool is that he thinks that the gaming world is ready for them, and that he is going to try and push the hardware folks to make it happen.

      One of the most fundamental properties of voxmaps is that the geometry and texture are defined hand-in-hand - they have the same resolution, and every point in the geometry has a unique texture. If you want this, then there are data structures like sparse octrees that store the data quite efficiently.

      However, decoupling the geometry and texture opens the door for all sorts of tricks usefull in limited memory situations. It was these tricks that made realtime polygon graphics possible in the past. Things like low resolution polygons with high resolution texture maps, tiled/reused texture maps and layered decals, are all ways to cut down on the amount of data needed while still creating a decent looking scene.

      However, as the amount of memory increases, these tricks are less necessary and less desirable. Artists want to be able to paint any part of a scene any way they want - and this is exactly what John has done in id Tech 5, their newest engine. After doing so he did some experimentation and found that storing this data in a sparse octree is even more memory efficient than the way he is doing it now, using pixmaps and polygons. If this approach were to work, artists would then have the same freedom in editing the geometry of the world as they do now with textures - the entire world would have geometry at the resolution of current texture maps with zero additional memory costs. That would be awesome.

      For this to work though, you need to be able to render the data efficiently. Raycasting of sparse octrees is one of those embarrassingly parallel problems, and thus hardware acceleration for it is relatively easy. But they don't exist due to lack of market, and unfortunately graphics cards are not well suited for this, IIRC because GPUs mostly accelerate floating point calculations, while descending the sparse-octree uses a lot of integer bit-twiddling (I might be wrong about the reasons here). But with the memory-usage tradeoffs shifting in favor of voxmaps, GPU vendors looking to make their products better suited for general purpose High Performace Computing, and John Carmack pushing for it, this may be an idea whose time has come.