Eigenvectors won't show up in an elementary path/ray tracer.
You need the most barebone understanding of LA for xform composition/application.
You can probably??? write a raytracer using Trig alone: it just means that you'll be using sin/cos on angles instead of "short-cutting" with a dot-product to determine normal vectors.
Hmmm... well... maybe the concept of dot-products and orthogonal vectors will help. So Linear Algebra probably will make things easier if you studied that too... but I still think its kinda optional.
Sines and cosines fall out of rotations because of the implicit circle involved, but it’s more general to think of a transform between two basis frames. It just so happens that the lengths of basis vectors of one frame projected to the other are computed using sines and cosines, but the transform and dot products are there whether they’re made explicit or not.
Using only sines and cosines falls apart very quickly, here are a couple of examples:
Compute a surface normal under non-uniform scaling. You need the inverse transpose matrix. I don’t even know how to derive it using trig.
Implement instancing or a character rig in your ray tracer. As soon as you need to compose transforms just to trace a ray, the trig route is off the table (impractical in the extreme), and matrix math is required. An alternative might be geometric algebra - is that in the same boat with linear algebra for you?
trigonometry provides the trigonometric functions, their relationship and a few basic equations. Linear algebra provides vectors/matrices. You need both of them to model 3D objects and vectors interscting with them (aka rays hitting objects)
tan(angle) = opposite-leg / adjacent-leg.
arctan(opposite-leg / adjacent-leg) == angle.
I mean, I recognize that I'm just "reinventing cross-product" here to get the length of opposite-leg and the direction of adjacent-leg. But it does seem feasible to do all of these things in Trigonometry alone.
A little bit of Linear algebra (cross product creates an orthogonal vector) would definitely make this problem easier.
(0,0,0), A, and B are the three points of a right-triangle.
Hmm... okay, yeah. I see what you mean. Every time I think about how to do things, its linear algebra time.
The thing is: I've had this feeling before in other maths: the more you study one math subject, the "worse" you get in another. There's surprising things you can do with algebra alone without any calculus... but once you learn calculus, you kinda forget those old algebra tricks.
Your next line suggests you already know this, but just so it's clear it's not, they are three points in an arbitrary triangle. Each vector has a right triangle between the origin and (two of?) it's axis, but I'm not sure that's helpful.
Yeah, I agree in that it feels like you should be able to do this, but I just know that I've been stumped in the past, and can't figure it out now either.
sin(a) / A = sin(b) / B = sin(c) / C
Apparently, MY trigonometry is awful and needs more practice! Law of sines is basic 'non-right triangles' stuff.
There are three legs: A-0, B-0, and B-A. Hmmm... B-A seems like a vector operation (but its a really easy one, so... probably can be figured out without formally studying linear algebra).. That gives us the "A", "B" and "C" for lengths.
Aaaannnnd I'm stuck again. I have the lengths but I don't have the angles. I only need to find one angle and the other two are solved with law of sines.
Maybe a system of equations at this point (lol, another subject where linear algebra helps). The law of sines gives 3-unknowns, but only 2-equations. So I still need one more constraint before I can math-out a solution.
------
EDIT: Law of sines is fully:
sin(a) / A = sin(b) / B = sin(c) / C = d
Where "d" is the diameter of the circumcircle of the triangle. So the circumcircle's diameter gives us the 3rd equation needed to solve the above system of equations (using non-matrix math).
So yeah, I think its possible. Its just waaayyyy harder to do. I also am handwaving a difficult part. I guess... take the average of 3 points, which would give the center of the circumcircle. Then sqrt(x, y, z) from the center to find the radius, then 2*radius = d.
Wow, that's a lot of work compared to an easy projection matrix...
You could also use the law of cosines to get a triangle's angles pretty easily when you know its edge lengths: https://mathworld.wolfram.com/LawofCosines.html.
> math formulas created by artists
Rarely do artists create the BSDF, generally a general model BSDF is provided by an engineer or scientest, and the parameterization is tweaked by an artist.
> that specify how light bounces off of objects
Technically a BSDF generalizes all light interaction with medium. a BRDF, is the function that describes how light bounces (reflects, the R in BRDF) off of objects, which is sufficent for raytracing solid, non transparent/translucent objects.
> And an "uber BSDF" that kind of provides sliders for many different objects. (Invented by Disney
The idea of an uber BSDF wasn't "Invented by Disney" Brent Burley did develop Disney's principled BRDF at Disney, but it builds on a long foundation of uber BRDFs at VFX studios. He did popularize, if not invent the idea of a metalness map. It was however already possible to represent metals in existing uber shaders by just using a standard full color specular lobe.
> Understanding the hardware (SIMD-cores, maybe even GPUs)
I'd add understanding memory cache hierarchies, and their affect on performance highest among those.
I don’t know what the precise differences are, but FWIW we had an uber shader that we called “uber shader”, with a metalness map (a texture driven metallic BRDF lobe, not just full color specular) at PDI in the late 1990’s, written by Sing Choong Foo (who worked on the Lafortune model). I’d guess Pixar and other studios had one too by that time.
I'm not even sure Disney can be fully credited with popularizing it, I think it was becoming important in videogames with packed GBuffers almost concurrently.
A friend worked on a similar project to predict bird (and dinosaur) coloration from the structure of their feathers, which is just wild!
Chapter 3 introduces BVHs, Chapters 4-5 add more surfaces, and Chapter 7 adds cubes. There's a third book ("Ray Tracing: The Rest of Your Life") that tackles more sophisticated approaches like importance sampling.
If you don't know Trig... you'll have to brush up on your math. But fundamentally, you project rays, you calculate if those rays hit an object (and if so, which object is "in front", and therefore hit first). And finally, you apply BSDF functions (math formulas created by artists that specify how light bounces off of objects) to calculate where the light bounced to.
That's it. The BSDF is an abstraction: there are many different models: one for metal, one for "specular" ("shiny" objects, like a marble), one for "diffuse" ("soft" objects like an egg), etc. etc. And an "uber BSDF" that kind of provides sliders for many different objects. (Invented by Disney: Roughness, Metalicness, Specularness, Diffuseness). But the BSDF itself is just an abstraction: where did the light bounce to? And different objects have different properties.
------
From there: making a FAST raytracer is the hard part. What kind of data-structures are needed to calculate intersections more quickly? Understanding the hardware (SIMD-cores, maybe even GPUs) to calculate BSDFs in parallel. Etc. etc. Lots of little things to learn and ultimately complicating the thing.
A professional raytracer would also have special code for the different kinds of objects in the scene.
True random path tracing takes too long. Biased techniques and quasi-random paths can make smoother images with less effort. Unbiased techniques shy away from such "theoretically suboptimal" optimizations. Denoising. Multithreaded, multi-computer, multi-GPU support. The feature sets goes on-and-on-and-on.
But if you want to just make "a" raytracer, without any care in the world about how fast (or slow) it is, then you easily can do that in one weekend. So give it a shot if you like.
-----------
https://www.kevinbeason.com/smallpt/
They brute-force an all-to-all check against all objects. There's no oct-tree partitioning or BVH trees. The only shape supported are spheres of varying sizes (no squares, no triangles, no cubes. Just spheres). There are only three BSDF functions implemented (specular "hard and shiny", diffuse "soft and matte", and glass). This tiny program is inefficient as all heck, but hey... 99 lines of code is pretty spiffy. That's all you really need for a raytracer.