Solved

ZOS API Direct Batch Ray Trace path length


Userlevel 7
Badge +2

Hello everyone,

 

What would be an elegant way of computing the path length (for every ray) from a direct unpolarized (sequential) batch ray trace in the ZOS API (since I don’t think it is returned by this tool, but correct me if I’m wrong)?

I was thinking of going surface by surface, each time finding the intercepts in X and Y, and computing the path length based on the Thickness between the two corresponding surfaces, but this requires a ray trace for each surface, and before I go in this direction I wanted to hear from other people’s experience.

Thanks for your help, and take care,

 

David

icon

Best answer by MichaelH 5 July 2022, 23:58

View original

2 replies

Userlevel 6
Badge +2

Hey David,

I think your approach is correct.

Based on the number rays vs the number of surfaces, you can use a different method.  You can use the CreateDirectUnpol if you have only a few surfaces but thousands of rays or you can use SingleRayDirectUnpol if you have dozens of surfaces but only a few rays.  Either way, I think you’ll have to use a loop outside the IBatchRayTrace interface to loop through either the surfaces or the rays.  If you’re using compiled code, these loops should not rally even be noticeable to the end user.

Something to keep in mind is this Cartesian distance approach will only work for homogeneous materials.  There is not really an efficient way to calculate the path length in a GRIN material.

If you just need total OPL and you don’t care about the OPL at each surface, you can create a function that converts from direct to normalized coordinates (the opposite of GetDirectFieldCoordinates) and run a CreateNormUnpol method & OPDMode.  Since a direct raytrace ignores ray aiming anyways, turning off Ray Aiming and using the paraxial entrance pupil for the Px/Py might be an easier task than looping through the CreateDirectUnpol method for each surface.

 

Userlevel 7
Badge +2

Hi Michael,

 

Thank you for the thorough answer, it makes a lot of sense. Fortunately, I don’t have to deal with a GRIN case, but its a good reminder. I like your idea of converting from direct to normalized coordinates, since I’m interested in the total path length only. I’ll think about it and see what works best.

Thanks again!

Take care,

 

David

Reply