This is the
talk page for discussing improvements to the
Ray tracing (graphics) article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find video game sources: "Ray tracing" graphics – news · newspapers · books · scholar · JSTOR · free images · free news sources · TWL · NYT · WP reference · VG/RS · VG/RL · WPVG/Talk |
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This page is perhaps too specific.
Thus I suggest you make a distinction between the core of "ray tracing" as an algorithm and the various ways in which it is used to render images. --—Preceding unsigned comment added by Imroy ( talk • contribs) 10:37, 26 September 2004
Ad potential link spam in the article:
the ffconsultancy.com link in the "external links" section actually refers to a study that primarily deals *not* with raytracing, but rather with a strongly biased programming language comparison. Presumably should be removed as it is of no real relevance to raytracing. - Thomas Fischbacher --—Preceding unsigned comment added by 86.135.98.42 ( talk • contribs) 23:27, 27 October 2005
More and more links seem to point to commercial applications rather than web pages or documents that people can look at to learn about ray-tracing. For example lately Arauna & Photon Studio. Would everybody agree to remove them ? Or separate links in two categories. One for papers/tutorials and another one for any link that points to a product or a company ? -- 83.112.48.158 ( talk) 06:34, 23 June 2008 (UTC)
Agreed; unless it is particularly significant, I think that we should remove these commercial links; I've never heard of Arauna or Photon Studio before, despite being professionally involved in this field, I cant imagine that there could be any sort of consensus for viewing these as significant. I will remove. Cdecoro ( talk) 08:15, 23 June 2008 (UTC)
I don't want to remove any links but it seems to me that a couple of them are not greatly contributing to the article namely, "A series of tutorials on implementing a ray tracer using C++", "Tutorial on implementing a ray tracer in PHP". The "chapters" for the first article are not working, and an example of very basic ray tracing in PHP is really not adding any value to the article. I would like to suggest they get removed. There's tons of webpages of people putting the code of their ray tracer online. Only professional links should be kept in this article. jeancolasp ( talk) 19:21, 16 November 2014 (UTC)
I was researching Ray Tracing and immediately came to Wikipedia for a start to finesse my definition and realized this definition needed finessing. I reformatted and re-arranged the article today (11/18). It seems a little more linear now. I also agree that the links section needs bolstering - and is a more appropriate place for deeper explorations of the Ray Tracing topic (Monte Carlo, SIGGRAPH papers, etc.). Whoever put in all the stuff I edited seems to have included the most appropriate historical and technical balance for the definition. Thanks!kcdot -- —Preceding unsigned comment added by 12.7.137.83 ( talk • contribs) 19:38, 18 November 2005
Scanline algorithms and other algorithms use data coherence to share computations between pixels, while ray tracing normally starts the process anew, treating each eye ray separately.
Coherence is exploited in high performance parallel ray tracing, even if mostly to get better cache behaviour. Such a system typically shots a set of (hopefully) highly coherent rays together. As they have coherent memory access patterns, this greatly reduces memory bandwidth compared to shoting rays at random. This is done for example in the Ray Processing Unit. -- Taw 12:53, 18 December 2005 (UTC)
I think that the differences between ray casting and ray tracing are not made clear in this article. Ray casting can be thought of as a subclass of ray tracing. Both techniques cast rays from the eye into the scene through the pixel to intersect with objects/surfaces in the scene.
The general idea is that each surface is illuminated by lights and other surfaces. So the algorithm traces rays from the surface to other surfaces recursively. This is ray tracing.
Ray casting only considers the initial ray-object intersection. The color / shading of the pixel is dependant on the characteristics of the initial surface that the ray intersected with.
Please note that I am using the terms objects and surfaces interchangebly above. --—Preceding unsigned comment added by 81.97.15.130 ( talk • contribs) 00:30, 14 January 2006
Is the example that was just added too simple to be of any use? There is a lot more going on in raytracing than just finding the point where a line intersects a sphere. BTW, please check the math. I think it was dead wrong as originally posted, since the author confused vector and scalar math. I think I've fixed it but a second opinion would be useful.-- Srleffler 23:10, 4 February 2006 (UTC)
Sorry if I confused things - that's my first mathematical contribution here, and I'm not used to all the standards! The maths, however, was correct as it stood if one correctly interpreted dot product vs. multiplication - I've implemented it in a raytracer I wrote myself. Also, I know it was specific, and hence I was doubtful myself as to whether to add it - as I attmepted to make clear, it is only a example/taster of one of a particular algorithm used. "be brave" is the motto here - I just thought I'd give it a go. If you still dislike it, remove it. I was only trying to provide something of some interest, so if that was not the case, it would be better were it removed. -- Wrayal
I think the example is useful in the case of an optics application using a spherical lens. Anyway, I cleaned up the equations a bit. The boldface on the 'd' had been dropped halfway through, so I fixed that. I added a note saying it was vector notation. Also, I put the equation in quadratic form so it's easier to read and understand. Mikiemike 16:32, 8 November 2006 (UTC)
Does this equation really have more than one solution?
Now this quadratic equation has solution(s):
Unless t (time) can be negative, there will be either one or no solutions at all. -- Niks 11:34, 2 April 2007 (UTC)
It might be worth noting that 1) t isn't time, it's just a scalar distance (effectively); 2) you can have two positive solutions (V.d may be negative). Out of interest, should one root be positive, one negative, you would discard the latter, though in this instance you'd be inside the sphere.
131.111.245.246
20:56, 21 April 2007 (UTC)
This example is just what I needed for a college assignment. Thanks guys/gals! Yes, the equation can have up to two solutions. If you intersect a line with a sphere you might get an "entry" and "exit" point.
Yang (
talk)
20:33, 4 March 2008 (UTC)
I have added an image and a short description describing the algorithm in process. It should make the pseudocode easier to understand. -- Kolibri 10:57, 27 October 2006 (UTC)
Shouldn't the article be explicit that the example algorithm is pseudocode? Some people may actually think computer languages look like this. - 15:57, 18 January 2008 (UTC) —Preceding unsigned comment added by 137.99.115.235 ( talk)
The section below is mercilessly removed. The article already has the "See also / Software" subsection of wikipedia articles about ray-soft. The idea of the deletion is simple: if a software is notable, make an article (survive AfD :-) and wikilink it ito the abovementioned section. Otherwise the corresponding ext link is spam. Good luck, `' mikka 02:24, 19 May 2007 (UTC)
This article should be renamed 'optical ray tracing', because ray tracing has, for decades, also been done at RF and much of the argument here would need to be modified for that. `--- Aussienick
I agree. Ray tracing is used in many areas apart from the CG applications mentioned in the article; for example, I came here looking for ray tracing as related to acoustics. -- Devnevyn 11:32, 1 November 2007 (UTC)
I also agree. Ray tracing is a technique used to determine the path a wave will take, given its frequency and wavenumber; as the above authors mention (RF & acoustics) it is applicable to science beyond just computer graphics; for example, I came in search of earth/planetary wave ray tracing. 07:22, 10 February 2008 (UTC) —Preceding unsigned comment added by 131.128.73.5 ( talk)
Not entirely sure where to put this, but I believe a mention should be made about the fact that the ray tracing algorithm is embarrassingly parallel - an example from that page, "In ray tracing, each pixel may be rendered independently. In computer animation, each frame may be rendered independently."
Anyone concur?
Smerity 09:30, 22 October 2007 (UTC)
raytrace is best thing KOSOVO —Preceding unsigned comment added by 80.80.161.147 ( talk) 20:24, 27 February 2008 (UTC)
The figure PathOfRays.svg, and the associated text (below the code sample, beginning with "First, a ray is created at an eyepoint"), seems to imply that when a ray intersects a diffuse surface, that ray is reflected onto another diffuse surface, and so on, until it reaches a light source.
While this is correct for reflective, mirror-like surfaces, or transparent glassy surfaces, it is not true for *diffuse* surfaces. When a ray intersects a diffuse, non-reflective surface, the recursion stops, and shadow rays are projected only to light sources in order to compute the direct illumination term. The recursion does not continue. This is why ray-tracing cannot do indirect illumination, which is precisely what inter-reflections among diffuse surfaces would entail.
Note that while the descriptive text and the figure are incorrect, the pseudo-code excerpt is in fact correct. Note that it specifies "generate ... ray: recurse" only if the surface is either "reflective" or "transparent". If neither of these is true, the surface is diffuse and the recursion stops.
The statement that "For example if the light source emitted white light and the two diffuse surfaces were blue, then the resulting color of the pixel is blue" implies color blending from one surface to another, which is not true for ray-tracing (but is true for radiosity or other general illumination methods)
-- marciot
Ray tracing in computer graphics and ray tracing in other applications are similar in concept, but quite different topics. I suggest creating "Ray Tracing" and "Ray Tracing (physics)". Ray tracing in graphics is quite a deep topic, and I don't think it makes sense to group it with discussion about tracing radio waves through the ionosphere, etc.
The former of the two pages would focus on graphics applications, with a "if you are looking for..." thingie at the top pointing to the physics page. A quick google search for "ray trace" shows almost entirely graphics results, so it should probably be the main article. This would give the article more space to talk about some of the different variations and non-physical tricks that ray tracing algorithms use.
The "Ray Tracing (physics)" page would have a similar redirect, and would discuss purely scientific applications of ray tracing, like the part about radio waves & lens design. Ray tracing is also used to trace acoustic signals through the varying density of the ocean, and the physics page would be a good place to put this as well.
It seems like other people on this talk page agree that the two topics are somehow fighting with each other. Thoughts?
Timrb ( talk) 09:11, 18 April 2008 (UTC)
There seems to be some dispute over whether the main image uses diffuse interreflection and area light sources. I can tell you as the creator of the image and programmer of the renderer that it does, and this is documented in the image's description page. If you still don't believe me, I can render it again with global illumination turned off and you can see the difference for yourself. Timrb ( talk) 08:40, 22 May 2008 (UTC)
When this page was moved to "Ray tracing (graphics)" from just plain "Ray tracing", all the links to this page were suddenly broken, and now every article that was supposed to link to an article about ray tracing in graphics now points to a disambig page.
This Should Not Be and I think drives the point home that the (graphics) part of the title is not necessary and just messes things up, as anyone who wrote [[ray tracing]] would reasonably expect it to point to the graphics article. A quick google search for "ray trace" verifies that the vast majority of pages are about ray tracing in graphics. The Wikipedia:Disambiguation page allows for a non-disambiguated title if there is a clear primary topic. If there are no objections, I would like to move this page back to its original title. Timrb ( talk) 09:09, 22 May 2008 (UTC)
The result of the proposal was Do not move. Looks like someone is messing with the target redirect now. Everyone play nice please. — Wknight94 ( talk) 17:19, 11 June 2008 (UTC)
Ray tracing redirects here. As this is the primary topic, there is no need to add (graphics) to the article name. 199.125.109.107 ( talk) 06:01, 30 May 2008 (UTC)
Oppose Ray tracing has a long history in fields other than CG; Gauss was tracing rays in his studies of optics long before computers. The title should stay as it is. Cdecoro ( talk) 17:26, 10 June 2008 (UTC)
Does anyone know how this move happened, even though it had only opposition here? Dicklyon ( talk) 03:25, 11 June 2008 (UTC)
Oppose. Independent of frequency of use, the physics sense of the term is primary. The graphics technique is an application of physics-based ray tracing.-- Srleffler ( talk) 08:13, 11 June 2008 (UTC)
This article really doesn't know what its focus is on; I agree with one of the first posters: is it about visibility determination along a ray, specifically expressed as ray-object intersection? Or is it about rendering algorithms that use ray tracing as a component, which is basically equivalent to saying ALL physically-based rendering algorithms (even radiosity algorithms generally use ray tracing to compute form factors, and frequently use ray tracing to perform the final image synthesis to pixels). I suggest that this article be primarily focused on the former (visibility determination by intersecting rays) and specific articles be made to cover the rendering algorithms that use it. Cdecoro ( talk) 17:26, 10 June 2008 (UTC)
User:Cdecoro says "Replaced incorrect and misleading information on radiosity, photon mapping, and MLT with a (hopefully!) clearer and more informed version." But how can we tell if it's less misleading, clearer, or more informed, if you don't tell us what it's informed by? To encourage the citation of a source or two, I think I'll just revert it for now. Dicklyon ( talk) 17:32, 10 June 2008 (UTC)
I've now added additional references to the original papers on bidir path tracing and photon mapping; in conjunction with the references by Timrb, this is sufficient. Cdecoro ( talk) 21:41, 11 June 2008 (UTC)
I've got a work in progress here: User:Timrb/Ray tracing. Some comments on structure and content could be helpful. (In particular, I'm now wondering about all that lighting model stuff-- perhaps it belongs in an article of its own? On the other hand, it will make formally talking about things like path tracing a lot easier.) Timrb ( talk) 12:18, 23 June 2008 (UTC)
Hey, I think its looking really good. I think the light modeling section is very good to have; if we're going to talk about ray tracing as the rendering algorithm, as opposed to merely a visibility determination method, than I think theres no better place than here. I would strongly suggest (for the Rendering equation article also) using and instead of w and w' for the exitant and incident directions, respectivly. It's now mostly the standard usage, and I think its a lot clearer, both in indicating that we are talking about a direction (with omega) and disambiguating the directions. The illustrations look really good btw, I just figured I'd mention that sooner or later someone is going to attach one of those "should be SVG" tags, though. Cdecoro ( talk) 20:31, 23 June 2008 (UTC)
This new version is interesting and agree, illustrations are good. However I feel it is not justified to switch from the existing version to this one. I believe it would have been much better to improve the existing document which is already rather good. The main difference between the two articles is your section on illumination models. However illumination models are not specific to ray-tracing. It would be therefore, as suggested, a much better idea to move that content to a specific article on CG illumination models. As for the article itself. The two articles are still not focused enough on the concept of rays and how they can be used in a rendering program. We should included example such as shooting rays to compute indirect diffuse, shooting rays to simulate area lights, shooting rays to compute BSSRDF, etc. and have clearer references to topics in which rays can be used (importance sampling, advanced light transport models, etc). There's no note on 'acne' which is a typical rendering artifact of ray-tracers. A last note, citation list could be cleaned with at last proper citation of Appel & Whited's papers, I would suggest to clean the Software list, keep renderers' names which have been known to contribute to make this algorithm popular (MRay, POV, lately PRman) and remove the others (this is not an article on 3D rendering programs). I am unsure as why the External Links is different in the suggested article than the existing one (links can't be left to purely personal choices). Also the pseudo code version is good but reference to Java could be removed and it would make it really pseudo code then. For example the code is readable without the public declaration... plus floats could be used instead of doubles (which sticks to what most render programs use). I don't want to discourage any attempt in improving this article. On the contrary it's great it has some attention. We are just a bit off track here while a lot can still be done to add more useful information on the subject. --- Mast4as ( talk) 07:01, 27 July 2008 (UTC)
It's true, I just checked them myself, 3 times and I know what I'm talking about. I have a PhD in Advanced Mathematics from MIT. 89.123.87.161 ( talk)M.Johnson —Preceding undated comment was added at 17:59, 19 January 2009 (UTC).
I might only be in algebra, but that doesn't mean I can't try to make a ray-tracer! The only problem is, I can't find equations to re-create reflection of a line off any surface! Could someone maybe edit the page to describe an equation to allow you to MAKE reflective objects? Becuase, until then, my ray-tracer can only be diffused. —Preceding unsigned comment added by GMEncrypt ( talk • contribs) 01:32, 10 July 2009 (UTC)
More of a question than a comment - is there any research into combining foveated imaging with ray tracing to cut down on the calculation overheads? I am imagining some sort of view-direction detection for animated ray-traced graphics, so that the image rendered is high-resolution only where the viewer is actually looking at that moment. Simon Oliver (nli) 212.125.69.106 ( talk) 13:59, 26 January 2010 (UTC)
Retina | |
---|---|
![]() Right human
eye cross-sectional view. Courtesy
NIH
National Eye Institute. Many animals have eyes different from the human eye. | |
Details | |
Artery | central retinal artery |
Anatomical terminology |
I mean glass, water light refraction and even for computer graphics, if object is big like human at 1 meter distance, then you will not see him like real 3D person but with some unrealistic 3D effects. Only small objects like bugs or mouse from closely (from close look) can be viewed correctly, but even mouse is too big. So for ray tracing (glass, water light refraction) this "BIG EYE"-"BIG VIRTUAL CAMERA" effect will be deadly and distortion and wrong ray tracing will appear. But since not many of us, think what can be correct ray tracing and what can be wrong ray trancing, then many can do not notice difference, between correct ray tracing and wrong ray tracing for big objects (bigger than size of eye; bigger than 1 cm size).
What is solution? Solution is, that need to change all 3D drawing algorithms, because they are all wrong even not for ray tracing, but for all big and not distance objects, but this will require addition computing power of about 2-10 times more.
In current games iris size is about 1 square meter.
The exact solution would be to shrink virtual camera (in game or rendering) size or to maximize size of all objects around and then in front of virtual camera [matrix] need to put glass lens, which have correctly chosen light refraction of about 1 cm of size in front of virtual camera (or virtual eye). This is possible for 3D rendering like in 3Dmax, but just need to put on camera correct lens of glass and need to magnifie objects, which need to render. But in current 3D games, where you can't have light refraction in glass - is impossible to see correct 3D shapes/objects.
— Preceding unsigned comment added by Versatranitsonlywaytofly ( talk • contribs)
And by the way, glass refraction is (I don't know how correctly) is possible even on Radeon 9700 card (about 2004 year) in ATI Debevec 9700 demo. But multiple times of reflections in current games are still imposible.
(glass balls are purple, green for instance and big in center) — Preceding unsigned comment added by Versatranitsonlywaytofly ( talk • contribs) 11:52, 14 March 2011 (UTC)
I wonder what the class of rendering algorithms is called that traces paths of particles, either it is from the eye or from a light source, and lets the particles bounce around in the scene ( ray tracing and path tracing (what's the difference?), Metropolis light transport, photon mapping, instant radiosity etc.). "Path tracing" seems to be a suitable name for such a family since all of those algorithms basically trace paths, and the article says it is a generalization of conventional ray tracing, but path tracing refers to a specific algorithm in which paths are traced from the eye and samples the light input to the eye in Monte Carlo fashion (or so I've heard). Besides, the article talks about the path tracing algorithm. Ray tracing on the other hand, can refer to Whitted-style ray tracing, which simulates direct illumination from delta (point and directional) light sources and specular reflection and refraction. So what should you say if you want to talk about all these algorithms at once?
If you leave an answer, please notify me on my talk page. — Kri ( talk) 00:58, 14 August 2011 (UTC)
What is relationship between this method and Monte Carlo method for photon transport? 142.196.169.88 ( talk) 05:19, 29 July 2013 (UTC)
Nobody can verify if the example image was in fact produced using the techniques described in the article. We have to trust the author. That's not the way an open encyclopedia works. -- 84.177.32.89 ( talk) 08:24, 19 August 2011 (UTC)
I disagree with the move from "Ray tracing (graphics)" to "Ray tracing". As discussed previously, the graphics usage is not unambiguously primary.-- Srleffler ( talk) 05:18, 9 December 2011 (UTC)
If this is wrong to do, please explain to me why. AFAIK this is one of the most classic graphics algorithms there is... ToolmakerSteve ( talk) 06:56, 27 October 2012 (UTC)
I am not an expert in ray tracing, but even I can tell that there is a problem with the disadvantages section as it is written. I think the problem stems from ambiguity between "ray tracing in the narrow, historical sense of Whitted's ray tracing algorithm" and "ray tracing as a technique, that is used in a wide variety of algorithms". Correct me if I'm wrong, but without the concept of tracing rays, most (performance practical) global illumination algorithms would not exist. Photon mapping & path tracing - couldn't these (oversimplified) be described as casting additional rays (in a particular manner)? Or am I confusing the basic act of "ray casting" with a specific use of ray casting, that is considered "ray tracing"? Is there consensus on the meaning of "ray tracing"? ToolmakerSteve ( talk) 07:36, 27 October 2012 (UTC)
The section /info/en/?search=Ray_tracing_(graphics)#Bounding_volumes would be far more understandable to non-mathamaticians if there was an illustration of the pieces that make up the bounding volume.
Hardware raytracing is just a subtopic of raytracing Ethanpet113 ( talk) 04:20, 20 April 2019 (UTC)
The last paragraph of the introduction has this sentence: "In fact, any physical wave or particle phenomenon with approximately linear motion can be simulated with ray tracing." I am wondering what would be an example of a physical phenomenon that behaves nonlinearly? I am wondering if there is a phenomenon that behaves in a spiral shape or something else? ScientistBuilder ( talk) 02:14, 27 January 2022 (UTC)ScientistBuilder ScientistBuilder ( talk) 02:14, 27 January 2022 (UTC)
I would like to add this source https://reference.wolfram.com/language/tutorial/PhysicallyBasedRendering.html. It would be good to add a few details about the limitations of ray tracing. ScientistBuilder ( talk) 21:08, 27 January 2022 (UTC)ScientistBuilder ScientistBuilder ( talk) 21:08, 27 January 2022 (UTC)
Is there a way to measure how much more computing power is needed for every increase in resolution? I am curious about this part of the Disadvantages section: "A serious disadvantage of ray tracing is performance (though it can in theory be faster than traditional scanline rendering depending on scene complexity vs. number of pixels on-screen). Until the late 2010s, ray tracing in real time was usually considered impossible on consumer hardware for nontrivial tasks." given a finite amount of computing power, which is more realistic: a lower resolution image with more ray tracing calculations done or a higher resolution image (4k for example) with reduced ray tracing calculations? Is there a way to approximate using Big O or asymptotic notation the number of additional calculations needed? ScientistBuilder ( talk) 21:12, 27 January 2022 (UTC)ScientistBuilder ScientistBuilder ( talk) 21:12, 27 January 2022 (UTC)
An editor has identified a potential problem with the redirect
Ray tracing (graphics and has thus listed it
for discussion. This discussion will occur at
Wikipedia:Redirects for discussion/Log/2022 October 27#Ray tracing (graphics until a consensus is reached, and readers of this page are welcome to contribute to the discussion.
Steel1943 (
talk)
19:24, 27 October 2022 (UTC)
It turns out that ray tracing in the most common form is reminiscent of the emission theory as set forth by Greek philosophers, notably Empedocles. This ancient, now scientifically obsolete theory postulated that our eyes emitted rays lighting up things for us to see. Remember, Empedocles was the same man who theorized that everything was composed of air, earth, fire, and water, with love pulling the elements together and hate tearing them apart. In his theory of light, the fire in our heads emitted beams that would bounce off objects before entering the eye again. Essentially, our eyes were like flashlights. Never mind that a startling number of people continue to adhere to the obsolete theory. It has been pointed out that it has practical use in computer graphics as recursive ray tracing since it is computationally orders of magnitude more efficient than to have the light sources emitting rays in all directions, most of which never reach the camera. Does this mention have a place in the article, perhaps under history? Free Media Kid$ 15:54, 16 November 2022 (UTC)
Section uses acronym "BVH" without that being defined. Marcusmueller ettus ( talk) 14:18, 16 January 2023 (UTC)
This is the
talk page for discussing improvements to the
Ray tracing (graphics) article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find video game sources: "Ray tracing" graphics – news · newspapers · books · scholar · JSTOR · free images · free news sources · TWL · NYT · WP reference · VG/RS · VG/RL · WPVG/Talk |
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This page is perhaps too specific.
Thus I suggest you make a distinction between the core of "ray tracing" as an algorithm and the various ways in which it is used to render images. --—Preceding unsigned comment added by Imroy ( talk • contribs) 10:37, 26 September 2004
Ad potential link spam in the article:
the ffconsultancy.com link in the "external links" section actually refers to a study that primarily deals *not* with raytracing, but rather with a strongly biased programming language comparison. Presumably should be removed as it is of no real relevance to raytracing. - Thomas Fischbacher --—Preceding unsigned comment added by 86.135.98.42 ( talk • contribs) 23:27, 27 October 2005
More and more links seem to point to commercial applications rather than web pages or documents that people can look at to learn about ray-tracing. For example lately Arauna & Photon Studio. Would everybody agree to remove them ? Or separate links in two categories. One for papers/tutorials and another one for any link that points to a product or a company ? -- 83.112.48.158 ( talk) 06:34, 23 June 2008 (UTC)
Agreed; unless it is particularly significant, I think that we should remove these commercial links; I've never heard of Arauna or Photon Studio before, despite being professionally involved in this field, I cant imagine that there could be any sort of consensus for viewing these as significant. I will remove. Cdecoro ( talk) 08:15, 23 June 2008 (UTC)
I don't want to remove any links but it seems to me that a couple of them are not greatly contributing to the article namely, "A series of tutorials on implementing a ray tracer using C++", "Tutorial on implementing a ray tracer in PHP". The "chapters" for the first article are not working, and an example of very basic ray tracing in PHP is really not adding any value to the article. I would like to suggest they get removed. There's tons of webpages of people putting the code of their ray tracer online. Only professional links should be kept in this article. jeancolasp ( talk) 19:21, 16 November 2014 (UTC)
I was researching Ray Tracing and immediately came to Wikipedia for a start to finesse my definition and realized this definition needed finessing. I reformatted and re-arranged the article today (11/18). It seems a little more linear now. I also agree that the links section needs bolstering - and is a more appropriate place for deeper explorations of the Ray Tracing topic (Monte Carlo, SIGGRAPH papers, etc.). Whoever put in all the stuff I edited seems to have included the most appropriate historical and technical balance for the definition. Thanks!kcdot -- —Preceding unsigned comment added by 12.7.137.83 ( talk • contribs) 19:38, 18 November 2005
Scanline algorithms and other algorithms use data coherence to share computations between pixels, while ray tracing normally starts the process anew, treating each eye ray separately.
Coherence is exploited in high performance parallel ray tracing, even if mostly to get better cache behaviour. Such a system typically shots a set of (hopefully) highly coherent rays together. As they have coherent memory access patterns, this greatly reduces memory bandwidth compared to shoting rays at random. This is done for example in the Ray Processing Unit. -- Taw 12:53, 18 December 2005 (UTC)
I think that the differences between ray casting and ray tracing are not made clear in this article. Ray casting can be thought of as a subclass of ray tracing. Both techniques cast rays from the eye into the scene through the pixel to intersect with objects/surfaces in the scene.
The general idea is that each surface is illuminated by lights and other surfaces. So the algorithm traces rays from the surface to other surfaces recursively. This is ray tracing.
Ray casting only considers the initial ray-object intersection. The color / shading of the pixel is dependant on the characteristics of the initial surface that the ray intersected with.
Please note that I am using the terms objects and surfaces interchangebly above. --—Preceding unsigned comment added by 81.97.15.130 ( talk • contribs) 00:30, 14 January 2006
Is the example that was just added too simple to be of any use? There is a lot more going on in raytracing than just finding the point where a line intersects a sphere. BTW, please check the math. I think it was dead wrong as originally posted, since the author confused vector and scalar math. I think I've fixed it but a second opinion would be useful.-- Srleffler 23:10, 4 February 2006 (UTC)
Sorry if I confused things - that's my first mathematical contribution here, and I'm not used to all the standards! The maths, however, was correct as it stood if one correctly interpreted dot product vs. multiplication - I've implemented it in a raytracer I wrote myself. Also, I know it was specific, and hence I was doubtful myself as to whether to add it - as I attmepted to make clear, it is only a example/taster of one of a particular algorithm used. "be brave" is the motto here - I just thought I'd give it a go. If you still dislike it, remove it. I was only trying to provide something of some interest, so if that was not the case, it would be better were it removed. -- Wrayal
I think the example is useful in the case of an optics application using a spherical lens. Anyway, I cleaned up the equations a bit. The boldface on the 'd' had been dropped halfway through, so I fixed that. I added a note saying it was vector notation. Also, I put the equation in quadratic form so it's easier to read and understand. Mikiemike 16:32, 8 November 2006 (UTC)
Does this equation really have more than one solution?
Now this quadratic equation has solution(s):
Unless t (time) can be negative, there will be either one or no solutions at all. -- Niks 11:34, 2 April 2007 (UTC)
It might be worth noting that 1) t isn't time, it's just a scalar distance (effectively); 2) you can have two positive solutions (V.d may be negative). Out of interest, should one root be positive, one negative, you would discard the latter, though in this instance you'd be inside the sphere.
131.111.245.246
20:56, 21 April 2007 (UTC)
This example is just what I needed for a college assignment. Thanks guys/gals! Yes, the equation can have up to two solutions. If you intersect a line with a sphere you might get an "entry" and "exit" point.
Yang (
talk)
20:33, 4 March 2008 (UTC)
I have added an image and a short description describing the algorithm in process. It should make the pseudocode easier to understand. -- Kolibri 10:57, 27 October 2006 (UTC)
Shouldn't the article be explicit that the example algorithm is pseudocode? Some people may actually think computer languages look like this. - 15:57, 18 January 2008 (UTC) —Preceding unsigned comment added by 137.99.115.235 ( talk)
The section below is mercilessly removed. The article already has the "See also / Software" subsection of wikipedia articles about ray-soft. The idea of the deletion is simple: if a software is notable, make an article (survive AfD :-) and wikilink it ito the abovementioned section. Otherwise the corresponding ext link is spam. Good luck, `' mikka 02:24, 19 May 2007 (UTC)
This article should be renamed 'optical ray tracing', because ray tracing has, for decades, also been done at RF and much of the argument here would need to be modified for that. `--- Aussienick
I agree. Ray tracing is used in many areas apart from the CG applications mentioned in the article; for example, I came here looking for ray tracing as related to acoustics. -- Devnevyn 11:32, 1 November 2007 (UTC)
I also agree. Ray tracing is a technique used to determine the path a wave will take, given its frequency and wavenumber; as the above authors mention (RF & acoustics) it is applicable to science beyond just computer graphics; for example, I came in search of earth/planetary wave ray tracing. 07:22, 10 February 2008 (UTC) —Preceding unsigned comment added by 131.128.73.5 ( talk)
Not entirely sure where to put this, but I believe a mention should be made about the fact that the ray tracing algorithm is embarrassingly parallel - an example from that page, "In ray tracing, each pixel may be rendered independently. In computer animation, each frame may be rendered independently."
Anyone concur?
Smerity 09:30, 22 October 2007 (UTC)
raytrace is best thing KOSOVO —Preceding unsigned comment added by 80.80.161.147 ( talk) 20:24, 27 February 2008 (UTC)
The figure PathOfRays.svg, and the associated text (below the code sample, beginning with "First, a ray is created at an eyepoint"), seems to imply that when a ray intersects a diffuse surface, that ray is reflected onto another diffuse surface, and so on, until it reaches a light source.
While this is correct for reflective, mirror-like surfaces, or transparent glassy surfaces, it is not true for *diffuse* surfaces. When a ray intersects a diffuse, non-reflective surface, the recursion stops, and shadow rays are projected only to light sources in order to compute the direct illumination term. The recursion does not continue. This is why ray-tracing cannot do indirect illumination, which is precisely what inter-reflections among diffuse surfaces would entail.
Note that while the descriptive text and the figure are incorrect, the pseudo-code excerpt is in fact correct. Note that it specifies "generate ... ray: recurse" only if the surface is either "reflective" or "transparent". If neither of these is true, the surface is diffuse and the recursion stops.
The statement that "For example if the light source emitted white light and the two diffuse surfaces were blue, then the resulting color of the pixel is blue" implies color blending from one surface to another, which is not true for ray-tracing (but is true for radiosity or other general illumination methods)
-- marciot
Ray tracing in computer graphics and ray tracing in other applications are similar in concept, but quite different topics. I suggest creating "Ray Tracing" and "Ray Tracing (physics)". Ray tracing in graphics is quite a deep topic, and I don't think it makes sense to group it with discussion about tracing radio waves through the ionosphere, etc.
The former of the two pages would focus on graphics applications, with a "if you are looking for..." thingie at the top pointing to the physics page. A quick google search for "ray trace" shows almost entirely graphics results, so it should probably be the main article. This would give the article more space to talk about some of the different variations and non-physical tricks that ray tracing algorithms use.
The "Ray Tracing (physics)" page would have a similar redirect, and would discuss purely scientific applications of ray tracing, like the part about radio waves & lens design. Ray tracing is also used to trace acoustic signals through the varying density of the ocean, and the physics page would be a good place to put this as well.
It seems like other people on this talk page agree that the two topics are somehow fighting with each other. Thoughts?
Timrb ( talk) 09:11, 18 April 2008 (UTC)
There seems to be some dispute over whether the main image uses diffuse interreflection and area light sources. I can tell you as the creator of the image and programmer of the renderer that it does, and this is documented in the image's description page. If you still don't believe me, I can render it again with global illumination turned off and you can see the difference for yourself. Timrb ( talk) 08:40, 22 May 2008 (UTC)
When this page was moved to "Ray tracing (graphics)" from just plain "Ray tracing", all the links to this page were suddenly broken, and now every article that was supposed to link to an article about ray tracing in graphics now points to a disambig page.
This Should Not Be and I think drives the point home that the (graphics) part of the title is not necessary and just messes things up, as anyone who wrote [[ray tracing]] would reasonably expect it to point to the graphics article. A quick google search for "ray trace" verifies that the vast majority of pages are about ray tracing in graphics. The Wikipedia:Disambiguation page allows for a non-disambiguated title if there is a clear primary topic. If there are no objections, I would like to move this page back to its original title. Timrb ( talk) 09:09, 22 May 2008 (UTC)
The result of the proposal was Do not move. Looks like someone is messing with the target redirect now. Everyone play nice please. — Wknight94 ( talk) 17:19, 11 June 2008 (UTC)
Ray tracing redirects here. As this is the primary topic, there is no need to add (graphics) to the article name. 199.125.109.107 ( talk) 06:01, 30 May 2008 (UTC)
Oppose Ray tracing has a long history in fields other than CG; Gauss was tracing rays in his studies of optics long before computers. The title should stay as it is. Cdecoro ( talk) 17:26, 10 June 2008 (UTC)
Does anyone know how this move happened, even though it had only opposition here? Dicklyon ( talk) 03:25, 11 June 2008 (UTC)
Oppose. Independent of frequency of use, the physics sense of the term is primary. The graphics technique is an application of physics-based ray tracing.-- Srleffler ( talk) 08:13, 11 June 2008 (UTC)
This article really doesn't know what its focus is on; I agree with one of the first posters: is it about visibility determination along a ray, specifically expressed as ray-object intersection? Or is it about rendering algorithms that use ray tracing as a component, which is basically equivalent to saying ALL physically-based rendering algorithms (even radiosity algorithms generally use ray tracing to compute form factors, and frequently use ray tracing to perform the final image synthesis to pixels). I suggest that this article be primarily focused on the former (visibility determination by intersecting rays) and specific articles be made to cover the rendering algorithms that use it. Cdecoro ( talk) 17:26, 10 June 2008 (UTC)
User:Cdecoro says "Replaced incorrect and misleading information on radiosity, photon mapping, and MLT with a (hopefully!) clearer and more informed version." But how can we tell if it's less misleading, clearer, or more informed, if you don't tell us what it's informed by? To encourage the citation of a source or two, I think I'll just revert it for now. Dicklyon ( talk) 17:32, 10 June 2008 (UTC)
I've now added additional references to the original papers on bidir path tracing and photon mapping; in conjunction with the references by Timrb, this is sufficient. Cdecoro ( talk) 21:41, 11 June 2008 (UTC)
I've got a work in progress here: User:Timrb/Ray tracing. Some comments on structure and content could be helpful. (In particular, I'm now wondering about all that lighting model stuff-- perhaps it belongs in an article of its own? On the other hand, it will make formally talking about things like path tracing a lot easier.) Timrb ( talk) 12:18, 23 June 2008 (UTC)
Hey, I think its looking really good. I think the light modeling section is very good to have; if we're going to talk about ray tracing as the rendering algorithm, as opposed to merely a visibility determination method, than I think theres no better place than here. I would strongly suggest (for the Rendering equation article also) using and instead of w and w' for the exitant and incident directions, respectivly. It's now mostly the standard usage, and I think its a lot clearer, both in indicating that we are talking about a direction (with omega) and disambiguating the directions. The illustrations look really good btw, I just figured I'd mention that sooner or later someone is going to attach one of those "should be SVG" tags, though. Cdecoro ( talk) 20:31, 23 June 2008 (UTC)
This new version is interesting and agree, illustrations are good. However I feel it is not justified to switch from the existing version to this one. I believe it would have been much better to improve the existing document which is already rather good. The main difference between the two articles is your section on illumination models. However illumination models are not specific to ray-tracing. It would be therefore, as suggested, a much better idea to move that content to a specific article on CG illumination models. As for the article itself. The two articles are still not focused enough on the concept of rays and how they can be used in a rendering program. We should included example such as shooting rays to compute indirect diffuse, shooting rays to simulate area lights, shooting rays to compute BSSRDF, etc. and have clearer references to topics in which rays can be used (importance sampling, advanced light transport models, etc). There's no note on 'acne' which is a typical rendering artifact of ray-tracers. A last note, citation list could be cleaned with at last proper citation of Appel & Whited's papers, I would suggest to clean the Software list, keep renderers' names which have been known to contribute to make this algorithm popular (MRay, POV, lately PRman) and remove the others (this is not an article on 3D rendering programs). I am unsure as why the External Links is different in the suggested article than the existing one (links can't be left to purely personal choices). Also the pseudo code version is good but reference to Java could be removed and it would make it really pseudo code then. For example the code is readable without the public declaration... plus floats could be used instead of doubles (which sticks to what most render programs use). I don't want to discourage any attempt in improving this article. On the contrary it's great it has some attention. We are just a bit off track here while a lot can still be done to add more useful information on the subject. --- Mast4as ( talk) 07:01, 27 July 2008 (UTC)
It's true, I just checked them myself, 3 times and I know what I'm talking about. I have a PhD in Advanced Mathematics from MIT. 89.123.87.161 ( talk)M.Johnson —Preceding undated comment was added at 17:59, 19 January 2009 (UTC).
I might only be in algebra, but that doesn't mean I can't try to make a ray-tracer! The only problem is, I can't find equations to re-create reflection of a line off any surface! Could someone maybe edit the page to describe an equation to allow you to MAKE reflective objects? Becuase, until then, my ray-tracer can only be diffused. —Preceding unsigned comment added by GMEncrypt ( talk • contribs) 01:32, 10 July 2009 (UTC)
More of a question than a comment - is there any research into combining foveated imaging with ray tracing to cut down on the calculation overheads? I am imagining some sort of view-direction detection for animated ray-traced graphics, so that the image rendered is high-resolution only where the viewer is actually looking at that moment. Simon Oliver (nli) 212.125.69.106 ( talk) 13:59, 26 January 2010 (UTC)
Retina | |
---|---|
![]() Right human
eye cross-sectional view. Courtesy
NIH
National Eye Institute. Many animals have eyes different from the human eye. | |
Details | |
Artery | central retinal artery |
Anatomical terminology |
I mean glass, water light refraction and even for computer graphics, if object is big like human at 1 meter distance, then you will not see him like real 3D person but with some unrealistic 3D effects. Only small objects like bugs or mouse from closely (from close look) can be viewed correctly, but even mouse is too big. So for ray tracing (glass, water light refraction) this "BIG EYE"-"BIG VIRTUAL CAMERA" effect will be deadly and distortion and wrong ray tracing will appear. But since not many of us, think what can be correct ray tracing and what can be wrong ray trancing, then many can do not notice difference, between correct ray tracing and wrong ray tracing for big objects (bigger than size of eye; bigger than 1 cm size).
What is solution? Solution is, that need to change all 3D drawing algorithms, because they are all wrong even not for ray tracing, but for all big and not distance objects, but this will require addition computing power of about 2-10 times more.
In current games iris size is about 1 square meter.
The exact solution would be to shrink virtual camera (in game or rendering) size or to maximize size of all objects around and then in front of virtual camera [matrix] need to put glass lens, which have correctly chosen light refraction of about 1 cm of size in front of virtual camera (or virtual eye). This is possible for 3D rendering like in 3Dmax, but just need to put on camera correct lens of glass and need to magnifie objects, which need to render. But in current 3D games, where you can't have light refraction in glass - is impossible to see correct 3D shapes/objects.
— Preceding unsigned comment added by Versatranitsonlywaytofly ( talk • contribs)
And by the way, glass refraction is (I don't know how correctly) is possible even on Radeon 9700 card (about 2004 year) in ATI Debevec 9700 demo. But multiple times of reflections in current games are still imposible.
(glass balls are purple, green for instance and big in center) — Preceding unsigned comment added by Versatranitsonlywaytofly ( talk • contribs) 11:52, 14 March 2011 (UTC)
I wonder what the class of rendering algorithms is called that traces paths of particles, either it is from the eye or from a light source, and lets the particles bounce around in the scene ( ray tracing and path tracing (what's the difference?), Metropolis light transport, photon mapping, instant radiosity etc.). "Path tracing" seems to be a suitable name for such a family since all of those algorithms basically trace paths, and the article says it is a generalization of conventional ray tracing, but path tracing refers to a specific algorithm in which paths are traced from the eye and samples the light input to the eye in Monte Carlo fashion (or so I've heard). Besides, the article talks about the path tracing algorithm. Ray tracing on the other hand, can refer to Whitted-style ray tracing, which simulates direct illumination from delta (point and directional) light sources and specular reflection and refraction. So what should you say if you want to talk about all these algorithms at once?
If you leave an answer, please notify me on my talk page. — Kri ( talk) 00:58, 14 August 2011 (UTC)
What is relationship between this method and Monte Carlo method for photon transport? 142.196.169.88 ( talk) 05:19, 29 July 2013 (UTC)
Nobody can verify if the example image was in fact produced using the techniques described in the article. We have to trust the author. That's not the way an open encyclopedia works. -- 84.177.32.89 ( talk) 08:24, 19 August 2011 (UTC)
I disagree with the move from "Ray tracing (graphics)" to "Ray tracing". As discussed previously, the graphics usage is not unambiguously primary.-- Srleffler ( talk) 05:18, 9 December 2011 (UTC)
If this is wrong to do, please explain to me why. AFAIK this is one of the most classic graphics algorithms there is... ToolmakerSteve ( talk) 06:56, 27 October 2012 (UTC)
I am not an expert in ray tracing, but even I can tell that there is a problem with the disadvantages section as it is written. I think the problem stems from ambiguity between "ray tracing in the narrow, historical sense of Whitted's ray tracing algorithm" and "ray tracing as a technique, that is used in a wide variety of algorithms". Correct me if I'm wrong, but without the concept of tracing rays, most (performance practical) global illumination algorithms would not exist. Photon mapping & path tracing - couldn't these (oversimplified) be described as casting additional rays (in a particular manner)? Or am I confusing the basic act of "ray casting" with a specific use of ray casting, that is considered "ray tracing"? Is there consensus on the meaning of "ray tracing"? ToolmakerSteve ( talk) 07:36, 27 October 2012 (UTC)
The section /info/en/?search=Ray_tracing_(graphics)#Bounding_volumes would be far more understandable to non-mathamaticians if there was an illustration of the pieces that make up the bounding volume.
Hardware raytracing is just a subtopic of raytracing Ethanpet113 ( talk) 04:20, 20 April 2019 (UTC)
The last paragraph of the introduction has this sentence: "In fact, any physical wave or particle phenomenon with approximately linear motion can be simulated with ray tracing." I am wondering what would be an example of a physical phenomenon that behaves nonlinearly? I am wondering if there is a phenomenon that behaves in a spiral shape or something else? ScientistBuilder ( talk) 02:14, 27 January 2022 (UTC)ScientistBuilder ScientistBuilder ( talk) 02:14, 27 January 2022 (UTC)
I would like to add this source https://reference.wolfram.com/language/tutorial/PhysicallyBasedRendering.html. It would be good to add a few details about the limitations of ray tracing. ScientistBuilder ( talk) 21:08, 27 January 2022 (UTC)ScientistBuilder ScientistBuilder ( talk) 21:08, 27 January 2022 (UTC)
Is there a way to measure how much more computing power is needed for every increase in resolution? I am curious about this part of the Disadvantages section: "A serious disadvantage of ray tracing is performance (though it can in theory be faster than traditional scanline rendering depending on scene complexity vs. number of pixels on-screen). Until the late 2010s, ray tracing in real time was usually considered impossible on consumer hardware for nontrivial tasks." given a finite amount of computing power, which is more realistic: a lower resolution image with more ray tracing calculations done or a higher resolution image (4k for example) with reduced ray tracing calculations? Is there a way to approximate using Big O or asymptotic notation the number of additional calculations needed? ScientistBuilder ( talk) 21:12, 27 January 2022 (UTC)ScientistBuilder ScientistBuilder ( talk) 21:12, 27 January 2022 (UTC)
An editor has identified a potential problem with the redirect
Ray tracing (graphics and has thus listed it
for discussion. This discussion will occur at
Wikipedia:Redirects for discussion/Log/2022 October 27#Ray tracing (graphics until a consensus is reached, and readers of this page are welcome to contribute to the discussion.
Steel1943 (
talk)
19:24, 27 October 2022 (UTC)
It turns out that ray tracing in the most common form is reminiscent of the emission theory as set forth by Greek philosophers, notably Empedocles. This ancient, now scientifically obsolete theory postulated that our eyes emitted rays lighting up things for us to see. Remember, Empedocles was the same man who theorized that everything was composed of air, earth, fire, and water, with love pulling the elements together and hate tearing them apart. In his theory of light, the fire in our heads emitted beams that would bounce off objects before entering the eye again. Essentially, our eyes were like flashlights. Never mind that a startling number of people continue to adhere to the obsolete theory. It has been pointed out that it has practical use in computer graphics as recursive ray tracing since it is computationally orders of magnitude more efficient than to have the light sources emitting rays in all directions, most of which never reach the camera. Does this mention have a place in the article, perhaps under history? Free Media Kid$ 15:54, 16 November 2022 (UTC)
Section uses acronym "BVH" without that being defined. Marcusmueller ettus ( talk) 14:18, 16 January 2023 (UTC)