Closed samreid closed 9 years ago
+1 for using full names (position and direction).
First, why does it store the direction as a 2d vector instead of an angle? It only has 3 degrees of freedom, so why store 4 values and require that the 4th value not be independent (in an assertion check?)
I've found that using the unit vector for direction is generally much easier. A common case is stepping a ray forward by a fixed amount (position + multiplier * direction), which would be (position + trig expression). Also most intersection routines for rays involve the unit vector for direction more often than any sort of "angle" is used.
Second: the fields are called pos and dir. It may be better to call them position and direction to be consistent with the rest of the nickname-less code, especially since they are public.
Sounds great to me, it was mostly a hold-over from other code I've written many years ago. I'll take care of this.
Anything left to do here, and can you review my changes?
The changes above look good. Shall we do the same thing for Ray3?
Also, the other thing I would suggest is running the sim tests to see if we missed anything. @jonathanolson do you have time to start that up or should I?
Sounds good to both test and handle Ray3. I'll be able to take care of that at home.
Done, tested usages of Ray3.
@jonathanolson suggested that I look into using Ray2 for some math in bending light. It is looking good but I have some questions about Ray2:
First, why does it store the direction as a 2d vector instead of an angle? It only has 3 degrees of freedom, so why store 4 values and require that the 4th value not be independent (in an assertion check?)
Second: the fields are called
pos
anddir
. It may be better to call themposition
anddirection
to be consistent with the rest of the nickname-less code, especially since they are public.