Talk:Ray tracing (graphics)

message: This page is perhaps too specific.
* Ray tracing itself is not concerned with rendering, only ray-object intersections. Shading models (phong, etc) are not a part of ray tracing.
* Most renderers now use a hybrid solution e.g a fast scan-line or REYES algorithm to "draw" the visible parts, and ray tracing to determine shadows, reflections, and refrations. They often even allow selection between ray tracing and faster but more primitive methods (e.g shadow/environment maps) on a per-light/material basis.
* Ray tracing is even used in various radiosity implementations to determine the contribution of one patch on another. In this capacity it's simply used to determine visibility, much like light rays in a traditional ray tracer. 
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 
:"Ray tracing itself is not concerned with rendering, only ray-object intersections. Shading models (phong, etc) are not a part of ray tracing."
:Not sure I agree. Ray tracing is the process of rendering an image by tracing rays through a scene and seeing how the energy propegates. I think you are thinking about ray casting, not ray tracing.
:Maybe the article itself would benefit from having sections going into depth with the various issues with ray tracing, eg. the light transportation equation, trajectory splitting (eg. shadow rays), the monte carlo solution to light transport, the various basic sampling methods and their variance and uniformity, and possible even a section describing quasi-monte carlo sampling. --Kolibri 13:17, 19 October 2005 (UTC)
replies: text: I agree with Kolibri that having sections regarding issues of raytracing should have their own section within the article, but I think that particularly large portions (Monte Carlo) should have their own article. Right now, this article needs some formating; it is not very well organized. --Osmaker 19:21, 20 October 2005 (UTC)
thread_title: Too specific for subject?

message: 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 
:The link is to a page entirely about ray tracing, comparing equivalent ray tracers written in different languages. The page includes and links to further pages that contain detailed information about the construction of these programs and explanations of how they act as ray tracers. The page also acts as a language comparison specifically in the context of ray tracing. - Jon Harrop -- —Preceding unsigned comment added by 80.229.56.224 (talk • contribs) 22:36, 31 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)
thread_title: Possible linkspam

message: 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)
thread_title:  Ray coherence 

message: 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)
replies: text: No problem. I only asked because I wasn't sure. Nobody else seems to feel strongly about it, so it might as well stay. Yes, by all means be bold in editing! In retrospect, I agree the math was correct except for the omission of the sign for dot product. It confused the heck out of me, though, because there was nothing at the beginning to indicate that the quantities indicated were vectors.--Srleffler 04:14, 16 February 2006 (UTC)

text: t=\frac{-(2\mathbf{V}\cdot\mathbf{d})\pm\sqrt{(2\mathbf{V}\cdot\mathbf{d})^2-4(\mathbf{d}^2)(\mathbf{V}^2-r^2)}}{2(\mathbf{d}^2)}\ 
Unless t (time) can be negative, there will be either one or no solutions at all.
--Niks 11:34, 2 April 2007 (UTC)
thread_title: Example

message: 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)
thread_title:  Added Simple Example of Algorithm 

message: 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)
thread_title: External trimmage 

message: 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)
replies: text: Well, I'm pretty sure that this is the "most common" use. So the best thing to do would probably be to create Ray tracing (disambiguation), link it from the header, and point to the other uses there. Adam McCormick (talk) 13:17, 18 April 2008 (UTC)
thread_title: Should be renamed Optical Ray Tracing 

message: 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)
thread_title:  Mention Raytracing is an Embarassingly Parallel Algo? 

message: 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
:I've removed the offending text and replied on the user's talk. Adam McCormick (talk) 13:24, 18 April 2008 (UTC)
replies: text: That is completely wrong. Global illumination with a ray tracer is possible, and works by recursing upon contact with a diffuse surface. This models the effect of light scattering off of diffuse surfaces, and it works great. Timrb (talk) 08:40, 22 May 2008 (UTC)

text: Yes, as the writer of that part, reflection from diffuse surfaces does indeed happen. See Diffuse reflection and Diffuse Shading. --Kolibri (talk) 12:05, 9 January 2010 (UTC)
thread_title:  Possible misleading figure PathOfRays.svg 

message: 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)
replies: text: I could agree with that, if physics is the major other use and you have some expertise in the matter feel free to be WP:BOLD and pull some content for physics. I'd be happy to help reorganize and clean up. Adam McCormick (talk) 13:20, 18 April 2008 (UTC)

text: The split was a great idea -- thanks for that!  —Preceding unsigned comment added by 99.251.254.165 (talk) 18:50, 23 April 2008 (UTC)
thread_title: Suggest separating into two articles

