Hi Markus

Yes I can see your point and well I don’t know. I’ll check with our developers.
I checked the “old version” of this method under The Programming Tab > About Extensions > Tracing Large Numbers of Rays > Step 1: Placing the Ray Data in the Array > Mode 5: For Tracing Non-sequential Rays and it seems that the enumeration used to be an integer called the integer vigcode.

The integer vigcodevalue determines if polarization ray tracing, splitting, and scattering are to be used. To determine the vigcode value, use 0 for no polarization, 1 for polarization, plus 2 if splitting is used, plus 4 if scattering is used. The resulting integer will be between 0 and 7 inclusive. Note if ray splitting is to be used, polarization must be used as well.
 

I think that the other option would be to use a ZRD file: 

Sandrine

Thank you, Sandrine, this certainly makes the situation a lot clearer and also explains why the NSCRayTraceOptions return “3” when using “UseSplitting” as input instead of the input string, as it does for the arguments “None”, “UsePolarization” and “UseScattering”. It seems all options are already there in the backend, we just cannot access them. Maybe we could get access to all the raytracing options in a future version? I am looking forward to any feedback from the developers.

I have attempted using a ZRD file, as suggested, however from the few tests I have done it seems to still perform a lot worse than using the IBatchRayTrace interface directly, simply due to the constant writing and reading of files. If even remotely possible I would like to avoid any file I/O operations altogether - which is currently only possible with batch raytrace, as far as I am aware.

Hello Markus

Yes I am hoping we can access the missing raytracing options. I have submitted a bug to our developers and I’ll let you know when I hear from them.

Yes batch ray tracing does not involve saving a file. We also have an operand called NSRA but it has also limitations.

Yes, it appears that the ZOS-API version of the older DDE Extension for NSC ray tracing (Mode 5) is not implemented correctly.  Doesn’t seem like it should take too much effort to fix this.  However, I never understood why this mode is considered a “batch ray trace” since you can only define and trace one NSC ray at a time -- not much of a batch process! 

A more efficient approach, which is truly a batch process, would involve using a Source File to define a large set of custom rays (although per-ray polarization is not supported), then execute a standard NSC ray trace (multi-threaded) with the results saved to a ZRD file, and then efficiently parse the file using RayTrace.dll (see Batch Processing of Ray Trace Data using ZOS-API in MATLAB).  I have an SSD in my workstation that makes file I/O very fast.  Even with a conventional hard drive the overhead isn’t particularly severe.  If the ZRD file is simply too large, and only ray data for those segments that hit a particular object are needed, then just this ray data of interest can be saved in DAT or SDF format as described in the help documentation (with optional filtering allowed for even more control of what gets saved).  This can make a huge difference in the file size.  The file structure is also much simpler, so parsing can then be done quite easily inside of Matlab.  

On a somewhat different note, it would be nice if the sequential IBatchRayTrace options (that mimic the DDE Extension Modes 0-3) would be expanded to include surface scattering.  Then, for example, spot diagrams with and without scattering could be programmatically generated.   

Hi Csilla,

Any chance that you guys can add scattering to the sequential batch ray tracing options?

Thanks,

Jeff

Hello Jeff,

Thanks for your follow-up question here.

Thank you for bringing this topic to our attention. I have checked and indeed, unfortunately, there is no option in case of sequential batch ray trace to enable scattering. Therefore, I have gone ahead and submitted this internally as a feature request on your behalf.

Please keep in mind that feature requests are weighed based on impact, difficulty to implement, and the number of users who request it. A request is not a guarantee that the feature will be added to a future release.

However, these feature requests are very important to us and shape the future of OpticStudio, so we appreciate your input regarding this desired functionality.

Thank you,
Csilla