Posts by nicoclark

Quote from s-maier

Sounds like cache related on your side.

Thanks, I will bear that in mind next time.

Just to explain this plug-in issue. I upgraded my KR pano js to 1.22 and the demo warning in my site disappeared. The plug-ins the site was referencing were from 1.20. As soon as I replaced even one of the plug-in files from the 1.22 plug-ins folder the demo warning appeared again. The solution to this was to upgrade the JS file again and then the demo warning disappeared.

Thanks for the offer of Email support. But I'm sure you've got a lot to do. If it's just a couple of days then I can certainly wait Klaus.

Regarding the new plug-ins it seems that if you replace them after you've upgraded your license you need to upgrade your license again.

------

On the issue of the different behaviour in a conditional code execution I'm relieved not to be the only one who is affected. Not sure how quickly you're planning to bring out a new version but until then would you recommend that we don't upgrade until the next release?

Is there a way that we can avoid this problem just by writing our code slightly differently.? I would really like to utilise the other excellent advances in version 1.22

On your recommendation, I'm trying to update the plug-ins now. They generate a license upgrade notice when I reload the page. Do I need to upgrade the plug-ins or something?

Quote from klaus.krpano

There were not fundamentally changes and code isn't interpreted differently.

If you want, you can send me your example (not encrypted of course) and I can take a quick look. It can be only a very minor thing, maybe really related to tween calls...

At the moment, I'm just going to do a little bit of experimenting to see what is different. If I get very stuck I may well take you up on your kind offer, Klaus.

Quote from indexofrefraction

first thing: the plugins you use are from 1.20 and do not match the used krpano 1.22

this is for sure problematic and you should replace the krpano plugins folder with the one from 1.22

That's an interesting point, thanks for mentioning it. Do the plug-ins really change from one version to the next and if they do, would they work differently and change the overall function?

I've actually repaired those uninitialised tweens. It doesn't change the fact that the site functioning very differently when the same code is being loaded with version 1.21 and 1.22..

There must be something else in the basic viewer code which has changed, meaning that the existing code is being interpreted differently. I will probably spend many hours hunting for the changes but it would be very helpful to have some tips as to what might be fundamentally different in how it executes existing code since the last version.

I do apologise for referring to the failures in functionality as crashes, Klaus. That's not correct it's just that the site as you can see behaves quite differently if you run the same code using 1.21 and 1.22. I have no idea whether my code was badly constructed or not, but it was working as I intended before and now it's doing something quite different.

I can certainly go through and look for tweens that have been called without an initial value and hopefully that will solve all of the issues that I'm experiencing.

This is the current version using 1.21.2 it doesn't crash but the new 1.22 version crashes

So I guess the concept is that before I was making a big mistake, but I was getting away with it. From now on no more Mr. Nice Guy!

Last time with (the excellent) 1.21 update it took many days work to get our existing code to work again. The issue was mostly syntax changes and older functions that had been replaced or renamed.

This (also excellent) 1.22 update is also causing quite a number of malfunctions. It would be really helpful Klaus if you could point out where to start looking for changes that need to be made to our existing code. This is the current version using 1.21.2 With the new 1.22 version as you can see there seems to be a lot of work to be done to get it functioning as before.

I imagine the indications of what needs to be changed are somewhere in the release notes but I would really appreciate a few quick tips as to what the most fundamental changes are.

This is what I can see at the moment:-
WARNING: There is already a blocking lookto(), the current call will be skipped!

WARNING: tween() - layer[menu1].alpha doesn't exist!  [3x]WARNING: tween() - layer[infopanel].height doesn't exist!WARNING: tween() - layer[infopanelitem].height doesn't exist!WARNING: tween() - layer[infotranslate].y doesn't exist!WARNING: tween() - layer[menu1].alpha doesn't exist!

I am going to follow your advice Klaus and reduce these image sizes. One thing I did want to point out is that this crashing problem is only an issue when we're operating mobile VR. I never have crash problems with the normal iOS functionality.

Oh I see! Sorry I forgot about those completely.
I've been using these big imag files as a way of avoiding loading lots of separate images for the UI icons. Basically, we load one image and then we use crop to select an section of it. I kind of got the impression that that was the best way to work.
Do you think I need to split these into more separate images and reduce the overall size that's loaded?

Thanks for the very detailed response, Klaus. I do really appreciate the fact that you've looked into the link and analysed what's going on.

Is there a different approach for dealing with text fields so that it doesn't affect the GPU memory usage so much? Should I set the renderer as web GL?

You said my example uses large images. Do you mean panoramic tiles because I can't see any other images that would be loaded there? So to set a smaller image size which images do I need to make smaller?

Bravo Klaus!
Particularly delighted about the Vision OS support. I'm hoping that it will make it possible to use the Apple Simulator to test VR without actually having to have a headset in your hands.

I'll give it a go when I get a moment.

There is such a difference between the mobile VR layout on the three main browsers for iOS. I'm not sure how best to set the mobilevr_profile to optimise it in each case.

In the documentation it says.

The default value (for Cardboard V1 headsets):

• Code

  "80|60|42|35|0.441|0.156"

But which browser with this relate to?? And how should it differ for these different layouts?

I appreciate your input index, although I'm not sure that could be the case.

If it is a memory issue why is it that would only happen when you change into VR? The site doesn't crash when it's originally loaded. The memory you're loading is no greater when we start VR it's just the fact we are calling up a different functionality.

You can see the example link I sent has got very little content in it apart from the panorama. 7.6 MB is loaded at the start and when you load VR it goes up by less than one megabyte.

Just an update on this point. I have the same problem this morning. Probably 10 other apps open on the iPhone. And the site would crash every time VR was launched in Safari. I closed all the other apps and then it launched properly. Then I launched the podcast app and launched it again successfully. But if I actually played a podcast and then try to launch it, it would crash.

This actually doesn't happen in Firefox or Chrome on the iPhone so the issue is specifically with Safari. It would be helpful to be able to describe it and maybe create a ticket at Apple. Not something I've ever done before.

I'm just wondering, is this a problem only for me or for other KR pano users?

Glad to see that my post helped you to solve the same problem.