message: 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)
replies: text: Ray tracing is a common technique in optics, and this is the primary and original use of this technique. Any physicist or optical engineer who writes "ray tracing" will expect it to link to the other article. The problem here is that the person who moved the page and created the disambiguation page should have gone through all of the links to the dab page and corrected them to point to the appropriate article. The correct solution here is not to move the article back, but to fix the links. On the other hand, dab pages are not supposed to have only two entries. Disambiguation with only two articles is handled via redirects and hattext. I'll fix it.--Srleffler (talk) 17:24, 29 May 2008 (UTC)
replies: text: OK, done. Variations of Ray tracing link here. Ray tracer and Ray trace link to the physics article. Someone still should go through all of the links and ensure that they point to the correct article.--Srleffler (talk) 17:35, 29 May 2008 (UTC)

text: I don't agree with that, ray tracer is the name given to the vast majority of raytracing graphics renderers, and I think that this page is still the most likely thing being referenced when someone wikilinks ray tracer. Adam McCormick (talk) 19:36, 29 May 2008 (UTC)
replies: text: I've gone through all the links to Ray tracing and only about 15 of the 110 or were used in a physics context so I've changed them to point to the graphics article directly. I think ray tracer is probably similar in that it is used in more graphics articles than physics articles. In fact, of the six links, none are physics-based, so I'm going to point it here not there. Adam McCormick (talk) 20:24, 29 May 2008 (UTC)
replies: text: OK. Thanks for checking and updating links.--Srleffler (talk) 22:25, 29 May 2008 (UTC)

text: The following discussion is an archived discussion of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section. 
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)
thread_title: Page move broke everything

message: 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)
thread_title: Unfocused Article

message: 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)
replies: text: I converted the first two to proper refs using Template:cite journal and Template:cite web.  Take a look at those for what other parameters are available, and do a few more; let me know here if you need help. Dicklyon (talk) 04:50, 12 June 2008 (UTC)
thread_title:  Cdecoro's section rewrite 

message: 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)
thread_title:  Complete re-write coming 

message: 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)
thread_title:  Calculations are wrong 

message: 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)
replies: text: If p is the direction of the incident ray and q is the surface normal (both being unit vectors), then the reflected ray's direction is p - 2*(p·q)*q, if I remember right, where p·q is a dot product. —Tamfang (talk) 03:47, 13 July 2009 (UTC)
thread_title:  Calculation for beginners 

message: 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)
thread_title:  [[Foveated_imaging]] 

message: 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)
thread_title:  To what rendering algorithm class does ray tracing belong? 

message: 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)
thread_title:  example image does not meet WP standards 

message: 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)
replies: text: I disagree too, and have discussed this unilateral move with him at User_talk:Thumperward#Ray_tracing.  Thumperward, I request that you put it back to where it was and make a two-way disambig page.  Dicklyon (talk) 05:23, 9 December 2011 (UTC)

text: Actually, I was able to move it back myself.  But "Ray tracing (disambiguation)" is not as easy to move back to "Ray tracing" now.  I notice their are several articles linking to Ray tracing from when it was a disambig, which is wrong, but they include both meanings; some disambiguating of links is in order.   Dicklyon (talk) 05:25, 9 December 2011 (UTC)
replies: text:  Having a disambiguation page for two links is actively harmful. I can just about see the rationale behind leaving the root title as a redirect to one of the two topics, though as I've said to Dicklyon I consider this to be a distinctly minority reading of the weight of the "primary importance" section of WP:PRIMARYTOPIC, but a disambiguation page simply means that rather than inconveniencing 50% (say) of readers with an additional mouse click to get to their desired page we inconvenience 100% of readers. Article titles are a means to an end and are not canonical representations of importance. Similarly, dab pages are technical matters of convenience and not arbitrators of equality. Chris Cunningham (user:thumperward) (talk) 07:30, 9 December 2011 (UTC)
replies: text: You appear to be in conflict with the policy you cite, so I suggest you take it up there if you want a change in policy. I have no preference either way, but you've shot yourself in the foot here. GDallimore (Talk) 12:43, 9 December 2011 (UTC)
replies: text:  I'm not even sure that comment was supposed to be addressed to me, such is the level of vagueness. Who and what is in conflict with what part of what policy? Chris Cunningham (user:thumperward) (talk) 12:45, 9 December 2011 (UTC)
replies: text: You're the only person citing policies and you're the only person to be misrepresenting them in your comments: "if an ambiguous term is considered to have no primary topic, then that term should lead to a disambiguation page". GDallimore (Talk) 12:54, 9 December 2011 (UTC)
replies: text:  I'm not arguing that there's no primary topic. I am arguing that of the two methods given at WP:PRIMARYTOPIC, it is far more useful to optimise for usage and thus readers (who are over six times more likely to visit the graphics page than the physics page) than for alleged importance, and thus nobody. Of the two methods, the former strongly indicates that the graphics article is the primary topic, while the latter has no consensus. We should therefore consider the graphics page to be primary. My comments should be taken in that light. As to the current situation, where the root title redirects to the graphics page, I feel that it may have some diplomatic value in hopefully placating physicists upset with the idea of usage being favoured over importance, though I'd be just as happy with the graphics page being at the root title personally. Chris Cunningham (user:thumperward) (talk) 13:12, 9 December 2011 (UTC)
thread_title:  Disagree with move. 

