Mitsuba 1 Sunsky

[tszirr]

NEW DESCRIPTION:

Port of the mitsuba1 sunsky plugin, following the old implementation as closely as possible. I tested scalar_rgb, packet_rgb, gpu_rgb, scalar_spectral, and packet_spectral modes, they all approximately match the references I have for mitsuba 1.

The implementation is slighly compacted, merging sun, sky, and sunsky, with corresponding XML upgrade paths. An open issue is that there is currently no way to pass a spectral texture to the 'envmap' plugin. This results in unnecessary RGB and subsequent upsampling conversions for the spectral code path. However, I tried to keep the code forward-compatibile, such that the necessary changes to the spectral code path are minimal, once spectral emitter textures are supported.

OLD DESCRIPTION, now split into other pull requests: https://github.com/mitsuba-renderer/mitsuba2/pull/90 https://github.com/mitsuba-renderer/mitsuba2/pull/91 https://github.com/mitsuba-renderer/mitsuba2/pull/86

This pull request includes several patches which ultimately allow to load all the mitsuba1 scenes that I have been using in the past years, mostly without any manual modifications. I kept the patch as small as I could, the biggest additon being an as direct as possible port of the mitsuba1 sunsky plugin.

I tested scalar_rgb, packet_rgb, gpu_rgb, scalar_spectral, and packet_spectral modes, they all approximately match the references I have for mitsuba 1.

While I tried to keep changes small, the following outline hopefully simplifies their review:

• The first three commits are somewhat unrelated bugfixes (https://github.com/tszirr/mitsuba2-patches/commits/bugfixes), fixing XML object expansion, generic env map classification, and a utility function signature
• The fourth commit (https://github.com/tszirr/mitsuba2-patches/commits/compatibility) brings minor improvements for compatibility with previous scene file versions: It prevents breaking camelCase conversion of <default> names, mangles names that collide with reserved IDs, and fixes 'diffuseReflectance' for diffuse BSDFs
• The fifth commit (https://github.com/tszirr/mitsuba2-patches/commits/upgrade) adds two command line flags (-D__load_permissive=1 and -D__upgrade_approximate=1) to the XML loader, which allow to ignore 'unreferenced X' errors and approximately replace currently unsupported BSDFs, respectively
• The final commit (https://github.com/tszirr/mitsuba2-patches/commits/sunsky) adds the mitsuba1 sunsky plugin in a slighly compacted form (merging sun, sky, and sunsky, with corresponding XML upgrade paths). The code closely follows mitsuba1, its major open issue being that there is currently no way to pass a spectral texture to the 'envmap' plugin. This results in unnecessary RGB and subsequent upsampling conversions for the spectral code path. However, I tried to keep the code forward-compatibile, such that the necessary changes to the spectral code path are minimal, once spectral emitter textures are supported.

With this set of changes (and the additional upgrade load flags), I can load and render all mitsuba1 scenes I have on drive, including many scenes from previous work and popular public scene archives.

Update: One more commit to also fix packet_spectral. Tested modes are now scalar_rgb, packet_rgb, gpu_rgb, scalar_spectral, and packet_spectral. Also re-checked API-doc build.

[Speierers]

Hi @tszirr,

Thanks a lot for your PR!

Could you please split this PR in 4 different PRs (part 1 has already been merged into master from your other PR)? Then I will be happy to review those changes 😉

[tszirr]

This PR now only includes the sunsky changes. See new description text at the top.

[alhirzel]

What is needed (other than a rebase :) ) to get this great work merged? Should the spectral texture loading be addressed?

[peroveh]

Was sunsky added??

[Speierers]

No it wasn't added to the Mitsuba 2 repository. Once the new codebase is release we can try to revive this PR.

[alhirzel]

@Speierers - thanks for the update, do you happen to have a rough ETA for the new code base release?

[Speierers]

@alhirzel all I can say is that it will happen before SIGGRAPH this year 😉