Henke/NFF tables are not loaded correctly #476

Describe the bug

Henke/NFF refractive-index tables are parsed but remain empty because the parsed entries are not added to NffTable::m_Lines.

As a result, Henke data is never used. The effective lookup order is:

Palik → Cromer

instead of:

Palik → Henke → Cromer

To Reproduce

Steps to reproduce the behavior:

1. Use a material with an available Henke table, for example Cu.
2. Run RAYX with verbose logging enabled.
3. Request a refractive index in the Henke energy range, for example at 100 eV.
4. Observe that the Henke table contains no entries or that the lookup falls back directly to Cromer.

Alternatively, inspect NffTable::load() and observe that parsed NffEntry objects are never appended to m_Lines.

Expected behavior

Henke/NFF files from Data/nff should be loaded into NffTable::m_Lines.

For energies within the valid table ranges, the lookup order should be:

Palik → Henke → Cromer

The implementation should not extrapolate outside a table’s valid energy range.

Screenshots

Not applicable.

System Information:

• OS: [e.g. macOS 15.7]
• Version: [RAYX git commit hash, see output of rayx --version]
• Material: [e.g. Cu]
• Energy: [e.g. 100 eV]

Additional context

The Henke data is stored in Data/nff. The files contain energy-dependent f1 and f2 scattering factors and are intended to be converted into complex refractive indices.

Relevant files:

• Intern/rayx-core/src/Material/NffTable.cpp
• Intern/rayx-core/src/Material/Material.cpp
• Intern/rayx-core/src/Shader/RefractiveIndex.cpp
• Intern/rayx-core/tests/testShader.cpp

The supplied Henke data is intended for use from approximately 30 eV onwards.