Week 3 Entry - Ray Intersections

Rays - An Interpolation Recipe

A ray, while graphically presented similarly to a vector, is constructed with only one constant aspect consistent with a vector, direction. A vector is presented with a finite magnitude (length) and direction. A ray, however, is presented with a direction and a possibly infinite length. The mathematical representation of a ray that we utilize is an algebraically reorganized linear interpolation formula with the direction scalar as the sole unknown. The determination of the ray's length is based on the displacement provided by this scalar multiplication summed with the ray's origin. While we are utilizing the ray's direction only within the assumption of a positive, forward direction (scalar value greater than zero), the ray could theoretically be utilized to have a negative vector result.

Again, critical to remember is the result of a ray equation is a point and not a vector. The concept of a "point + displacement" results in a point being applied in this case. While the scalar value (in the below example shown as variable time, t) multiplied by the unit direction would result in the displacement or vector, by adding it to the ray's relative origin, we place the ray in a relative position and are provided a position from the origin along the ray's direction.

Intersection using Implicit Surfaces

Using the result of the above equation, a point along the direction of the ray, we can find where the ray could intersect with a surface. This process of finding an intersection can be easily applied using the application of an implicit surface. An implicit surface can be applied in code through an implicit equation. In the case of a sphere, we use the below equation with P_circle representing a point on the surface of the sphere, c representing the center point of the sphere, and r representing the radius value of the sphere.

This implicit equation, like those to create other vector-based other implicit surfaces, is based on the principle of a point being on the surface only if the equation equates to zero. Using this as a definitive way to provide the points on the surface, we can apply the ray equation by substituting "o + td" for the P_circle. Assuming that there in fact is an intersection between the ray and our surface, this equation will still return 0. We can use this concept to then solve for t (our scalar multiplier) to determine the distance (or time in the above case) the ray needed to travel before reaching this point on the surface. Other information that could be gathered once determining there is indeed an intersection includes the normal vector of the surface at that point, whether the origin of the vector is within the surface, or if this intersection is tangent to the surface.

Regularly Scheduled Struggle Bus

Actually, implementing the code for this concept was, pleasantly, fairly seamless and I didn't have too many complications. The most important issue I ran into involved the vector3.js implementation and being sure that I was not overriding my working vectors in circumstances where that was not intended. The clone() function quickly became a close friend. Unfortunately, this did make the code quickly less readable, and diagnosing the lack of this function was difficult without passionately following the debugger. This was especially important once I needed to overview my partner's code and found occurrences of the error where all other parts of a test's code were implemented correctly. 

Questions I found while implementing this process revolve greatly around real-time implementation. Given a light or field of view, even if just one ray represents it as used here, how would the calculations be handled if the direction and origin of the ray are dynamic? Wouldn't this produce a heavy load of calculations if it were needing to check for intersections with an implicit object to instigate some sort of reaction? With many, different implicit objects or different reactions? Would the idea of an implicit object need to be dropped, or would such an abundance of calculations be minimal compared to the overall load of a commonly sized game project for instance?