I'm having a hard time understanding that! I'm trying to find some sources to explain this but comin up short.

I would have though the inverse ray would be (x*-1, y*-1, z*-1), making an inverse ray of positive X as (-1, 0, 0). Then it's a ray going in the opposite direction.

By the way, thank you for answering, I realise I'm probably asking really stupid questions. ]]>

You say you can calculate the inverse of a ray with (1/x, 1/y, 1/z) but I don’t understand that.

Suppose I had a ray going straight in the x direction (1,0,0). Wouldn’t this give:

(1/1,1/0,1/0) = (1,0,0)

Which is surely the same ray?

Sorry if this is a stupid question!

]]>You can't divide by zero like this. The result is undefined in glsl, which means the implementation is free to do whatever nonsense it wants to when it encounters this statement (except - according to the spec - crash).

]]>`dmnsn_ray`

) is by the parametric formula `origin + t*direction`

. Commonly we restrict `t >= 0`

to get a half-line starting from the given origin. So generally `t`

specifies a position along a line. In this case, `t`

is the closest object intersection found so far, so if the bounding box is farther away than `t`

, we can ignore it.
I agree that should be better documented! :)

]]>http://blog.johnnovak.net/2016/10/22/the-nim-raytracer-project-part-4-calculating-box-normals/

]]>

static inline bool dmnsn_ray_box_intersection(dmnsn_optimized_ray optray, dmnsn_aabb box, double t)

It hurts me to say this but I believe that some of the functions do require comments about their input parameters. Or more obvious names.

]]>