Creating a routine to calibrate for spherical aberration in a concave mirror so that a laser's scan of the interior of an eye could be more precise. The mechanical solution was to scan against a flat surface first, but since the mirror was only convex on one axis and was spun at high speed with the laser reflected off another also spinning mirror, you needed to calculate the complete angle of the laser.
Everyone else working on the project was screwing around with matrices and sin/cos -- the "accepted" methodology -- but that was taking far, FAR too much CPU time on the hardware available at the time. (this was twenty years ago)
So I said "no, this is a job for arctangent!"
Instead of trying to read the motor's position, I just added black stripes around the scan surface that could be used on the software side to calculate the position and speed. A lookup table of what the value SHOULD BE based on the two slopes (arctan's job) gave you the amount to fudge the result when compared to the actual reading against the flat plate.
The end result being a significant lowering of the mechanical tolerances and manufacturing quality of the mirrors needed. Basically using software as corrective lenses -- knocking about five grand off the price per unit.
A good laugh when the purpose of the entire machine was for eye exams.
I used the same technique in creating 3d games back in the '80's. Two arctangents to turn heading and pitch into X and Y is far faster than screwing around with matrices and a slew of sin/cos, particularly when you can do the viewer perspective rotation AFTER the projection. So long as you don't need a system of true 3d movement without gimble lock, it works far faster as you can reduce the entire projection to slope calculations and a lookup table.
Ooph, I've not thought along those lines in over a decade -- been wasting my time on front-end stuff since that's where the real money seems to be these days.
Jason Knight
The less code you use, the less there is to break
Creating a routine to calibrate for spherical aberration in a concave mirror so that a laser's scan of the interior of an eye could be more precise. The mechanical solution was to scan against a flat surface first, but since the mirror was only convex on one axis and was spun at high speed with the laser reflected off another also spinning mirror, you needed to calculate the complete angle of the laser.
Everyone else working on the project was screwing around with matrices and sin/cos -- the "accepted" methodology -- but that was taking far, FAR too much CPU time on the hardware available at the time. (this was twenty years ago)
So I said "no, this is a job for arctangent!"
Instead of trying to read the motor's position, I just added black stripes around the scan surface that could be used on the software side to calculate the position and speed. A lookup table of what the value SHOULD BE based on the two slopes (arctan's job) gave you the amount to fudge the result when compared to the actual reading against the flat plate.
The end result being a significant lowering of the mechanical tolerances and manufacturing quality of the mirrors needed. Basically using software as corrective lenses -- knocking about five grand off the price per unit.
A good laugh when the purpose of the entire machine was for eye exams.
I used the same technique in creating 3d games back in the '80's. Two arctangents to turn heading and pitch into X and Y is far faster than screwing around with matrices and a slew of sin/cos, particularly when you can do the viewer perspective rotation AFTER the projection. So long as you don't need a system of true 3d movement without gimble lock, it works far faster as you can reduce the entire projection to slope calculations and a lookup table.
Ooph, I've not thought along those lines in over a decade -- been wasting my time on front-end stuff since that's where the real money seems to be these days.