This article demonstrates a stray light analysis workflow for a head up display (HUD). This article is part one of a three-part series.
Stray light analysis for head up display: part 1
Stray light analysis for head up display: part 2

Authored By Michael Cheng

Downloads

Article Attachments

Introduction

In Part 1, the specular straylight path of the picture generation unit (PGU) and sunlight are analyzed. A scene and a simple camera are added to visualize the image of the scene and the PGU received by an eye camera. To simulate efficiently straylight from the sun, a method of reverse ray-tracing from the eye camera to the sun is discussed.

In Part 2, an API Analysis tool is introduced to visualize straylight caused by the sun. This is done using a reverse ray-tracing process.

In the final part, a CAD model of the mechanical housing is imported into the system. The straylight process is repeated to analyze the straylight paths caused by scattering from the mechanical housing.

Note, while this article can be read independently, it’s suggested to read the article, Which tools to use when working on a Head-up-Display?. The straylight analysis is done on the system presented in that article.

Adding mechanical housing

In this section, the HUD housing is added as a CAD file to study straylight related to this housing. The file in this section can be found in attached “v2_Step3.zar” file. As shown in Figure 1, the CAD file (Object #43) is a mirror with a coating of I.95, which means it will reflect 5% of light. The part will scatter the reflected light. The scatter model is set to Gaussian with sigma = 1.

Figure 1 A CAD file is added with 5% Gaussian scattering.

These settings are not based on the specification of a real material but are used for an initial analysis when real data is not available. Users can define different coatings if the expected total scattering power is higher or lower than 5%. For scattering, users can use different sigmas or different models such as Lambertian. 
The Lambertian model is a good choice when the material is supposed to scatter light uniformly in angle.
Gaussian scattering, as shown in Figure 2, is a useful model when the scattered light is around the specular direction. The Gaussian model can be a good compromise between using a Lambertian scattering model and not using any scattering model.

Note that these models are approximations. Users should use measured BSDF data at a later stage of their design for best accuracy.

Figure 2 Gaussian scattering

Also note that, in order to simulate a scattering model well, the maximum intersections/segments and minimum ray intensity should be modified adequately as in Figure 3.

Figure 3 Maximum Intersections/Segments Per Ray are increased. Minimum Relative Ray Intensity is decreased.

Scattering straylight from housing

This part of the article analyzes the effects of straylight from the CAD housing. Therefore, the filter string “G0 & H26 & H43” is used in the analyses. It will select only ghost rays (G0) hitting the Detector Polar representing the sun (H26) and hitting the CAD housing (H43). Figure 4 shows those filtered rays in the Layout and the Ray Trace dialog.

Figure 4 The “G0 & H26 & H43” filter string considers only straylight paths that hit the CAD housing.

First, trace 1e6 rays from the reverse source for eye detector (Object #36). Save the ZRD file with the filter string mentioned in Figure 4. The result from the ZRD file in the eye detector and the sun detector is shown in Figure 5.

Figure 5 The 1e6 rays are traced from Source #36. The rays are saved in a ZRD file with the following filter string: “G0 & H26 & H43”. The data in the ZRD file is shown in the eye detector (#30) and sun detector (#26).

Here a trick is used to speed up the ray-tracing. The results on Figure 5 show that only rays from a certain area of the reverse source (#36) can hit the sun detector (#26). This implies that the source can be smaller and still give the same results. To simulate this more efficiently, in Figure 6, the size of the source is reduced from 40 mm x 30 mm to 11 mm x 22 mm.

Figure 6 Smallest rectangular size for object #36 to cover all the effective area for straylight analysis.

After reducing the size of source #36, a ray-trace is done again with 1e8 analysis rays. More rays means more representative results. Note that a ZRD file is saved and the final ZRD size is about 12 GB. The result in the ZRD file is shown in Figure 7. The difference between Figure 7 (b) and (c) is that (b) shows the result of the Detector Viewer and (c) the “sun_straylight_analyzer.exe” User Analysis. The result in (b) doesn’t considers the transmittance from the reverse source (#36) to the sun detector (#26), while the result in (c) considers it. Note the result in (c) considers the sunlight from all possible directions at the same time.

Figure 7 ZRD data in (a) sun detector (#26), (b) eye detector (#30), and (c) user analysis sun_straylight_analyer.

The following section will look at specific directions for the sun.
Settings for Figure 7 (c) are Source# = 36, Detector Polar# = 26, Detector Rectangle# = 30, Only ZRD data = checked, Half cone angle = 180, and the rest = default.
All the settings for the “sun_straylight_analyzer” User Analysis are shown in Figure 8 for reference.

Figure 8 Settings dialog of the "sun_straylight_analyzer.exe” User Analysis.

Cross-checking the straylight on eye/sun detectors

Unlike the straylight analysis for the specular path seen in previous parts of this series of article, the path analysis for this system with a scattering component gives more than 100 paths. It’s not practical to analyze all these paths. Instead, in this case, it may be more useful to do a cross-check for the results on both eye and sun detectors. For example, Figure 9 shows how different angles of the sun (detector polar #26) can contribute to different areas on the eye detector (#30). The two lower pictures of Figure 9 uses filter strings to show only rays that hit specified area on the detector #30. This is useful for designers to know what angle of the sun will contribute most to a specific area on the eye detector.

Figure 9 Using a filter string to check the effect of a certain area on eye detector on the detector polar.

The following table explains the 4 keywords: X_XGT, X_XLT, X_YGT and X_YLT used in the filter string in Figure 9 and Figure 10. The 4 keywords are used to specify the upper and lower boundaries for x and y directions for a rectangle. For more information about filter strings, read the article Introduction to stray light analysis.

For more details, the path analysis can be run for a specific area of the eye detector (#30) as shown in Figure 10. This can be more useful than doing a path analysis for the whole eye detector. After knowing which component is the cause of the problem, designers can then take an adequate strategy to solve the issue.

Figure 10 Path analysis for a specific area on eye detector (#30).

On the other hand, it is also possible to specify a polar and azimuthal angle of the sun and see how the straylight looks like on the eye detector for that angle.
For example, the angle of (polar, azimuthal) = (0,0) and (10, -77) are checked in Figure 11.
Note that the divergence angle for sunlight in clear sky is about 0.25 degrees.

However, in Figure 11, the half cone angle is set to 2.5 degrees to include more rays in the eye detector and thus have a better image. Since a larger cone angle includes more sunlight, it can cause unrealistically high irradiance on the eye detector. So, the Scale is set to (2.5/0.25)^2 = 0.01 to compensate. Roughly to say, when the half cone angle is n times larger, it includes n^2 times of power.

Figure 11 Checking the image on the eye detector for at specific angle of sunlight.

In Figure 11, the straylight from light scattering on the CAD housing has a maximum irradiance of only about 0.01 Watts/cm^2. This is not high compared to the scene and the HUD image, which has a maximum irradiance of about 1 Watts/cm^2 (see previous parts of the articles). It means that if the mechanical housing is made of materials that scatter light with no more than 5% of reflectance, the straylight and ghosts from the mechanical parts won’t be a big problem. However, these results are only based on approximations such as the Gaussian scattering model. Users should use real data in the analysis and make a correct estimation.

Removing straylight

This series of articles doesn’t mention solutions to remove straylight from the system as solutions can be very different from one system to another. Users should investigate straylight paths of their system and consider counterplans.
Usual solutions involve adding mechanical components to block straylight, while not modifying the direct light path, coating the mechanical components with black paint to decrease the reflectance of surfaces and increasing surface roughness to enlarge the scattering angle. 
The following links provide some useful resources when solving straylight issues.

• To build complicated geometries:
  How to use the Boolean CAD, Boolean Native and Compound Lens objects, and the Combine Objects tool
  Improving non-sequential ray tracing speeds with nested and Boolean objects
• To import CAD:
  How to import CAD objects
  Tips and tricks for successful CAD import
  How accurate is the CAD exchange?
• To change coating and scattering properties:
  How to add coatings and scattering functions to Non-Sequential objects

Conclusion

In this series of articles, the straylight analysis of a HUD system has been performed.

• Part 1 showed a reverse ray-tracing technique to analyze the effect of sunlight on a HUD system. It also discussed the very useful path analysis tool to analyze the specular straylight path.
• Part 2 introduced a ZOS-API User Analysis tool “sun_straylight_analyzer.exe” to visualize the straylight from the sun on the eye detector. This was done with a saved ZRD file from a reverse ray-tracing process.
• Finally, in Part 3, the mechanical housing of the HUD was imported. Some different strategies for analyzing straylight caused by scattering from the mechanical parts were also discussed.