-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Baffle "inside" lens? #63
Comments
The way this works in ZEMAX is that the baffle has a negative thickness, so rays that don't hit it effectively travel backwards then re-enter the lens front face. |
I think this still fits the model of sequential tracing and should be supported but probably isn't at the moment. Do you have a yaml file for the above that I could play with to work on this? |
I decided to implement the baffles whose (planar) origin falls inside a lens by changing their surface type to spherical, since that gives the same masking effect and preserves the strictly sequential ordering of ray-intersection tests. This applies to Baffles B1, B7, B10 and B13-15 of DESI.yaml in #62. |
I've been playing with tracing backwards a bit today. One issue I've found is that for all surfaces other than planes, there are potentially multiple ray/surface intersection solutions, and it's not always clear how to choose among these. The most obvious example of this is if you're tracing a ray to the surface of a sphere, and the ray is originating from inside that sphere, then there is one future and one past intersection point. Setting some constraints on the maximum distance from the vertex or the optic axis might help one choose between solutions, but I don't think even this is completely general since one may in principle be dealing with very oblique rays. It would also require pushing the obscuration code down to the c++ layer, which isn't the end of the world, but it's nice to have it available at the python layer. But for Planes, at least, since there's only ever 1 solution (unless the ray is coincident with the plane), I think it's fine to allow backwards propagation. This does mean you'd need to list the Plane baffles second wherever they intersect a lens, since you can go backwards from lens to plane, but not from plane to lens. A completely different approach may be to change the behavior of |
Some of the DESI lens cells have a planar baffle whose z coordinate is "inside" the lens, e.g. the leftmost mask of the first and last lenses here:
Is the ray tracing strictly sequential, or is this supported? When I list the baffle before the lens entrance in my yaml file, it effectively slices the lens front at its z.
The text was updated successfully, but these errors were encountered: