<p>Im not a professional computer graphics programmer, I'm just learning. All the tutorials I've seen so far about ray tracing have one thing in common, that in order to get good visual results they need to cast thousands of rays in random directions from each pixel of the final input and bounce them around.</p>
<p>My question is: Why not cast only 4 and say &quot;These 4 lines form a parallelepiped(a rectangle extruded into the 3rd dimension) and every line inside this parallelepiped is considered a ray that contributes to the final color of this pixel.</p>
<p>At the first iteration, a  parallelepiped will hit a triangle called &quot;T1&quot; (assuming all your meshes are made out of triangles) and change the geometry(on geometry shaders) of triangle T1. The triangle T1 will be split into 2 polygons: 1 that was hit by light, and one that hasnt been. These polygons can then be diveded into an array of triangles Lets call this array &quot;T2&quot;. This way, only 1 little triangle inside the T2 array will contain all the light and there woudnt be any point inside the little triangle that is not hit by light. Lets call this little triangle T3. All you have to do now, is reflect the triangle T3 to start the second iteration. The difference is that now, at the second iteration, you will have to reflect all the little triangles T3 from every triangle T1 that has been hit by light at iteration 1.</p>
<p>With this technique, you would arrive at the nth iteration with a list of triangles that have all the light in the scene. All you need now is to convert those triangles to actual pixels on the screen and add them to the final color. It just seems faster to me to work with the geometric equation of a line 4 times, than to work with thousands of rays.</p>
<p>What do you think?</p>

CC BY-SA 4.0
2022-10-20T15:30:23.067Z
"*These 4 lines form a parallelepiped(a rectangle extruded into the 3rd dimension) and every line inside this parallelepiped is considered a ray that contributes to the final color of this pixel.*" Because parallelepipeds are not *rays*. Ray tracing is used because ray/thing intersection tests are *cheap* compared to doing volume/thing. tests. They also result in a single point, not a bunch of points that you then have to average together.
Nicol Bolas
CC BY-SA 4.0
2022-10-20T15:36:05.500Z
Checking if 4 points are inside a triangle, or if a triangle is inside 4 points, or if only some of the points are inside a shape seems way more easier than to check if thousands of rays are inside a triangle. Dont you think?
Robert Puscasu
CC BY-SA 4.0
2022-10-20T15:38:54.727Z
"*Checking if 4 points are inside a triangle*" That's not how parallelepiped collision checks work. And actually computing the collision area is much harder. Also, one of the advantages of raytracing is that it's not limited to triangles.
Nicol Bolas
CC BY-SA 4.0
2022-10-20T15:40:21.290Z
Yes it is, because that parallelepiped stops extruding once it hits the triagle, and thus, the triangle can only intersect with 1 side of the parallelepiped. So the triangle only hits a polygon.
Robert Puscasu
CC BY-SA 4.0
2022-10-20T15:43:08.060Z
"*Yes it is, because that parallelepiped stops extruding once it hits the triagle*" Only if the entire parallelepiped is obstructed by a single triangle. But that's going to be very rare. Each triangle that partially obstructs it will break it up into a more complex shape. Thus adding to the complexity of subsequent tests.
Nicol Bolas
CC BY-SA 4.0
2022-10-20T15:44:42.997Z
Just think about the 2D equivalent. You have a triangle being extruded outward from some point. At first, you're extruding a line. But once you intersect with something else, you're now extruding a smaller line or two *separate* lines if the object you hit was in the middle of your extrusion. And this goes on and on and on, increasing the complexity of each calculation for each object hit.
Nicol Bolas
CC BY-SA 4.0
2022-10-20T15:45:10.227Z
"Each triangle that partially obstructs it will break it up into a more complex shape" Exactly! Now you get it. And isnt that better? Because you could code it to stop iterations once a certain complexity is achieved.
Robert Puscasu
CC BY-SA 4.0
2022-10-20T15:47:35.760Z
"*Because you could code it to stop iterations once a certain complexity is achieved.*" Each "iteration" in this example is an object collision. If you stop iterations, then you stop testing against objects in the scene. So that means some objects will appear and disappear based on non-local factors (how many other objects happened to be near enough to cause iteration to stop). This is not good.
Nicol Bolas
CC BY-SA 4.0
2022-10-20T15:52:13.897Z
That's not what i meant. What i meant was "you can code the algorithm to stop splitting triangles into smaller triangles once the triangle area gets smaller than a given area( for example, the area of 1 pixel, calculated to be in accordance to the distance between that triangle and the camera.) That way, your little triangles will always be just a little smaller than a given area (a pixel).
Robert Puscasu
CC BY-SA 4.0
2022-10-20T15:56:26.413Z
The "complexity" that I was talking about is the complexity of the increasingly complex shapes you will be colliding with. Your parallelepiped is only such a shape *once*; after each intersection, it becomes an increasingly more complex shape. And each increase in shape complexity has *exponentially increasing* intersection testing costs. It's no long a simple "square over triangle" test.
Nicol Bolas
CC BY-SA 4.0
2022-10-20T15:58:24.743Z
I agree with everything you just said, but there is 1 thing i havent explained it yet. Im editing my response right now.
Robert Puscasu
CC BY-SA 4.0
2022-10-20T16:16:23.933Z
In my algorithm we can use the fact that ray tracing is used with PBR to our advantage. In PBR, every triangle has a property named roughness. That tells you how scattered is the reflection. https://learnopengl.com/img/pbr/microfacets_light_rays.png . I told you before that the you can think of my algorithm as a parallelepiped that starts from the screen and gets extruded until it hits a triangle. But when roughness is different than 0, the parallelepiped also gets scaled up the father it goes.( think of a flashlight). 

