Partially restore 'old' sphereCorrection behaviour (prior to 4.2.0)

Hi,

I am developing an application which makes use of PSV and am coming across some problems getting it to work as intended in 4.2.0.

A bit of explanation: I load heading, pitch and roll from a server-side API rather than from the XMP data directly. The application allows users to correct heading, pitch and roll data via a web-based interface if the XMP data is inaccurate (which it frequently is), so the XMP data is sourced from a server-side API rather than directly from the image.

I can get it to work if I set useXmpData to false. However ideally I do not want to completely turn off loading all data from XMP - just the heading, pitch and roll.

The alternative approach of setting the panoData option does not work fully for my use-case. The application allows users to correct the heading, pitch and roll through controls in a web interface. See the screenshot below. The yellow line represents the route of a sequence of panos taken along the path, and the markers represent the pano positions themselves. You can see that the route is offset slightly from its real position, which is along the visible path. Note how the interface allows the user to change the heading, pitch and roll; pressing the buttons should move the panorama relative to the markers without reloading the panorama.

This works as intended on <4.2 or when useXmpData is false. It works by calling Viewer.setOption() with sphereCorrection set to the new, corrected, heading (pan), tilt (pitch) and roll values when the user presses the pan, tilt and roll correction controls shown on the screenshot below.

However if I try the same thing with panoData rather than sphereCorrection: I cannot use setOption() with panoData, I have to re-load the panorama, which is slow and does not lead to the desired effect of changing the panorama rotation relative to the overlaid markers.

Therefore, is it possible to restore part of the pre-4.2 functionality where sphereCorrection can be changed even if it was found in the XMP data? Or, alternatively, a refinement of the useXmpData option where you can set it to ignore heading, pitch and roll but use the other XMP data.

Of course, there may be a solution to what I want to achieve without doing this, but after experimentation I have not found a way. Many apologies if so and please let me know!

[mistic100]

Good catch, it was missing a recursive option on the raycaster

[nickw1]

@mistic100 to add to that: this has definitely happened with this latest commit. If I use the immediate previous commit, the select-marker event is fired as expected.