Simple Beamsplitters #57
Conversation
The structure of 'traceRay()' was adjusted to allow for tracing multiple rays after an optical element to allow for semitransparent optics like beamsplitters. There is no new functionality added and the tracing should behave as before.
Before implementing beamsplitters properly, use the pre-existing mirror element to test the necessary code changes. Instead of a single 'dNewRay', the code now uses a list of of those. The changes already work turning a mirror object into a beamsplitter: if making a plane a mirror, a ray is reflected and another is transmitted. If the a cube is used instead of a plane, the transmitted rays will be reflected and transmitted when exiting the cube. This might be desired for tracking residual reflection but there is not reflection coefficient yet. Hence, when trying to use, e.g., a thorlabs beamsplitter step file, the user should add a face right where the actual coating is (the face where the two triangular halves of the cube are glued together). Turning the cube into a lens (piece of glass) with the mirror surface inside the cube, however, does not work: the beam is only reflected but not transmitted anymore. Look into this with low priority (in most of my models the angle of incidence will be normal anyway).
All necessary classes were added (copied and adjusted from the mirror classes). The new icon is based on the mirror icon and was modifed via Claude AI to include a transmitted beam. The splitter works as described in the last commit (only single faces/planes should be used as splitters). There are currently problems when trying to use the optics workbench in an assembly4 assembly: added mirrors do not seem to work. At least when the linked parts are assigned to be mirrors after insertion. I believe this worked in the past, but maybe I added the mirrors in files prior to inserting them in the assembly.
The missing 'splitter' entry caused problems when adding more than one splitter in a document.
|
Thank you for the contribution. We can use it as a base for the semi-transparency feature, but I do not want to merge it in the way it is implemented now. Re- formatting the code is okay as long it is done in a separate commit without any new code or logical changes. I am not sure, but it seems you did that. |
My pleasure and thanks for the feedback! I agree that a transparency parameter would be useful and that a new optical object is not strictly required. Regarding single faces as optical beamsplitters/elements: Hence, to me, single faces as optical objects makes sense. What do you think? (If you prefer, we can move the discussion to issue #31 )
Good to know. Unfortunately, I did not... The first commit includes formatting and other changes. For future submissions I will be more careful. |
|
Addendum: To demonstrate the faces as optical objects idea: Same setup as in the screenshot of my last comment. Here, however, I made the cube a lens and added a face (marked in green) which I turned into a beamsplitter: |
|
I added the semi-transparency feature to mirrors with a Transparency parameter in this branch: It also calculates an energy value for each ray hit, but there are still some issues with theses values in the CSV export |
|
To get semi transparency work together with lenses, you could add a transparency parameter to lenses with the default of 100%. If the value is smaller and we do not have total reflexion a ray hit from the outside, add an additional mirrored ray in the same way the mirror does |
I added simple beamsplitters:
The code was adjusted such that a ray can generate a "tree" of lines (instead of a "list") and then made optical elements of type 'splitter' reflect a beam (same as mirror) and add a new transmitted line (a new "ray branch") by setting the 'doLens' flag without changing the refractive index. I would revise the 'doLens' hack in the near future, but it works for now.
Naturally, only FreeCAD objects that consists of a single face/plane should be turned into splitters as otherwise an incoming transmitted ray will be reflected inside the object indefinitely (up to maximum iteration, generating a lot of extra rays).
There is no transparency, i.e., transmission and reflection coefficients as discussed in issue #31 (but I might tackle this in the future).
Note that my editor formatted the 'Ray.py' file (I use python-lsp with the ruff plugin, so the formatting is that of the Black formatter). If this is an issue let me know I will revert the formatting where possible.
Feedback is welcome.