(Comment is too long, second part is coming)
Robert Puscasu
CC BY-SA 4.0
2022-10-20T16:16:33.447Z
And the power of a flashlight per square inch gets quadratically smaller according to this physical law http://hyperphysics.phy-astr.gsu.edu/hbase/Forces/imgfor/isqrr.gif. Thus, after only a few iterations, the light power of a parallelepiped gets really small and we can stop bouncing it, while classic raytracing needs thousands of bounces. In short, i think(but im not sure) that my algorithm converges way faster due to the Inverse Square Law for Light.
Robert Puscasu
CC BY-SA 4.0
2022-10-20T16:17:46.333Z
"*In PBR, every triangle has a property named roughness.*" Um, no, it does not. *Parts* of a surface have roughness, but PBR does not require that this is a per-triangle property. There is no reason that it cannot be fetched from a texture access (and indeed, a *lot* of PBR implementations do precisely that).
Nicol Bolas
CC BY-SA 4.0
2022-10-20T16:19:37.407Z
And, again, I am not talking about bouncing, reflections, or anything of that nature. We're just talking about parallelepiped vs. scene intersection tests. It is not just one test vs. a single triangle. Once it hits the nearest triangle, the *rest of the* extruded shape (the part of the shape that *didn't* hit that particular triangle) has to continue on and test against *other triangles*. And that shape is no longer a "simple" square. That is what makes it complicated: the shape becomes increasingly complex and thus intersection tests become increasingly complex.
Nicol Bolas
CC BY-SA 4.0
2022-10-20T16:25:07.417Z
"Um, no, it does not. Parts of a surface have roughness, but PBR does not require that this is a per-triangle property." I admit, you got me with that one. Didnt think about it. The only thing i can think about is maybe you can calculate the average roughness of that triangle and use that.
" And that shape is no longer a simple square." I agree. Its a square divided into triangles. And those triangles can be generated on the fly on a geometry shader and disregarded when they emit too little light, or when they become too small. I 100% agree that the number of triangles grows exponentially
Robert Puscasu
CC BY-SA 4.0
2022-10-20T16:25:33.990Z
But i was thinking that you tell the algorithm" stop once you have more than N triangles". And i was also thinking that maybe, the number of bounces is much smaller thanks to the inverse square law.
Robert Puscasu
CC BY-SA 4.0
2022-10-20T16:30:54.290Z
"*disregarded when they emit too little light, or when they become too small.*" Why do you feel that size is the principle issue with performance here? It doesn't take too many intersections for the complexity of the extruded surface's subsequent intersection costs to *vastly* exceed just doing raytracing.
Nicol Bolas
CC BY-SA 4.0
2022-10-20T16:45:53.687Z
Because at each iteration, a parallelepiped will only divide a small number of triangles out the entire scene(only the visible ones) And you can tell the algorithm to stop dividing once the size is smaller then the area of pixel.
Area of a pixel explained: Imagine being a cube looking at the camera that is 10 units away. You say "that rectangle(the screen) is 10 units away and it ocupies 10% of my screen if i WERE(but im not) to render the scene from my perspective. it has 1920*1080 pixels so the area that each pixels fills in the world can be is X units." Thats the "area" of a pixel.
Robert Puscasu
CC BY-SA 4.0
2022-10-20T16:49:25.513Z
Basically, i want to treat light in a scene as a quantity(a liquid) that is infinitily divisible in (theory), while classic ray tracing treats it as a number of particles.
Robert Puscasu
CC BY-SA 4.0
2022-10-20T16:57:44.593Z
Does this thing sound in any way debatable or reasonable to you? If yes, then i would like to keep debating you on a different platform because here i have a warning that i shouldn't keep making the discussion larger. Since i don't know what platforms you use, this is my LinkedIn: https://www.linkedin.com/in/robert-antonie-puscasu-24ab16138/
Robert Puscasu
CC BY-SA 4.0
2022-10-20T16:58:21.920Z
Where is the efficiency gain? None of the intersection tests you're talking about are cheap. They are *way* more expensive than ray/triangle tests. They're way more expensive than the culling used for culling groups of triangles in ray/triangle tests. Half as many tests at 10x the cost per test is still more expensive (and that "half" is a generous estimate).
Nicol Bolas
CC BY-SA 4.0
2022-10-20T17:01:40.730Z
Iteration 1: a parallelepiped hits N triangles in a scene(only the visible ones from its perspective). And divides them acordingly. These triangles would fill the entire screen and nothing more if you were to move them towards the camera. So no waste of resources here.
Iteration 2: Now you have to go trhough all of those visible triangles and for each: the strength of the light reflected gets smaller as its area gets bigger( thanks to the inverse square law). It hits only the visible triangles from its perspective.
...
Iteration 10: By now, the light strength is so low, we can stop caring.
Robert Puscasu
CC BY-SA 4.0
2022-10-20T17:07:33.363Z
See for example: https://www.researchgate.net/publication/220852839_A_Real-time_Beam_Tracer_with_Application_to_Exact_Soft_Shadows as well as the references inside. Finite element methods (e.g. radiosity) also work in a somewhat similar manner to what you describe. Also see cone tracing.
lightxbulb
CC BY-SA 4.0
2022-10-20T17:09:40.413Z
At every iteration, we have only interacted with the triangles that contribute to the final color. The strength of their reflections decrease quadratically so the algorithm converges fast to the final color. Instead of dealing with 1000 rays sent in the same direction from each pixel, we solved everything by carrying with us the equation for the parallelepiped that surrounds all of them. 4 lines instead of 1000 particles.
Robert Puscasu
CC BY-SA 4.0
2022-10-20T17:21:19.530Z
@NicolBolas colision test:
case 1: every point of the triangle is inside the parallelepiped face(which is also a triangle even though ive been calling it a parallelepiped  face). color the entire triangle |
case 2: every point of the parallelepiped  face is inside the triangle: make a hole in the shape of the parallelepiped face in the triangle and divide the rest into triangles |
case 3: 2 points of a triangle are inside another triangle. Calculate the 2 points where the triangles intersect, and those points are the border. Use it to divide the triangle of the mesh |
case 4: similar to 3
Robert Puscasu
CC BY-SA 4.0
2022-10-20T17:36:08.603Z
@RobertPuscasu: "*At every iteration, we have only interacted with the triangles that contribute to the final color*" That's where magic has to happen. Given a scene of some number of triangles, you first must figure out *which* triangles "interact" with the parallelepiped. *That's the expensive part*. That's the part which is way more expensive than tracing rays.
Nicol Bolas
CC BY-SA 4.0
2022-10-20T17:54:58.230Z
For ray tracing you check whether 1 point is inside a triangle
For my algorithm you check whether 1 triangle has 2 or 3 points inside another triangle. Whatever magic you use for normal ray tracing, use it for this algorithm as well. Im not going to claim i know the best colision test idea on the spot. The only thing that changes is the number of triangles you have, which keeps growing the more iterations you do.
My entire point is that light strength decreases quadratically, which should converge much faster than adding each ray in classic ray tracing.
Robert Puscasu
CC BY-SA 4.0
2022-10-20T18:05:19.187Z
@RobertPuscasu: "*For ray tracing you check whether 1 point is inside a triangle*" In 3D, you have to find the intersection between a ray and a triangle; this is a point in 3D space. You do this for all triangles "nearby" the ray via some spatial partitioning scheme. And then you take the closest one. Your algorithm has to do the equivalent, but it needs different "closest triangles" for different parts of the parallelepiped. That's the hard part.
Nicol Bolas
CC BY-SA 4.0
2022-10-20T18:12:23.653Z
I thank you for your time. Since i dont have an answer right now, im gonna say "dont know".
Robert Puscasu
CC BY-SA 4.0
2022-10-21T05:06:23.600Z
You should check the drawbacks of cone-tracing as lightxbulb mentioned, same would apply to your technique. The main problem is as Nicol said, intersection test would be expensive plus a plethora of possibilities arising because now it's not a point that results in an intersection but whole/partial areas.
gallickgunner
CC BY-SA 4.0
2022-10-22T16:27:16.830Z
Hi, Robert! Welcome to the site. Note: at 20 reputation points you earn the [chatroom privilege](https://computergraphics.stackexchange.com/help/privileges). And we'd love to see more open ended discussions in [our chatroom](https://chat.stackexchange.com/rooms/26589/the-cornell-box). I can't turn off the automatic message about discussion in comments, but I can choose to ignore it since everybody's being nice and constructive. No harm, no foul. But, remember we do have a chatroom available.
luser droog
CC BY-SA 4.0
2022-10-23T19:04:23.410Z
what you are describing sounds a lot like how the reyes rasterizing algorithm used by pixar used to work.
joojaa
<raytracing>
Is this algorithm a variation of ray tracing worth something?
Robert Puscasu
# Is this algorithm a variation of ray tracing worth something?

(Asked by: username_0 on 2022-10-20)

Im not a professional computer graphics programmer, I'm just learning. All the tutorials I've seen so far about ray tracing have one thing in common, that in order to get good visual results they need to cast thousands of rays in random directions from each pixel of the final input and bounce them around.

My question is: Why not cast only 4 and say "These 4 lines form a parallelepiped(a rectangle extruded into the 3rd dimension) and every line inside this parallelepiped is considered a ray that contributes to the final color of this pixel.

At the first iteration, a parallelepiped will hit a triangle called "T1" (assuming all your meshes are made out of triangles) and change the geometry(on geometry shaders) of triangle T1. The triangle T1 will be split into 2 polygons: 1 that was hit by light, and one that hasnt been. These polygons can then be diveded into an array of triangles Lets call this array "T2". This way, only 1 little triangle inside the T2 array will contain all the light and there woudnt be any point inside the little triangle that is not hit by light. Lets call this little triangle T3. All you have to do now, is reflect the triangle T3 to start the second iteration. The difference is that now, at the second iteration, you will have to reflect all the little triangles T3 from every triangle T1 that has been hit by light at iteration 1.

With this technique, you would arrive at the nth iteration with a list of triangles that have all the light in the scene. All you need now is to convert those triangles to actual pixels on the screen and add them to the final color. It just seems faster to me to work with the geometric equation of a line 4 times, than to work with thousands of rays.

What do you think?

**Tags:** raytracing

> **Comments:**
> **username_1**: "*These 4 lines form a parallelepiped(a rectangle extruded into the 3rd dimension) and every line inside this parallelepiped is considered a ray that contributes to the final color of this pixel.*" Because parallelepipeds are not *rays*. Ray tracing is used because ray/thing intersection tests are *cheap* compared to doing volume/thing. tests. They also result in a single point, not a bunch of points that you then have to average together.  
> **username_0**: Checking if 4 points are inside a triangle, or if a triangle is inside 4 points, or if only some of the points are inside a shape seems way more easier than to check if thousands of rays are inside a triangle. Dont you think?  
> **username_1**: "*Checking if 4 points are inside a triangle*" That's not how parallelepiped collision checks work. And actually computing the collision area is much harder. Also, one of the advantages of raytracing is that it's not limited to triangles.  
> **username_0**: Yes it is, because that parallelepiped stops extruding once it hits the triagle, and thus, the triangle can only intersect with 1 side of the parallelepiped. So the triangle only hits a polygon.  
> **username_1**: "*Yes it is, because that parallelepiped stops extruding once it hits the triagle*" Only if the entire parallelepiped is obstructed by a single triangle. But that's going to be very rare. Each triangle that partially obstructs it will break it up into a more complex shape. Thus adding to the complexity of subsequent tests.  
> **username_1**: Just think about the 2D equivalent. You have a triangle being extruded outward from some point. At first, you're extruding a line. But once you intersect with something else, you're now extruding a smaller line or two *separate* lines if the object you hit was in the middle of your extrusion. And this goes on and on and on, increasing the complexity of each calculation for each object hit.  
> **username_0**: "Each triangle that partially obstructs it will break it up into a more complex shape" Exactly! Now you get it. And isnt that better? Because you could code it to stop iterations once a certain complexity is achieved.  
> **username_1**: "*Because you could code it to stop iterations once a certain complexity is achieved.*" Each "iteration" in this example is an object collision. If you stop iterations, then you stop testing against objects in the scene. So that means some objects will appear and disappear based on non-local factors (how many other objects happened to be near enough to cause iteration to stop). This is not good.  
> **username_0**: That's not what i meant. What i meant was "you can code the algorithm to stop splitting triangles into smaller triangles once the triangle area gets smaller than a given area( for example, the area of 1 pixel, calculated to be in accordance to the distance between that triangle and the camera.) That way, your little triangles will always be just a little smaller than a given area (a pixel).  
> **username_1**: The "complexity" that I was talking about is the complexity of the increasingly complex shapes you will be colliding with. Your parallelepiped is only such a shape *once*; after each intersection, it becomes an increasingly more complex shape. And each increase in shape complexity has *exponentially increasing* intersection testing costs. It's no long a simple "square over triangle" test.  
> **username_0**: I agree with everything you just said, but there is 1 thing i havent explained it yet. Im editing my response right now.  
> **username_0**: In my algorithm we can use the fact that ray tracing is used with PBR to our advantage. In PBR, every triangle has a property named roughness. That tells you how scattered is the reflection. https://learnopengl.com/img/pbr/microfacets_light_rays.png . I told you before that the you can think of my algorithm as a parallelepiped that starts from the screen and gets extruded until it hits a triangle. But when roughness is different than 0, the parallelepiped also gets scaled up the father it goes.( think of a flashlight).   (Comment is too long, second part is coming)  
> **username_0**: And the power of a flashlight per square inch gets quadratically smaller according to this physical law http://hyperphysics.phy-astr.gsu.edu/hbase/Forces/imgfor/isqrr.gif. Thus, after only a few iterations, the light power of a parallelepiped gets really small and we can stop bouncing it, while classic raytracing needs thousands of bounces. In short, i think(but im not sure) that my algorithm converges way faster due to the Inverse Square Law for Light.  
> **username_1**: "*In PBR, every triangle has a property named roughness.*" Um, no, it does not. *Parts* of a surface have roughness, but PBR does not require that this is a per-triangle property. There is no reason that it cannot be fetched from a texture access (and indeed, a *lot* of PBR implementations do precisely that).  
> **username_1**: And, again, I am not talking about bouncing, reflections, or anything of that nature. We're just talking about parallelepiped vs. scene intersection tests. It is not just one test vs. a single triangle. Once it hits the nearest triangle, the *rest of the* extruded shape (the part of the shape that *didn't* hit that particular triangle) has to continue on and test against *other triangles*. And that shape is no longer a "simple" square. That is what makes it complicated: the shape becomes increasingly complex and thus intersection tests become increasingly complex.  
> **username_0**: "Um, no, it does not. Parts of a surface have roughness, but PBR does not require that this is a per-triangle property." I admit, you got me with that one. Didnt think about it. The only thing i can think about is maybe you can calculate the average roughness of that triangle and use that. " And that shape is no longer a simple square." I agree. Its a square divided into triangles. And those triangles can be generated on the fly on a geometry shader and disregarded when they emit too little light, or when they become too small. I 100% agree that the number of triangles grows exponentially  
> **username_0**: But i was thinking that you tell the algorithm" stop once you have more than N triangles". And i was also thinking that maybe, the number of bounces is much smaller thanks to the inverse square law.  
> **username_1**: "*disregarded when they emit too little light, or when they become too small.*" Why do you feel that size is the principle issue with performance here? It doesn't take too many intersections for the complexity of the extruded surface's subsequent intersection costs to *vastly* exceed just doing raytracing.  
> **username_0**: Because at each iteration, a parallelepiped will only divide a small number of triangles out the entire scene(only the visible ones) And you can tell the algorithm to stop dividing once the size is smaller then the area of pixel. Area of a pixel explained: Imagine being a cube looking at the camera that is 10 units away. You say "that rectangle(the screen) is 10 units away and it ocupies 10% of my screen if i WERE(but im not) to render the scene from my perspective. it has 1920*1080 pixels so the area that each pixels fills in the world can be is X units." Thats the "area" of a pixel.  
> **username_0**: Basically, i want to treat light in a scene as a quantity(a liquid) that is infinitily divisible in (theory), while classic ray tracing treats it as a number of particles.  
> **username_0**: Does this thing sound in any way debatable or reasonable to you? If yes, then i would like to keep debating you on a different platform because here i have a warning that i shouldn't keep making the discussion larger. Since i don't know what platforms you use, this is my LinkedIn: https://www.linkedin.com/in/username_0-antonie-username_0-24ab16138/  
> **username_1**: Where is the efficiency gain? None of the intersection tests you're talking about are cheap. They are *way* more expensive than ray/triangle tests. They're way more expensive than the culling used for culling groups of triangles in ray/triangle tests. Half as many tests at 10x the cost per test is still more expensive (and that "half" is a generous estimate).  
> **username_0**: Iteration 1: a parallelepiped hits N triangles in a scene(only the visible ones from its perspective). And divides them acordingly. These triangles would fill the entire screen and nothing more if you were to move them towards the camera. So no waste of resources here. Iteration 2: Now you have to go trhough all of those visible triangles and for each: the strength of the light reflected gets smaller as its area gets bigger( thanks to the inverse square law). It hits only the visible triangles from its perspective. ... Iteration 10: By now, the light strength is so low, we can stop caring.  
> **username_2**: See for example: https://www.researchgate.net/publication/220852839_A_Real-time_Beam_Tracer_with_Application_to_Exact_Soft_Shadows as well as the references inside. Finite element methods (e.g. radiosity) also work in a somewhat similar manner to what you describe. Also see cone tracing.  
> **username_0**: At every iteration, we have only interacted with the triangles that contribute to the final color. The strength of their reflections decrease quadratically so the algorithm converges fast to the final color. Instead of dealing with 1000 rays sent in the same direction from each pixel, we solved everything by carrying with us the equation for the parallelepiped that surrounds all of them. 4 lines instead of 1000 particles.  
> **username_0**: @username_1 colision test: case 1: every point of the triangle is inside the parallelepiped face(which is also a triangle even though ive been calling it a parallelepiped  face). color the entire triangle | case 2: every point of the parallelepiped  face is inside the triangle: make a hole in the shape of the parallelepiped face in the triangle and divide the rest into triangles | case 3: 2 points of a triangle are inside another triangle. Calculate the 2 points where the triangles intersect, and those points are the border. Use it to divide the triangle of the mesh | case 4: similar to 3  
> **username_1**: @username_0: "*At every iteration, we have only interacted with the triangles that contribute to the final color*" That's where magic has to happen. Given a scene of some number of triangles, you first must figure out *which* triangles "interact" with the parallelepiped. *That's the expensive part*. That's the part which is way more expensive than tracing rays.  
> **username_0**: For ray tracing you check whether 1 point is inside a triangle For my algorithm you check whether 1 triangle has 2 or 3 points inside another triangle. Whatever magic you use for normal ray tracing, use it for this algorithm as well. Im not going to claim i know the best colision test idea on the spot. The only thing that changes is the number of triangles you have, which keeps growing the more iterations you do. My entire point is that light strength decreases quadratically, which should converge much faster than adding each ray in classic ray tracing.  
> **username_1**: @username_0: "*For ray tracing you check whether 1 point is inside a triangle*" In 3D, you have to find the intersection between a ray and a triangle; this is a point in 3D space. You do this for all triangles "nearby" the ray via some spatial partitioning scheme. And then you take the closest one. Your algorithm has to do the equivalent, but it needs different "closest triangles" for different parts of the parallelepiped. That's the hard part.  
> **username_0**: I thank you for your time. Since i dont have an answer right now, im gonna say "dont know".  
> **username_3**: You should check the drawbacks of cone-tracing as username_2 mentioned, same would apply to your technique. The main problem is as username_1 said, intersection test would be expensive plus a plethora of possibilities arising because now it's not a point that results in an intersection but whole/partial areas.  
> **username_4**: Hi, username_0! Welcome to the site. Note: at 20 reputation points you earn the [chatroom privilege](https://computergraphics.stackexchange.com/help/privileges). And we'd love to see more open ended discussions in [our chatroom](https://chat.stackexchange.com/rooms/26589/the-cornell-box). I can't turn off the automatic message about discussion in comments, but I can choose to ignore it since everybody's being nice and constructive. No harm, no foul. But, remember we do have a chatroom available.  
> **username_5**: what you are describing sounds a lot like how the reyes rasterizing algorithm used by pixar used to work.  

---

## 0 answers

