Slashdot Mirror


Crytek Bashes Intel's Ray Tracing Plans

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

7 of 151 comments (clear)

  1. Re:Ray-Tracing Extremely CPU Intensive by Yetihehe · · Score: 4, Informative

    Here it goes again. Try to rasterize on CPU. It will be similarly slow. On the other hand with good hardware (like raytracing on gpu (PDF), or on cell processor (PDF), or just on PS3 cluster) is ALREADY possible. If you could make custom accelerator for raytracing (PDF) gamers and graphicians would love it.

    --
    Extreme Programming - Redundant Array of Inexpensive Developers
  2. Re:Ray-Tracing Extremely CPU Intensive by jfim · · Score: 3, Informative

    It depends on the game. For example, the first releases of Quake 3 had different physics depending on your framerate, due to integer clamping of player positions. They fixed the issue in later patches by adding an option to force everyone to run at 125 Hz, but by default it is off.

    This allows a couple jumps that are not possible UNLESS you are running at 125 Hz, such as the megahealth jump on q3dm13.

    This guide has more information: http://ucguides.savagehelp.com/Quake3/FAQFPSJumps.html

  3. Re:Ray-Tracing Extremely CPU Intensive by irc.goatse.cx+troll · · Score: 4, Informative

    Since quake1, and everything dervived from it in some way.

    Yes its not a 'wise decision', but not all decisions can be made based on whats most logical..sometimes you need to cut corners based on what will work fastest or easiest.

    In quake your movespeed and your ability to move/accelerate in the air is based entirely on your fps. Some trick jumps can't be done without a certain framerate.

    In quake3 that changes more into your jump height, but the same end result -- Some jumps require certain fps to become possible.

    In any HL based game your ability to slide up a steep wall instead of slide down it is impacted by your fps (and also the servers framerate).

    In TFC hwguy assault cannon and a few other weapons would fire more often with higher fps.

    In Natural Selection(1.x) how quick your jetpack fuel replenishes is based on your fps. Enough FPS and you could fly forever.

    Theres more, but the tl;dr version: Any game that uses quake's "player.think()" system to do calculations will fire off more .think()s per second on clients with higher framerate.

    --
    Pain lasts, kid. Its how you know you're alive. Sometimes I think this growing up thing is just pain management-TheMaxx
  4. Re:So not an April fool then? by Molochi · · Score: 2, Informative

    ARP did the article "DX11 to support hardware accelleration of raytracing" (and it was an April Fools prank). However Intel is "serious" about hardware that does it... or at least serious about owning and promoting patents for the hardware.

    --
    "The Adobe Updater must update itself before it can check for updates. Would you like to update the Adobe Updater now?"
  5. Re:Well... duh! by Yvanhoe · · Score: 3, Informative

    Yes, you can do raytracing on polygons, but it kind of misses the point. For rendering polygons, Carmack is right, rasterization will probably always stay faster as long as triangles are bigger than 1 pixel.

    The point of raytracing is that instead of having a 100,000 polygons cloth animation to raster, you could have a smoother result with about 1000 control points on a mathematical surface.

    Today, game makers and modelers have the habit of breaking everything into triangles because of rasterization but the raytracing approach isn't limited to triangles; it can use any shape for which a collision with a ray can be computed. It is a very powerful approach but new tools have to be developed to use it to its full extent.

    --
    The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.
  6. Re:Ray-Tracing Extremely CPU Intensive by Laughing+Pigeon · · Score: 2, Informative

    Why would one want 30 framed per second? If I were to mention a number, I would either want at least ~72 frames per second (where the eye/brain would have a hard time discerning between individual frames) or at least match the sync of an ordinary LCD screen at 60 fps. That is not usefull at all. 30 frames per second suffice to make the eye see something as "moving" instead of taking small steps, what You describe as "where the eye/brain would have a hard time discerning between individual frames". The reason that one sees flickering on a crt is that the phosphor dots "cool down" after being hit by the electron beam, the dots have to be hit time after time. To prevent this from giving a flickering screen, the frequency by which the pixels are "activated" has to have a certain minimum value (for many people 72 Hz is enough)(and nobody truly needs more than 640 Hz ;-)). This has nothing to do with the brain discerning individual frames.
  7. Re:Ray-Tracing Extremely CPU Intensive by UnknownSoldier · · Score: 2, Informative

    You have never worked on rendering code for a game have you?

    You are wrong. I can tell the different between a game running at 30 fps and 60 fps because games rendering does not have temporal aliasing that movies do.