message: 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)
replies: text: Well, it's wrongish in that it's already in :Category:Global illumination algorithms, which is itself a member of :Category:Computer graphics algorithms. —Tamfang (talk) 07:03, 27 October 2012 (UTC)
replies: text: That doesn't make it "wrongish", it makes it plain wrong. Removed. GDallimore (Talk) 16:57, 27 October 2012 (UTC)
thread_title:  I've added Category:Computer graphics algorithms 

message: 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)
replies: text: According to the wiki article on ray casting, I am not confusing the two. Paraphrasing, "ray casting" refers to a technique WITH NO RECURSION (no secondary rays). As soon as there is recursion / secondary rays, a technique is categorized as a "ray tracing" technique. Therefore, these advanced Global Illumination (GI) algorithms that are mentioned, fall into the category of "ray tracing techniques". That is, they are algorithms, one of whose central characteristics is, they involve secondary rays. Therefore, I consider the sentence "Other methods, including photon mapping, are based upon ray tracing for certain parts of the algorithm, yet give far better results." to be inappropriately placed in the disadvantages section. What I mean is, this is *NOT* a "disadvantage of ray-tracing". Indeed, there is no such thing as photon mapping WITHOUT ray-tracing. So I am going to be bold, and instead reword this as a need to EXTEND ray-tracing with additional algorithms. ToolmakerSteve (talk) 07:44, 27 October 2012 (UTC)
replies: text:  I am now going to go even further, and reference a recent GI technique, that is not generally (AFAIK) classified as a ray tracing technique, though it involves ray casting. To me, it falls in a grey area (classification-wise). But again, I'm not an expert -- perhaps I am over-relying on the radically different implementation approach (parallel projection; rasterization; depth peeling). Perhaps underneath, the mathematics SHOULD categorize this as a ray-tracing technique. The bottom line is that this single paper fundamentally altered my personal understanding of how to approach high-performance GI. It challenged my underlying assumptions (as a technical evaluator examining competing vendors and future directions) of the discussion of "rasterization techniques versus ray-tracing techniques", as we attempt to have more realistic lighting in computer graphics. The existence of such a technique to me is fundamentally important in discussing pros and cons of rasterization and ray-tracing, hence my attempt to insert it into this discussion.  http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter38.html ToolmakerSteve (talk) 08:07, 27 October 2012 (UTC)
replies: text:  And for anyone who is skeptical that the above paper does describe a true GI approach (when I first read it, it seemed "too good to be true"), here are the two images that together I found compelling  http://www.bee-www.com/parthenon/stairs.png and  http://www.bee-www.com/parthenon/ibl_sample2.png  and the page containing downloadable code and other images http://www.bee-www.com/parthenon/ ToolmakerSteve (talk) 08:34, 27 October 2012 (UTC)
thread_title:  Disadvantages clarity 

message: Hardware raytracing is just a subtopic of  raytracing Ethanpet113 (talk) 04:20, 20 April 2019 (UTC)
replies: text: My view is that WP:BOLD merge not be appropriate as the references suggest that there is evidence for independent notability. Therefore, proposing first, giving a reason for the proposal and starting a discussion, is the way forward as per WP:MERGEPROP. My view would then be against a merge unless the argument was strong. Klbrain (talk) 09:25, 8 April 2020 (UTC)
thread_title:  Proposed merge with [[Ray-tracing hardware]] 

message: 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)
thread_title: Ray Tracing can be applied to any phenomenon that behave linearly

message: 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)
thread_title: Limitations of Ray Tracing Source Addition without Copyright Infringement from Close Paraphrasing

message: 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)
thread_title: Disadvantages

message: 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)
thread_title:  "Ray tracing (graphics" listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]] 

message: 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? FreeMediaKid$ 15:54, 16 November 2022 (UTC)
thread_title:  Emissions theory of sight 

message: Section uses acronym "BVH" without that being defined. Marcusmueller ettus (talk) 14:18, 16 January 2023 (UTC)
thread_title:  Interactive Ray Tracing: What's BVH?