The reason for this problem is that the new krpano version tracks and caches the currently used internal WebGL 'program' - and Three.JS is changing the current WebGL program by its own and so messes that tracking.Another question :
I am using three.js in my project, after upgrading my project from krpano 1.19-pr3 to krpano 1.19-pr4, panorama does not shown in the scene.
Actually three.js add a black layer on the scene.
Will be fixed in the next release.The interaction between autorotation and simulated WebVR has changed in PR4. In PR3 when you move the mouse to move the display it pauses autorotation in the same way that manually dragging does normally. In PR4 there is no pause making for a less accurate simulation. I doubt that was intentional?
Use the lookat action from the WebVR plugin for this:As I remember initial "view.hlookat" wasn't possible to specify individually on each scene on previous versions for WEBVR, is it possible now with this release?
|
|
Quellcode |
1 2 3 |
<events name="webvr_hlookat" keep="true" onxmlcomplete="if(webvr AND webvr.isenabled, webvr.lookat(get(xml.view.hlookat)));" /> |
Only whole files will be tracked.i find out when set <Image> label type to sphere, the progress.progress value is always 0
Disable the user control:New autorotate functions are very cool. But in one of my projects I have a pano where user must not stop autorotation in any way. How do I make autorotation ignore all user interaction and stay rotating constantly?
Yes - krpano has full WebVR API support.Forgive me if this has been addressed already, but will the panoramas work seamlessly with an Oculus? I have a potential job that wants to use one.
I had userconrol disabled already, yes. Here's a small test:Disable the user control:New autorotate functions are very cool. But in one of my projects I have a pano where user must not stop autorotation in any way. How do I make autorotation ignore all user interaction and stay rotating constantly?
http://krpano.com/docu/xml/#control.usercontrol
|
|
Quellcode |
1 |
onstart="autorotate.start();set(control.usercontrol, off);" |
Benutzerinformationen überspringen
Wohnort: Mexico City
Beruf: Virtual tours, Krpano coding, Graphic Design, Photographer, Panographer
Zitat
and remove all 'KEEPMOVING' occurrences from the vtourskin.xml.
.
Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von »Scott Witte« (4. Mai 2016, 20:56)
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Scott Witte« (27. April 2016, 23:58)
That was already reported (a few posts before) and is already on my list. I'm not sure yet what could cause that, but I hope to find out soon.It seems PR4 is adding a default OX OY offset
That's also already on my list, but that's more complex - it requires different viewing and rendering handling - the current horizontal viewing direction would need to be stored for the previous pano as kind of horizontal offset when changing the view for the new pano...think is the most comfortable way to blend between panos without "taking the image with you as you move your head
Maybe the GPU driver of that device was blacklisted by Chrome?After the last update Google Chrome Mobile on tablet Nexus 7 2012 stopped working krpano 1.19.4
The WebVR plugin switches in FAKE mode only to fullscreen mode when the browsers supports the Pointer Lock API - and the IE11 doesn't do that. That direct moving control mode in the fake mode is also only possible when the browser supports that API.Fake VR doesn't seem to work properly in IE11 (desktop). When I go into VR mode it does not go full screen, moving (vs dragging) the cursor has no effect and the Fake VR mode message does not disappear. This was also the case with PR3.
Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von »panomexico« (28. April 2016, 12:04)
With the 1.19pr4 version hotspot with edge different from center have a 10px offset ?
I found the reason now - it affects hotspots without zoom=true or distroted=true and an edge setting different to center. That problem was a more complex conflict with applying an internal zoom scaling to keep the hotspot size the same regardless of the current view zoom. That will be fixed in the next release (should be ready soon).It seems PR4 is adding a default OX OY offset
Das liegt an Apple selbst - Apple erlaubt keine höheren Auflösungen im iOS Browser, obwohl die Hardware vieler iOS Geräte mehr könnte.Ich habe das Video in 5 Auflösungen bereit gestellt, das iPhone und das iPad machen nur bis 2048x1024 mit, wie kann ich in der videopano.xml
die 4096x2048er Auflösung für die mobilen Geräte ausblenden, auf dem PC funktioniert die 4096x2048 Auflösung, deshalb möchte ich diese drin lassen.