Comment by dragontamer | Hacker News Reader

Comment by dragontamer | Hacker News Reader

Parent Full thread

Raytracing is surprisingly simple if you already know trigonometry.

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.

This is what made it such a fun project for me. I don't enjoy really complex math, but I love optimizing and refactoring and making things more modular and achieving new visual effects. So I was able to just drop in a couple of key equations from the internet, and I was off to the races and got many hours of enjoyment from the infinite tail of possible improvements. Plus, you get really satisfying output really early on ("in a weekend"), which is a big motivator for me to keep going.

More Linear Algebra plus Trig... trig won't teach you eigenvetors, normals, etc.

Normals are part of trigonometry.

Eigenvectors won't show up in an elementary path/ray tracer.

You need the most barebone understanding of LA for xform composition/application.

The way I see it: the linear algebra parts are just optimizations.

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.

I think of it not exactly, but sort-of, the other way around: using trig without any linear algebra is a shortcut to doing the linear algebra. Or maybe it’s just that the trig stays the same, but it’s possible to hard-code or short-cut your transforms to not include matrices or dot products explicitly... in simple cases. In reality trig and LA aren’t in competition, they’re both necessary in a serious renderer, and they represent different tools and different views on vectors.

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?

the word trigonometry comes from the greek word "trigono" (triangle) and "metro" (count) which quite clearly describe what trigonometry covers: counting triangles (ie sides and angles). Its history dates back to at least the ancient greeks (if not more/other civilizations, I do not know). Linear algebra is a different field of mathematics which focuses on solving systems of linear equations which has a LOT of applications (even in other non applied mathematics). I think it is better if you do not try to think one as part of the other.

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)

Can you even get the angle between two three dimensional vectors without using some sort of vector product and venturing into linear algebra territory?

Yeah. Its just harder using Trig: SOH CAH TOA.

    tan(angle) = opposite-leg / adjacent-leg.
    arctan(opposite-leg / adjacent-leg) == angle.

The more I do this, the more I realize that the linear-algebra approach might be easier... but the Trig approach can certainly do what you are asking for.

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.

Ok, hmm I'm still a bit lost though, those identities work on a right triangle, but how do you construct a right triangle between two 3D vectors A, and B?

> Ok, hmm I'm still a bit lost though, those identities work on a right triangle, but how do you construct a right triangle between two 3D vectors A, and B?

(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.

>(0,0,0), A, and B are the three points of a right-triangle.

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.

Ah right. Law of Sines

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...

The average of the 3 points would give you the triangle's centroid, not necessarily its circumcenter. You can still calculate the circumradius from a, b, and c: https://mathworld.wolfram.com/Circumradius.html.

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.

Yeah, sure is messy.

Like I could see how you could figure this out if you can project one line onto another maybe, but I also don't know how to do that with just trig.

Mostly nitpicks:

> 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.

> He did popularize, if not invent the idea of a metalness map.

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.

Thanks for the info, I knew even my statement might have been a stretch.

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.

There is even some crazy work using micro-CT scans to develop highly realistic scattering models of materials. https://www.cs.cornell.edu/~kb/publications/SIG11CT.pdf

A friend worked on a similar project to predict bird (and dinosaur) coloration from the structure of their feathers, which is just wild!

That's really cool. I hadn't seen it, but I'm not surprised to see Wenzel Jakob's name on the paper.

The same author also has "Ray Tracing: The Next Week", which introduces a lot of the missing features you mention.

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.

Interesting. The angle of incidence equals the angle of reflection.

Reply on news.ycombinator.com