3 ms·

You are right. The author has absolutely no clue what he is writing about. Just like what you pointed out. He also claims raytracing does not solve photorealis

by struppi 14y ago

You are right. The author has absolutely no clue what he is writing about. Just like what you pointed out. He also claims raytracing does not solve photorealism, but does not back this claim. No single argument why! [Edit: But he's right here, for photorealism you probably want a combination of methods, like ray tracing and radiosity or ray tracing and photon mapping] Complexity: For raytracing, you can store the scene in very efficient data structures, so you do NOT have to search your "billions of triangles" for each ray. Also, you can make sure rays degrade quickly since you trace them from the camera backwards to the light source, as you have pointed out. "How do you raytrace stars"? They are a light source at infinite distance. This is a solved problem in computer graphics - And a pretty simple one at that. Materials, Physics, Content and AI have nothing to do with computer graphics AT ALL.

blackhole 14y ago
Storing triangles in a super efficient data structure is precisely what I mean by traversing the scene. Do you really think that's a free operation when you have billions of triangles inside a data structure that must be dynamic by nature? You hit all sorts of arcane memory issues. I hit the same thing just developing a basic kd-tree for 2D culling. The approximation algorithms I pointed out are exactly how raytracing is done backwards, but actually still must use a combination of camera rays and light source rays in a stocastic method in order to determine a path from the camera to the light source. Brute force raytracing is, in fact, just shooting out rays from the light sources. That's obviously inefficient, which is why we have the backwards lighting attempts, as discussed in the article. Raytracing stars is not as simply as you think, not when you can visit them. They can no longer be point sources at infinite distance because the object itself is not infinitely far away, so you therefore can only substitute an infinite light source in when its essentially a point, which gets really nasty when you are dealing with entire galaxies as light sources, and if it isn't you must deal with all the lighting effects in between. Materials are the most important part of computer graphics. If you don't think this, you have absolutely no idea what you are talking about.
- vilya 14y ago
  Re: raytracing stars, the obvious answer is to use a lower detail representation when the stars are far away. In this case all the photons from the faraway galaxy will be arriving from almost exactly the same direction, so there won't be any noticeable loss of accuracy. This fits in pretty naturally with the hierarchical data structure you'll already be using (in practice) to hold the scene. Regarding the data structure: the types of hierarchical structure commonly used to hold scene data for ray tracing actually lend themselves pretty well to level-of-detail, caching and streaming from disk; so it can be a help rather than a hindrance for managing memory. There's been some really promising work in the last few years on Sparse Voxel Octrees, for example.
- Geee 14y ago
  I don't think anyone has ever done purely a from light source tracing, because it doesn't make sense. Tracing from camera is not an approximation. Brute-force path tracing is random sampling from camera to every direction and bouncing/interacting until light source is hit. This is the standard Monte Carlo path tracing method which is unbiased and arrives at the accurate solution given enough time. This is unbiased, accurate and very simple to implement, but very slow to compute. Metropolis and photon mapping are bidirectional methods where rays are selectively traced back from light source to forward direction, to speed up the path tracing computation.
Jach 14y ago
> Materials, Physics, Content and AI have nothing to do with computer graphics AT ALL. What do you mean by computer graphics? If you restrict the job of a computer graphics programmer to purely a function of how many polygons can be rendered at once at 60fps, you may be right... But such a programmer would ignore information about the scene at his or her peril. Materials: what should this object look like when it interacts with other objects? Does dirt stick, what does it look like inside if it gets cut in two, would a smooth cut even be possible, what about just trying to make a dent with a blunt object? If a flashlight is shined at the material, how does the material react? Physics: help define how materials behave. (Indeed if we could model everything on the level of real-life quarks the need for explicitly defined materials goes away.) What's fluid supposed to look like? What about when a player character is swimming? Can we sacrifice polygon counts for distant objects, or are distant objects important in the game's physical world? What does wind do to the grass polygons? Could we use less polygons to represent quickly-moving things where the level of detail is going to be poor anyway? Content: Does an artist need to create two copies of Tree so we can model-swap the low-poly one when appropriate? Do we need to cut content to be able to render at reasonable speeds? Do we need more content to render something worth rendering? Do we have any content to put on the screen at all? AI: Depends if you consider procedural generation of content AI or not. Also depends if you consider a subroutine that helps optimize your graphics pipeline during runtime AI or not. Then there's the problem of many and nice animations, which you may or may not consider important to "computer graphics".
- pandaman 14y ago
  "Physics" in the context of the article and the game development in general does not mean the natural science. It just means the part of the game that moves stuff around. Same for the "AI", it only means the part that tells the "physics" when to move the stuff around. And content is necessary for games but so is the air and food for everything. We don't usually talk about food when discussing technical issues in some field. Just because it's necessary does not make it relevant to the discussion.

by struppi 14y ago

blackhole 14y ago

Storing triangles in a super efficient data structure is precisely what I mean by traversing the scene. Do you really think that's a free operation when you have billions of triangles inside a data structure that must be dynamic by nature? You hit all sorts of arcane memory issues. I hit the same thing just developing a basic kd-tree for 2D culling. The approximation algorithms I pointed out are exactly how raytracing is done backwards, but actually still must use a combination of camera rays and light source rays in a stocastic method in order to determine a path from the camera to the light source. Brute force raytracing is, in fact, just shooting out rays from the light sources. That's obviously inefficient, which is why we have the backwards lighting attempts, as discussed in the article. Raytracing stars is not as simply as you think, not when you can visit them. They can no longer be point sources at infinite distance because the object itself is not infinitely far away, so you therefore can only substitute an infinite light source in when its essentially a point, which gets really nasty when you are dealing with entire galaxies as light sources, and if it isn't you must deal with all the lighting effects in between. Materials are the most important part of computer graphics. If you don't think this, you have absolutely no idea what you are talking about.

vilya 14y ago
Re: raytracing stars, the obvious answer is to use a lower detail representation when the stars are far away. In this case all the photons from the faraway galaxy will be arriving from almost exactly the same direction, so there won't be any noticeable loss of accuracy. This fits in pretty naturally with the hierarchical data structure you'll already be using (in practice) to hold the scene. Regarding the data structure: the types of hierarchical structure commonly used to hold scene data for ray tracing actually lend themselves pretty well to level-of-detail, caching and streaming from disk; so it can be a help rather than a hindrance for managing memory. There's been some really promising work in the last few years on Sparse Voxel Octrees, for example.
Geee 14y ago
I don't think anyone has ever done purely a from light source tracing, because it doesn't make sense. Tracing from camera is not an approximation. Brute-force path tracing is random sampling from camera to every direction and bouncing/interacting until light source is hit. This is the standard Monte Carlo path tracing method which is unbiased and arrives at the accurate solution given enough time. This is unbiased, accurate and very simple to implement, but very slow to compute. Metropolis and photon mapping are bidirectional methods where rays are selectively traced back from light source to forward direction, to speed up the path tracing computation.

Jach 14y ago

> Materials, Physics, Content and AI have nothing to do with computer graphics AT ALL. What do you mean by computer graphics? If you restrict the job of a computer graphics programmer to purely a function of how many polygons can be rendered at once at 60fps, you may be right... But such a programmer would ignore information about the scene at his or her peril. Materials: what should this object look like when it interacts with other objects? Does dirt stick, what does it look like inside if it gets cut in two, would a smooth cut even be possible, what about just trying to make a dent with a blunt object? If a flashlight is shined at the material, how does the material react? Physics: help define how materials behave. (Indeed if we could model everything on the level of real-life quarks the need for explicitly defined materials goes away.) What's fluid supposed to look like? What about when a player character is swimming? Can we sacrifice polygon counts for distant objects, or are distant objects important in the game's physical world? What does wind do to the grass polygons? Could we use less polygons to represent quickly-moving things where the level of detail is going to be poor anyway? Content: Does an artist need to create two copies of Tree so we can model-swap the low-poly one when appropriate? Do we need to cut content to be able to render at reasonable speeds? Do we need more content to render something worth rendering? Do we have any content to put on the screen at all? AI: Depends if you consider procedural generation of content AI or not. Also depends if you consider a subroutine that helps optimize your graphics pipeline during runtime AI or not. Then there's the problem of many and nice animations, which you may or may not consider important to "computer graphics".

pandaman 14y ago
"Physics" in the context of the article and the game development in general does not mean the natural science. It just means the part of the game that moves stuff around. Same for the "AI", it only means the part that tells the "physics" when to move the stuff around. And content is necessary for games but so is the air and food for everything. We don't usually talk about food when discussing technical issues in some field. Just because it's necessary does not make it relevant to the discussion.