Hi @MichaelH ! Thank you for your feedback. I will report a feature request. If anyone is interested in this feature request, please add your comment below explaining why you need it. Thank you!
Thanks Sandrine for submitting this. Unfortunately, I doubt anyone else will request this (most customers probably don’t even know the capability of NSRA, let alone the few data points it doesn’t currently calculate).
Although it’s a small improvement, I think Zemax could highlight this for a future release. You can essentially recreate the NSC Sag Map with native speed & without the need to save a ZRD file, which has caused a few issues in the past (there are other smaller benefits like implementing a Angle of Incidence as a Universal Plot/ZPL macro with a little more ease/user control or you could implementing a “Filter String” builder that could output Filter Strings which have a Face number component). Basically, any programming logic that requires Face Number as an input or output could greatly benefit from this with probably less than 4 hours of Development effort.
It’s a little awkward that NSST (mixed-mode) has the Face Number for the segment but NSRA (pure non-sequential) does not.
Thank you @MichaelH for the additional details.
I hope you don’t mind but I just have a few extra questions. Could you let us know some extra details about how this would impact your workflow? For example:
- What kind of optical systems are you building which require that functionality?
- Is your current workaround to save a ZRD file?
- How often are you performing this analysis?
Sorry if the questions seem naive but just to be sure I get the grasp of it.
Hey @Sandrine Auriol, the 2 main areas where this could affect me are:
- Non-Sequential CAD to Sequential Extended Polynomial conversion (think CAD windshield for a HUD system)
- “Sequential” Stray Light analysis
I need to save a ZRD to disk for each of these processes and having direct access to Face Number programmatically without saving & parsing a ZRD can help with speed and stability.
For the CAD to Extended Polynomial, I use the same concept as the NSC Sag Map where I trace a grid of rays in the Z direction and simply get the z-sag component of the ray intersection. The CAD part will need to be converted into 2 surfaces in Sequential mode so I need to know which face the ray hits. Once I have the grid of sag data, I can exploit symmetry if needed & fit an n-th order polynomial (up to 10th order for Extended Polynomial) to the dataset. Finally, I can save the sequential LDE with the 2 surfaces and then use the Insert Lens feature to add this to my optical system.
For the “Sequential” Stray Light analysis, I shared my vision for this with Bob & Tom last year at Optics & Photonics. The concept is to create a copy of the optical system, convert this copy to non-sequential mode, run a non-sequential ray trace & then analyze the paths. The few filter strings I use the most in this analysis are:
- X_XGT/X_XLT/X_YGT/X_YLT to isolate a region of interest on the detector
- X_IRLT to eliminate the intended path in the ROI
- Gn for ghosting off a lens
- X_HITFACE2 for double bounce ghosts
I always group these last two filter strings together (see my answer for Filter String for Ghost Analysis | Zemax Community) and when using a probing a ray to determine the Face Number for X_HITFACE2, saving a ZRD becomes very time consuming for a single ray.
I would need to perform the CAD to Extended Polynomial analysis maybe every 2-3 months but when I do the analysis, I need to analyze dozens of different CAD designs. I perform the Stray Light analysis on a weekly basis for different designs, especially during the prototype phase if there is stray light once the entire camera system is assembled.
Hi Sandrine,
As an old hand at this, can I suggest that you guys do a purge on almost?
NSRA almost does everything...more importantly ZOS-API almost does everything...it would be great if these features really did do everything that the UI can do.
I know from personal experience that it's more fun to work on new features, but some time on these ‘finishing up’ projects really does bring benefits for users. It also prevents lost project time as it’s frustrating to think you can do everything only to find you can’t. I think that’s particularly true of ZOS-API :-)
Hi @MichaelH and @Mark.Nicholson ! Thank you for your comments. Yes I agree that it can be frustrating. I’ll take care of the feature request. Thank you.
