Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: krpano.com Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Montag, 14. Mai 2018, 23:33

krpano.view.hlookat positive/negative flipping.

I've noticed what I think may be a bug or some weird behavior that is causing some downstream issues. In Chrome 66 with the latest version of KRPano, krpano.view.hlookat is either positive or negative and keeps increasing if you spin clockwise or decreasing if counterclockwise. In the Gear/Oculus browser in WebVR mode however, hlookat basically flips from positive to negative at 165 degrees/-195 degrees. This quick flipping between positive and negative values is creating a bit of a problem in the WebVR version.

I'm really sure if this is a gyro, webvr or just a browser issue so I'm not really sure the best way to solve it. Any idea what is going on/why the inconsistency?

EDIT: A little more investigation makes me believe it is gyro related. On my iphone, if I spin the view with my finger, hlookat keeps incrementing without flipping back and forth between positive and negative 180 degrees from the initial view like the desktop browser while if spin using the gyro, the lookat x flips between positive and negative. The reason the example above was 165 instead of 180 is the initial view has a -15 degree offset.

Nevertheless, this inconsistency is creating a problem since we processing the lookat data with a smooting algorithm to pass to a different device and this quick transition back and forth between positive and negative values and the inconsistency between navigation/input methods is making this a difficult to solve. It seems to me the viewer should return the same data regardless of the method used to spin the view no?

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »bhh« (15. Mai 2018, 00:37)


2

Dienstag, 15. Mai 2018, 09:41

Hi,

that's normal - the looking direction in the webvr/gyro usage case will come from a Quaternion which will be converted to the hlookat/vlookat/camroll Euler angles.

That means there is no continuous relative motion in Euler angles there (and not possible).
Flipping around the +180/-180 edges is something that always would need to get considered.

For smoothing such data try converting the Euler angles to Quaternions, interpolate there and then convert back (that should be the most common way for 3d rotations).

Or here a more simple solution if you only need continuous hlookat data - track the hlookat changes, check for the shortest distance around the circle and add only the relative shortest change:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
<events onviewchange="continuous_tracking();" />

<action name="continuous_tracking">
    if(last_hlookat === null, copy(last_hlookat,view.hlookat));
    if(cont_hlookat === null, copy(cont_hlookat,view.hlookat));
    
    calc(d1, view.hlookat - last_hlookat);
    calc(d2, view.hlookat+360 - last_hlookat);
    calc(d3, view.hlookat-360 - last_hlookat);
    Math.abs(ad1,d1);
    Math.abs(ad2,d2);
    Math.abs(ad3,d3);
    
    if(ad1 LT ad2 AND ad1 LT ad3,
        add(cont_hlookat,d1);
      ,ad2 LT ad1 AND ad2 LT ad3,
        add(cont_hlookat,d2);
      ,
        add(cont_hlookat,d3);
    );
    
    copy(last_hlookat,view.hlookat);
    
    trace('view.hlookat=',view.hlookat,' cont_hlookat=',cont_hlookat);
</action>


Best regards,
Klaus

3

Dienstag, 15. Mai 2018, 15:27

Thanks Klaus! That is super helpful and I'm sure I'll be able to run with one of these solutions.

Before we were basically just using a moving average of the last 30 or so data points which was a good tradeoff between delay and smoothness but obviously created issues when it flipped back and forth between positive and negative.

EDIT. So we implemented your strategy above (via Javascript within the plugin) to feed the smoothing algo continuous hlookat data and it worked perfectly. Thanks so much Klaus.

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »bhh« (15. Mai 2018, 17:14)