Zitat von »Teinberger«

When unzipping the krpano-1.20 folder I got the message, that krpano Tools.exe is infected with win64:Malware.gen. My virus scanner is "avast"
Could this be possible?

Definitively not!
It's a false-positive by your virus scanner.

Hi,

Zitat von »spacerywirtualne«

If I set a greater depth (to maintain the impression of different distances) e.g. above 1500, the effect is just like in the movie. It comes to the point that I can't aim the controller at hotspot at all.

That's related to the different depth distances that are used.

In previous versions the depth sizes and the width/height of hotspots in 3D space were basically unit-less and also meaning less, only the relative (!) differences between sizes was important for getting a good 3D effect.

But now - with VR and positional tracking support a physical unit gets introduced - so now there is an absolute physical reference. When the head moves around e.g. 50cm this movement must also have a representation in the krpano units.

Therefore by default now: '1 krpano unit = 1 cm unit' is used.

So a hotspot with depth=1000 means that this hotspot is 10m (=1000cm) away when viewed in VR.

For normal / non-depthmapped panos is fully okay, but in depthmap/3d-model panos a hotspot 10m avoid is typically to far away.

Therefore in the new webvr.xml the vr_cursor has a depth of 120 (=120cm) by default. That's looks better in VR and is typically in front of the 3d-model (instead of somewhere behind it, which looks bad when actually behind but still rendered above).

Now why the 'jumping' when hovering other hotspots: when hovering an hotspot the vr_cursor uses the same depth as the hotspot is hovers. And when the depths are very different (e.g. 120 and 1500) there is a noticeable difference of the stereo-displacement. At a distance of 120cm the hotspot is near to the eyes and so the left-/right-eye distance is bigger as when the hotspot 15m away.

With the vr-controllers it is similar, the 'point' is either rendered at the depth of the hotspot or at depth=1000 by default (defined in the webvr.xml in the 'vrcontroller_target_point' action). But with vr-controllers you need to image an line from the controller to that point.

By default the vr-controller style with the target point (at depth 1000) is used by default for normal panos - because hotspots also have depth=1000 by default. As long as all hotspots are using the same depth, there would be no depth-jumps when hovering something.

But for depthmap-panos the 'laser' vr-controller is used by default, there hotspots and the 3d-geometry is probably more near, and having a long line from the source (the vr-controller) into the world makes aiming easier.

Try using the laser style to see - e.g. by adding this line anywhere:



I hope this was a somehow understandable... it's a bit difficult to explain...

That means when modeling something that should also work in 3D with a physical size input, it becomes important to keep an eye to all involvement sizes.

Best regards,
Klaus

Zitat von »mstoss«

Just updated a recent project via krpano Tools - the log key option, using the "O" key, does not seem to work any longer? Is there an alternative to that to check for errors?

Now the 'tidle-key' is used instead of the 'O' key for log opening/closing.

That's the blue key shown here:


Please see also here:
https://krpano.com/docu/xml/#krpano.logkey

Hi,

Zitat von »Tuur«

i was wondering if we can use the new sound interface to play a sound at hotspot position without any VR or 3D stuff happening.

Technically the 3D sound is based on the WebAudio 3D / spatialization API:
https://developer.mozilla.org/en-US/docs…lization_basics

You can try an official browser API demo here:
https://mdn.github.io/webaudio-examples/spacialization/

Simplified said it works that way - you tell the browser where you are in 3D space and where the sound is in the 3D space. Then the resulting sound will be calculated by the browser itself.

I had to admit I have tested the '3D effect' mainly on Windows Firefox. Also because that's basically only Desktop Browser with WebVR support. And there the 3D sounds was working fine - as well with typical Stereo output and especially good also in VR. I have noticed that in Chrome the 3D effect was not so good, but as there is no way to control the browser exactly I have kept it as it is.

But I have got your reports about swapped left/right chancels on Mac and the bad stereo-location in Chrome and already started looking for solutions. I'm thinking about a kind of 'simple' 3D mode - where not the browser controls the 3D sound, instead the soundinterface will internally use a simple 2D-left/right panner to simulate the 3D direction. This way it should definitely work everywhere.

Best regards,
Klaus

Zitat von »jeromebg«

And a nice addon would also to be able to control the volume according to the fov ;)

Technically no problem, but how should the fov and the volume be linked?

Hi,

Zitat von »Aladdin_VR«

I was wondering if you are considering any alternatives to the creation of grayscale images to use the depth functionality

Yes - e.g. using everpano 3D - please see here for more information:
krpano Depthmap Support

Zitat von »jeromebg«

onloadcomplete still doesn't work as it should,

That's the intended behavior, the event will be sent once the current view is filled with any content, that can be also the preview pano or lower-res tiles.

There is already new event named 'onviewloaded' that could be used for checking if the current view is fully loaded with its best resolution, but it is not documented yet, because not fully implemented and tested for all kind of pano types and cases. Maybe try if it already works for your case.

Beside of that, when loading to another pano/scene it would be also possible to use the new PRELOAD flag, that forces not to blend until the view is fully loaded: https://krpano.com/docu/actions/#loadpano.flags

Zitat von »sblack«

http://krpano.com/forum/wbb/index.php?page=Thread&postID=76666#post76666
not ready yet? very interesting to get Altitude\Date\Time from panoramas stored in <scene>

It's already added as feature request.

Best regards,
Klaus