Thin perfect lens implementation to allow for afocal design

[gvJaime]

Overview

This pull request implements perfect thin lenses into BEAM FOUR, to allow for afocal designs such as telescopes, infinity corrected microscopes, microscope eyepieces, and so on.

It creates a new type of surface called "Thin" and a new attribute called "Focus". The new surface redirects the rays as if it was a perfect lens. That means absolutely no new aberrations introduced into the system.

Changes to the code

It creates an OTTHIN flag and a OFOCAL flag in B4constraints.java, it adds a condition for those in the parser in OEJIF.java, and implements a new iThin() method in the RT13.java raytracer.

Mathematics

The ray tracing function has been implemented understanding the lens as an application that converts ray entry angles into positions onto the focal plane. An incoming ray is then launched towards it's assigned position in the focal plane. However, we need the angles of the output ray u' = (u', v', w'), rather than a position of the focal plane. Therefore we need to obtain the vector as follows:

• Note that all the vectors are expressed on the lens' local coordinate system.
• Let u = (u, v, w) be the unitary vector containing the direction cosines of the incoming ray. And let f be the focal length of our lens.
• Let q be a vector that contains the coordinates of the point in the lens in which the incoming ray landed.
• Let P be a vector that has the same direction as the incoming ray, but emerges from the center of the lens and lands on the focal plane.
  • Because all parallel rays focus into a single point, and rays passing through the center don't get bend; this P vector represents the coordinates of the point in the focal plane assigned to that direction.
  • The only coordinate we know is the third coordinate, because the focal plane is one focal length from the lens, so P = (Px, Py, f).
  • We can know the rest of the coodinates because u is also the unitary vector for P.
    • That way ||P|| = f / w. and therefore P = ||P|| * u.
• Let r be a vector that goes from the incoming ray landing point, to the point assigned to that direction (that is, P).
  • Because we had q as the coordinates of the landing point, we have r = P - q.
• The angles of our output ray are the ones of r, so: u' = r / ||r||.
• To prevent the rays from going backwards in the case of negative focal lengths, u' is multiplied by the signature of f, so actually u' = sgn(f) * r / ||r|| .

What has been tested

This implementation has been successfully tested for oblique parallel ray focus, and for perfect object refocus.

Known issues

• Mixing this lenses with other parameters hasn't been tested or filtered. The user is supposed to behave.
  • This implementation does not prevent the user from making a non planar perfect lens.
• Focal lengths cannot be autoadjusted.
• For some reason, sometimes the diameter of the lens won't go over twice the focal length.

Additional notes

• If the commit sequence inside this pull request doesn't adjust to the commit etiquette of this repo, I can squash all the commits into one, and remake this pull request.
• Code style has been as respected as much as possible.
• Compiled and tested with javac 1.8.0_212. The version of javac hasn't been changed in B4constants.java.
• In case this get's merged, I can add this new entity into the documentation.

[gvJaime]

By moving OFOCAL parameter to the Adjustable part of parameters (behind OFINALADJ), focal lenghts are now adjustable.

[MikeLampton]

Nice! Thank you -Mike Lampton

…

On Tue, Jun 11, 2019 at 9:11 AM Jaime García ***@***.***> wrote: By moving OFOCAL parameter to the Adjustable part of parameters (behind OFINALADJ), focal lenghts are now adjustable. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3?email_source=notifications&email_token=ACLFEF7YW3WW7Z2CP5N7M53PZ72EHA5CNFSM4HVFVIJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXOGC4Y#issuecomment-500982131>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACLFEF62JP22CZR673FAXW3PZ72EHANCNFSM4HVFVIJA> .

[gvJaime]

Hello
I see that the changes haven't been merged to the main branch.
Is there any problem with the code, or any test that it didn't pass? Is there anything I can do to help?

[gvJaime]

Also, I'll add that I've been using this branch of the software since it was made in June, and it's been working well so far. Integration with the rest of functionalities works well, and no crashes have been experienced.

The only problem I have been experiencing is that when AutoAdjusting for Focal Length, BeamFour doesn't contemplate switching from a converging lenses to a divergent lens, resulting in AutoAdjust to diverge to infinity.

Maybe handling focal length with diopters rather than focal lenght would have been a better idea. This is a fairly simple change.

(It would make me update all my designs though, as they are all made with Focal length in mind)

[gvJaime]

Well

I found that my code was compared against the master branch, which holds the Sources for release 199, which is not the last one.
I made a development branch in my repo, with the 208 release sources found in a zip in the end-users branch in your repo.

The result was indeed an absolute mess of conflicts, but nothing that cannot be solved with a bit of patience.

I'm going to try to merge said development branch with 208 sources with my changes, so this pull request will hold the 208 changes and the thin lens addition.

Also, I will take this chance to turn the Focal parameter into a Diopters parameter. It seems to me that it will behave better, and that is more in line with how all the program is set up.

[gvJaime]

OK

I managed to merge the 208 changes with my changes with success. 208 made some parameter renumbering that needed to be merged manually. It works as intended now.

Also, I changed the Focal parameter into a Diopters parameter, which uses diopters rather than focal length. Had to make an exception in the raytracer function so the ray can be normalized when the Diopter parameter hasn't been assigned yet.

I'd like to rewrite the iThin() raytracing function to something that uses 1 / x less, to avoid bit saturation, but I cannot come up with anything right now. That's something for another day.