This pull request makes changes to the Ray objects such that user-selected optical elements can be ignored. The ignored elements will then not be considered in the ray tracing. This is set per ray-source, so it allows for multiple lightpaths to be constructed in the same document. It enables 2 use cases:
A situation where you may have an optical arrangement that has mixed static and dynamic elements, and you would like to visualise ray paths for each case without changing the geometry. For example a case where a mirror is inserted or retracted from an optical path. You could make one light source which ignores this mirror, and visualise both ray paths.
A crude way to get a 'beamsplitter/dichroic mirror' effect. You can create two (identical) lightsources, and from a single geometry create both a mirror and lens element. For one light source you set it to ignore the mirror element and you would get at least the geometric concept of a beamsplitter. Not as nice as a dedicated fresnel reflection element (more annoying to maintain too), but it doesn't require many changes. Example below:
[!IMPORTANT]
To run these checks, a python if el in list call is added to every ray calculation. I don't think it will impact the performance very much, but it is good to keep in mind.
An example file is included to demonstrate how one could achieve use case (2) described above.
I don't quite know how this use case should be documented. If you are happy having me write something to go in the main README I would be happy to do that, but if you prefer to write something yourself to keep it stylistically more consistent that would also be just fine.
[!IMPORTANT]
In the example file, you will see that, for the reflected rays, I do not ignore the 'lens' element (even though that would seem like a logical thing to do). That seems to lead to a update dependency loop. The ray then hits both a mirror and lens which exist in the same location. It's not a huge problem, but someone may accidentally do that and be confused. It may also slightly degrade performance as it might still try to calculate bounces of that lens surface (doesn't seem to affect ray path)
Other points
To maintain backwards compatibility with older light sources (which lack the new IgnoredOpticalElements attribute), a hasattr call is added to every ray trace calculation. I don't know what the maintainer's opinion is on breaking changes, but if performance is a concern that may be a point for tiny performance improvement.
Currently it seems like the step where the relevant optical elements to consider for a ray calculation is determined is done for every ray - even within the same ray object (e.g. sphere). It seems like it would be enough to do this only once per ray object. This seems like it may be a point of optimisation that could more than offset the performance drops introduced by this pull request.
This pull request makes changes to the Ray objects such that user-selected optical elements can be ignored. The ignored elements will then not be considered in the ray tracing. This is set per ray-source, so it allows for multiple lightpaths to be constructed in the same document. It enables 2 use cases:
A situation where you may have an optical arrangement that has mixed static and dynamic elements, and you would like to visualise ray paths for each case without changing the geometry. For example a case where a mirror is inserted or retracted from an optical path. You could make one light source which ignores this mirror, and visualise both ray paths.
A crude way to get a 'beamsplitter/dichroic mirror' effect. You can create two (identical) lightsources, and from a single geometry create both a mirror and lens element. For one light source you set it to ignore the mirror element and you would get at least the geometric concept of a beamsplitter. Not as nice as a dedicated fresnel reflection element (more annoying to maintain too), but it doesn't require many changes. Example below:
An example file is included to demonstrate how one could achieve use case (2) described above.
I don't quite know how this use case should be documented. If you are happy having me write something to go in the main README I would be happy to do that, but if you prefer to write something yourself to keep it stylistically more consistent that would also be just fine.
Other points
IgnoredOpticalElementsattribute), ahasattrcall is added to every ray trace calculation. I don't know what the maintainer's opinion is on breaking changes, but if performance is a concern that may be a point for tiny performance improvement.