If Transitions are this broken...what are YOU using?

[Branigan]

Edit: Just watch the video first if you use Pro and also use Transitions... https://youtu.be/d20hJKu_q2w

---------------------------------

This was using v6.1.8, haven't downloaded and tested 6.1.9 yet; but no mention of these fixes in the blog, so likely still present.

If you have Pano2VR Pro you can skip to the video section where I'll explain how broken Transitions are, the FoV mode is set wrong by default and why you've (possibly) been doing it wrong all this time, because otherwise you'd have noticed it too.

Video is 5 mins long, watch at x2 speed and still get the gist, if you can read text captions quickly.

-------------
OK, if you also use Pano2vr Lite and want to know why I was checking out Transitions in Pano2vr Pro, or just want the background; here goes...

As I'm getting very bad results when transitioning between URLs in Lite, with Black (or White) screens, followed by piecemeal buildup of the panorama and Hotspot Icons floating in an empty screen (found a fix for that thanks to Hopki, but you're all probably still doing it wrong too, it's the weird default settings getting you again), and Preview tiles often not loading before the full Res tiles, I went back to a demo of Pro to see if the extra cost was worth it for those sweet, sweet Transitions, with all my problems disappearing.

(Spoiler: Nope).

I have found that IE exhibits these problems less than my preferred Firefox - even though I'd never usually use IE myself - but other browsers on iPads, iPhones, Android Tablets and phones are all varying degrees of 'just as bad' as Firefox.

As my PC screen recording software seems to be getting its data from some buffer that's slightly different to what you see and at too slow a framerate to catch all the details, I recorded this with a camera at 60fps then extracted individual frames.

These screenshots show the Loading bar is a work of fiction, Preview Tiles sometimes don't show up and holes are left where they should be, while the Full Res tiles are already visible. I know the Preview tiles aren't appearing, because I've added a Gaussian Blur to them, which looks better than the blocky alternative of low quality and small size with the added advantage of even smaller filesizes (blurred images need less data), so the visual difference is obvious.

You also see the Hotspots (when they're embedded in skin.js) are not only contributing to a larger, slower-loading skin.js, as their data is encoded as Base64 text; they are displayed before anything else, so appear floating in space and looking...silly.

Faster and better is to change the Inline Image size from the (yet another one...) Default of 10000 bytes to 10 bytes; so all images are exported as PNGs and loaded at the right time, making skin.js run faster and producing smaller filesizes. Thanks to Hopki for that one yesterday.
.

New_URL1.jpg (75.34 KiB) Viewed 4527 times

New_URL2.jpg (50.55 KiB) Viewed 4527 times

New_URL3.jpg (86.82 KiB) Viewed 4527 times

New_URL4.jpg (41.29 KiB) Viewed 4527 times

.
Video Section
----------------------
To see if Pro was worth upgrading to, I installed the Pro Trial on a second PC and tested out what I was hoping would be improvements.

I did find that Transitions don't work at all between URLs, only Nodes, despite the option being available. Not sure why/how it would be so hard to store the panorama of the last URL and even just allow a Cross Dissolve/Iris/Wipe between that and the next one - Zooming possibly being too complicated? - but assume that's because you're not supposed to Upgrade; you just buy Pro first and make all your Panoramas in it.

If you look at the photos above you'll see the one where the next URL's hotspot was already loaded and visible and being drawn over the panorama of the current one, when it supposedly hadn't been loaded yet; so it apparently would be possible to do something similar(ish) with actual panoramas.

Maybe even using those vestigal appendix-like files: location_ovr.jpg which is a mini 512x256 panorama image that could be displayed as an alternative to a flipping Black or White screen? Hmmm.. maybe?

I'd have to remake all my URL linked panoramas as Node-based again because of this, so would it be worth it? Place your bets now...

The video below shows that not only are Transitions not worked properly, there are very limited options available (when zooming anyway; irises and wipes are just... no.).

If you didn't notice this before it's possibly because you've got the FoV Mode set on the default value of Vertical - which is for Mobile phones in Portrait/upright mode- and forgot to change it when you made your deskstop-centric tours. Well, why would you? Defaults are there for a reason, right?

Not only does this hide some of the brokenness of the Transitions, but if you don't change it - even if not using Zooming or other Transitions, or just using a Cross Dissolve - your Panoramas FoVs will look wrong on anything other than the desktop you developed on; because you will have adjusted the Default View FoV to look right on the desktop, using the wrong FoV Mode, so when you do view it on mobile, it's wrong for that. It also scales hotspots differently and they get quite small.

The video shows the problems with using Transitions with Zooms, in an attempt to look something less boring than a cut or a crossfade, and closer to Matterport and others. Although once you set FoV Mode to Vertical, there are several other places where it causes problems; most notably in the Viewing Limits and FoV Min/Max areas.

You do set those to stop people zooming in and out by silly amounts? No? Then you're less affected.

5 Minute video here: https://youtu.be/d20hJKu_q2w
.
So, given that Transitions aren't working correctly when I want to display panoramas on both Landscape/Desktop/Horizontal and Portrait/Mobile/Vertical and the setting that covers these: Diagonal, messes them up, I'll delay the upgrade to Pro just yet.

But if you already have Pro, how are you managing/avoiding these problems?

[Branigan]

Moved the video link to the top of the previous post for people who:

a) use Pan2vr Pro and
b) use Transitions and don't want to read all my waffle before getting to the point.

[Branigan]

Edit: Just watch the video first if you use Pro and also use Transitions and have left FoV Mode:Vertical (Mobiles)... https://youtu.be/d20hJKu_q2w

---------------------------------


If you have Pano2VR Pro you can skip to the video section where I'll explain how broken Transitions are, the FoV mode is set wrong by default and why you've (possibly) been doing it wrong all this time, because otherwise you'd have noticed it too.

Video is 5 mins long, watch at x2 speed and still get the gist, if you can read text captions quickly.

-------------
OK, if you also use Pano2vr Lite and want to know why I was checking out Transitions in Pano2vr Pro, or just want the background; here goes...

As I'm getting very bad results when transitioning between URLs in Lite, with Black (or White) screens, followed by piecemeal buildup of the panorama and Hotspot Icons floating in an empty screen (found a fix for that thanks to Hopki, but you're all probably still doing it wrong too, it's the weird default settings getting you again), and Preview tiles often not loading before the full Res tiles, I went back to a demo of Pro to see if the extra cost was worth it for those sweet, sweet Transitions, with all my problems disappearing.

(Spoiler: Nope).

I have found that IE exhibits these problems less than my preferred Firefox - even though I'd never usually use IE myself - but other browsers on iPads, iPhones, Android Tablets and phones are all varying degrees of 'just as bad' as Firefox.

As my PC screen recording software seems to be getting its data from some buffer that's slightly different to what you see and at too slow a framerate to catch all the details, I recorded this with a camera at 60fps then extracted individual frames.

These screenshots show the Loading bar is a work of fiction, Preview Tiles sometimes don't show up and holes are left where they should be, while the Full Res tiles are already visible. I know the Preview tiles aren't appearing, because I've added a Gaussian Blur to them, which looks better than the blocky alternative of low quality and small size with the added advantage of even smaller filesizes (blurred images need less data), so the visual difference is obvious.

You also see the Hotspots (when they're embedded in skin.js) are not only contributing to a larger, slower-loading skin.js, as their data is encoded as Base64 text; they are displayed before anything else, so appear floating in space and looking...silly.

Faster and better is to change the Inline Image size from the (yet another one...) Default of 10000 bytes to 10 bytes; so all images are exported as PNGs and loaded at the right time, making skin.js run faster and producing smaller filesizes. Thanks to Hopki for that one yesterday.
.

New_URL1.jpgNew_URL2.jpgNew_URL3.jpgNew_URL4.jpg
.
Video Section
----------------------
To see if Pro was worth upgrading to, I installed the Pro Trial on a second PC and tested out what I was hoping would be improvements.

I did find that Transitions don't work at all between URLs, only Nodes, despite the option being available. Not sure why/how it would be so hard to store the panorama of the last URL and even just allow a Cross Dissolve/Iris/Wipe between that and the next one - Zooming possibly being too complicated? - but assume that's because you're not supposed to Upgrade; you just buy Pro first and make all your Panoramas in it.

If you look at the photos above you'll see the one where the next URL's hotspot was already loaded and visible and being drawn over the panorama of the current one, when it supposedly hadn't been loaded yet; so it apparently would be possible to do something similar(ish) with actual panoramas.

Maybe even using those vestigal appendix-like files: location_ovr.jpg which is a mini 512x256 panorama image that could be displayed as an alternative to a flipping Black or White screen? Hmmm.. maybe?

I'd have to remake all my URL linked panoramas as Node-based again because of this, so would it be worth it? Place your bets now...

The video below shows that not only are Transitions not worked properly, there are very limited options available (when zooming anyway; irises and wipes are just... no.).

If you didn't notice this before it's possibly because you've got the FoV Mode set on the default value of Vertical - which is for Mobile phones in Portrait/upright mode- and forgot to change it when you made your deskstop-centric tours. Well, why would you? Defaults are there for a reason, right?

Not only does this hide some of the brokenness of the Transitions, but if you don't change it - even if not using Zooming or other Transitions, or just using a Cross Dissolve - your Panoramas FoVs will look wrong on anything other than the desktop you developed on; because you will have adjusted the Default View FoV to look right on the desktop, using the wrong FoV Mode, so when you do view it on mobile, it's wrong for that. It also scales hotspots differently and they get quite small.

The video shows the problems with using Transitions with Zooms, in an attempt to look something less boring than a cut or a crossfade, and closer to Matterport and others. Although once you set FoV Mode to Vertical, there are several other places where it causes problems; most notably in the Viewing Limits and FoV Min/Max areas.

You do set those to stop people zooming in and out by silly amounts? No? Then you're less affected.

5 Minute video here: https://youtu.be/d20hJKu_q2w
.
So, given that Transitions aren't working correctly when I want to display panoramas on both Landscape/Desktop/Horizontal and Portrait/Mobile/Vertical and the setting that covers these: Diagonal, messes them up, I'll delay the upgrade to Pro just yet.

But if you already have Pro, how are you managing/avoiding these problems?

[Hopki]

Hi Branigan,
Matterport is CGI with texture and uses a completely different process. Where the rooms are not symmetrical, the effect falls apart and can look quite nasty. We will be looking at transitions in the next major release but not something we will be addressing in V6.
The current default is cross dissolve which is not going to light up the world but for most people this being the default is fine, interesting to note that most high-end property tours I have seen the owners really don't want all this zooming in and out but that's not to say we should not do better in the future.

But this all said if I am going to use a transition which is most of the time for me, starting with the default settings I prefer to use Zoom In before and Zoom In after with Wait for transitions deselected and Zoomed FoV set to 40.00.
How good this looks depends on the distance between nodes.
As an example, the Layer Marney Tower tour has this transition: https://ggnome.com/samples/pano2vr_5/tower/
This could be better improved by the nodes being closer together, but not that close that you see the same content in the next node.

If you find a combination of settings which are preferable then you can set up an output template.
Set up your output settings how you want then save as a template.

1.png (25.7 KiB) Viewed 4405 times

Give your template a name.

2.png (14.95 KiB) Viewed 4405 times

When starting a new project, select the green + button as normal but this time select your template.

3.png (39.9 KiB) Viewed 4405 times

Regards,

[Neal]

It should be noted that Matterport generally requires the nodes to be within 10-12 ft of each other. At that short of a distance, it doesn't take much of a zoom effect. One side zooms 5ft and so does the other. Not really that fancy. In truth, there are far more interesting transitions that can be done going from one room to another as opposed to having to move 10ft at a time.

[Branigan]

Hi Branigan,
Matterport is CGI with texture and uses a completely different process. Where the rooms are not symmetrical, the effect falls apart and can look quite nasty. We will be looking at transitions in the next major release but not something we will be addressing in V6.
The current default is cross dissolve which is not going to light up the world but for most people this being the default is fine, interesting to note that most high-end property tours I have seen the owners really don't want all this zooming in and out but that's not to say we should not do better in the future.

Martin,

(tl;dr: One line of code change would fix the problem for 95% of your customers)

Thanks for the reply, but your explanations don't indicate that you've watched the video all the way through, or quite understood my point?: https://www.youtube.com/watch?v=d20hJKu_q2w

It's only 5 minutes long and you can watch it at 2x speed and still see the problems. From half way is where the meat is.

For everyone else: the single adjustment value 'Zoomed FoV' is used both for Zoom in and Zoom out, except the range for one is the inverse of the other.

That's why you have a too long (IMO) Zoom In to your destination panorama in that example at your link. Short leaving Zoom, Long arriving Zoom.

Try to make it shorter? You can't. Yet. But read on and you could.

Currently, if you want a short Zoom In before the transition you set the Zoomed FoV value to 40 (range is 0-50).
If you want a short Zoom In after the transition you set the Zoomed FoV value to 10 (range is 0-50).

If you use the 'wrong' value for the 'wrong' zoom the results are bad.

If you want a Zoom In both before and after the transition you cannot set it to a short value for both, because what is short for one is long for the other. The midrange value of 25 looks quite awful.

Then there is the 'Wait For Transition' check box. This only applies to a Zoom In after the transition. This is better deselected to give the Cross Dissolve combined with the Zoom In after at the same time.

The only 'least bad' options (IMO) you can set are: Cross Dissolve, Trans Time 1.0, Before: None, After: Zoom In, Wait: Unticked, Zoomed Fov: 10, Speed 1.0.

This gives a Cross Dissolve over a gentle, short Zoom In to the next panorama. You have a sense of moving into the destination, without it looking like warp speed, or taking too long.

The ideal setup would be a Short 0.5 second Zoom In of the current pano, followed by that Cross Dissolve across a 0.5 second Zoom In into the destination pano.

So you would start to move, then you fade into the arrival. It's not flashy, it's not nauseating, it's just...pleasant, and short; although you could make it gentler and longer on both sides to suit your requirements.

This is not currently possible, because you can only set the Fov Zoomed value to 25 (if you want both sides to be equally long) , which produces both a too long Zoom In before and after the Cross Dissolve. You can play with the Zoom Speeds, but higher values just make you feel sick.

This is a VERY easy thing to fix. Invert the ranges of ONE of the Zoomed FoV sides in the code. Either the Before, or After, it does not matter which. Then you would be setting the Distance of the Zoomed FoV to the same values either side of the change in panos.

You want a short Zoom In on both sides of the switch over? Set it to 10. Even shorter? 5.
You want a long Zoom In on both sides of the switch over? Set it to 40. Even longer? 45. Easy. That's the fix.

Ideally they wouldn't be sharing a value at all and be independent, but this single change is the least possible effort and risk.

Except, of course it's not that easy when you set your project's FoV Mode to Diagonal, when the other maths falls over. That also needs fixing urgently, but for the 95% of people who still have their Default view set up to the Vertical setting intended for Mobiles but don't realise: they could have better, working Transitions in the blink of an eye.

It's not like inverting one of those values would break things for anyone, because it's unlikely they're even using it, given the current results.

This could be done in a point release by changing one line of code. I wouldn't even benefit because a) I'm using Light, which doesn't even have Transitions and b) I'd still need the Vertical vs Diagonal fix doing before I'd upgrade to Pro, which seems to be taking a while to get recognised as an actual problem, but 95% of your other customers would have much better Transitions.

Like these:
.

zoomfade.gif (924.95 KiB) Viewed 4374 times

.

gnomefade.gif (874.7 KiB) Viewed 4369 times

.

gnomefade2.gif (1 MiB) Viewed 4367 times

[Hopki]

Hi Dave,
I watched all of your video and the FoV not being equal for the Before and After has already been reported.
I know at first looks this will be a simple thing to fix, and that may well be the case, but experience tells me one small change can lead to causing issues elsewhere.
But rest assured it is on our radar.
Regards,

[Branigan]

Hi Dave,
I watched all of your video and the FoV not being equal for the Before and After has already been reported.
I know at first looks this will be a simple thing to fix, and that may well be the case, but experience tells me one small change can lead to causing issues elsewhere.
But rest assured it is on our radar.
Regards,

If flipping a single value isn't good enough (you could try and see though?) then the way to not have any issues is to separate the two values out, so people can still have a short Zoom In before and a long Zoom In after...if they really want something so wonky. Plus they'd only need to even be aware of the change if/when they made a New pano, so make it clear in the Fixed: notes.

But the need is gettting real now with the new kid on the block www.metareal.com which is out-matterporting Matterport with a much cleaner Doll's house that requires fewer images - because either you construct it yourself, or pay them to do it at $2-$4 per pano and you can use any camera and upload your own images, so they can be processed better than uploading directly from the Matterport app.

It also create Floorplans, which Matterport doesn't, and is much cheaper to host images (based on storage, not locations) and while you can't currently click on a room in the Doll's house to go to it directly (Matterport have various patents that may prevent that) you can from the floorplans.

Things are continually getting more competitive and Pano2VR's USPs aren't quite as U as they used to be, so it needs to step up or make it clear what market it is aiming for; because Text to Speech was so niche as to be able to count the number of people who would actually use and benefit from it on the fingers of one foot.

[Neal]

If that metareal is the competition, Pano2VR doesn't have much to worry about. Those were terribly jerky and the doll-house feature is a yawn. I agree that the zoom feature in Pano2Vr is not very good, but having a good zoom transition wouldn't be in the top 10 features that I would want to improve. Neither the Matterport nor the metareal zoom transitions are very pleasing and you have to do a pano every few feet even for those. I am far more concerned with how fast the panos load, how they display on different devices, a strong API with good documentation, a CSS based skin, how the panos can be integrated with my current site, and an interface with larger text.

[Branigan]

If that metareal is the competition, Pano2VR doesn't have much to worry about. Those were terribly jerky and the doll-house feature is a yawn. I agree that the zoom feature in Pano2Vr is not very good, but having a good zoom transition wouldn't be in the top 10 features that I would want to improve. Neither the Matterport nor the metareal zoom transitions are very pleasing and you have to do a pano every few feet even for those. I am far more concerned with how fast the panos load, how they display on different devices, a strong API with good documentation, a CSS based skin, how the panos can be integrated with my current site, and an interface with larger text.

I agree with most of that but Pano2vr has: wibbly hotspots, underwhelming, busted or outdated transitions (seriously... irises?) while the world moves on; and while I'm having fun learning how to manipulate things down to the pixel: (RIP Russell Kirsch), the 'self assembly' nature wouldn't look out of place in an IKEA catalogue. Its main advantage for me is being able to host the results anywhere and be in complete control, rather than have your panos disappear if you stop paying the monthly fee.

Metareal is just one of many other competitors and certainly has its own issues; speed of initial loading being one, but ditto P2VR unless you start pruning/combining the repeat elements in the skin and being careful about the size of your assets and tiles and not hosting everything as SVGs and PNGs in the skin. But measurements and floorplans are useful for Real Estate and are quick to produce once you know the height of the camera, or just one other known distance in the room, even if you turn off the - overblown, but still popular - doll's house. Plus, I suspect the examples have everything including the kitchen sink crammed in there to show off everything it can do.

You also don't need panos every few feet, that's the advantage over Matterport. You can have as little as one pano per room and it'll still look about as good as Google Maps going though a doorway - which people are used to - if you have the floorplan in place. Or if not making one of those: just throw a rough box around the room and it'll smoosh that. Watch the first few tutorials on the 3D creation side. Pretty interesting, and you could pay the $2-$4 per pano to get them to do the more complicated rooms, but it looks like you could knock up most standard locations in a few minutes to the "Not 100% accurate, but you get the idea" standard that most expect and understand once you got up to speed.

But it's horses for courses and I don't think Real Estate is P2VR's preferred audience anyway. There could be (probably is, if I bothered to look) a market in creating skins for P2VR because making a custom one yourself requires time and energy you could better spend elsewhere. There is always something to tinker with...

[Neal]

If that metareal is the competition, Pano2VR doesn't have much to worry about. Those were terribly jerky and the doll-house feature is a yawn. I agree that the zoom feature in Pano2Vr is not very good, but having a good zoom transition wouldn't be in the top 10 features that I would want to improve. Neither the Matterport nor the metareal zoom transitions are very pleasing and you have to do a pano every few feet even for those. I am far more concerned with how fast the panos load, how they display on different devices, a strong API with good documentation, a CSS based skin, how the panos can be integrated with my current site, and an interface with larger text.

I agree with most of that but Pano2vr has: wibbly hotspots, underwhelming, busted or outdated transitions (seriously... irises?) while the world moves on; and while I'm having fun learning how to manipulate things down to the pixel: (RIP Russell Kirsch), the 'self assembly' nature wouldn't look out of place in an IKEA catalogue. Its main advantage for me is being able to host the results anywhere and be in complete control, rather than have your panos disappear if you stop paying the monthly fee.

Metareal is just one of many other competitors and certainly has its own issues; speed of initial loading being one, but ditto P2VR unless you start pruning/combining the repeat elements in the skin and being careful about the size of your assets and tiles and not hosting everything as SVGs and PNGs in the skin. But measurements and floorplans are useful for Real Estate and are quick to produce once you know the height of the camera, or just one other known distance in the room, even if you turn off the - overblown, but still popular - doll's house. Plus, I suspect the examples have everything including the kitchen sink crammed in there to show off everything it can do.

You also don't need panos every few feet, that's the advantage over Matterport. You can have as little as one pano per room and it'll still look about as good as Google Maps going though a doorway - which people are used to - if you have the floorplan in place. Or if not making one of those: just throw a rough box around the room and it'll smoosh that. Watch the first few tutorials on the 3D creation side. Pretty interesting, and you could pay the $2-$4 per pano to get them to do the more complicated rooms, but it looks like you could knock up most standard locations in a few minutes to the "Not 100% accurate, but you get the idea" standard that most expect and understand once you got up to speed.

But it's horses for courses and I don't think Real Estate is P2VR's preferred audience anyway. There could be (probably is, if I bothered to look) a market in creating skins for P2VR because making a custom one yourself requires time and energy you could better spend elsewhere. There is always something to tinker with...

My first question is why you are having an issue with load speed? You shouldn't have to do any of that to have a good download speed. I just put up a high-resolution tour with 32 panos, ~60 photos, music, SVG floor plans and icons, and a thumbnail menu, both Yslow and Pingdom gave the page an 'A' rank for page speed. The online time is 1.8seconds. That's really good for an image page with caching turned off.

The floor plan creation is nice, but overkill for the floor plan I use for navigation. If you are going to make a floorplan you need to be either 100% accurate or clearly not accurate. Illustration works really well to create a simple floor plan. Pull the room dimensions from the MLS, type them directly into illustrator, and stack the rectangles like legos.

There is a trade-off between quick and easy, and having full control. The more control you have, the more there is to learn, and the more you need to put into the initial setup. The simple fact is that the more you customize a product, the more time it takes. Metareal and Manterport are good products. They make pano easy and generally quick. The downside is higher costs, your panos looking very similar to everyone else's, limited customization options and limited options for incorporating them into your site.

[Branigan]

My first question is why you are having an issue with load speed? You shouldn't have to do any of that to have a good download speed. I just put up a high-resolution tour with 32 panos, ~60 photos, music, SVG floor plans and icons, and a thumbnail menu, both Yslow and Pingdom gave the page an 'A' rank for page speed. The online time is 1.8seconds. That's really good for an image page with caching turned off.

Well, it does depend on your target audience, but my response is: how are you not having problems?

Storing everything as PNGs and SVGs in the skin is one way to slow things down on more modest viewing hardware with less RAM, slower processors or a mobile or less-than-stellar landline connection.

I have fast fibre optic broadband, but I know more remote/rural viewers (based on the locations of the customers themselves) have internet speeds of 1/10th or less than what I have and dodgy mobiles/tablets that barely pick up a 3G connection, with no chance of 4G even when standing at the top of a hill. So I assume the worst: a 4 year-old mobile phone/tablet with a poor connection. If it works on that, it flies on anything else.

I have lightweight mobile versions with quarter-sized (half width/height), Single Res tiles (because I've seen the traffic of the Multi-Res) and I'm also considering adding a really light mobile version where the maximum tile size is 400, so like a 1600x800 panorama. All assets in the Images folder are also resized. Happily, P2VR will treat a 2000x1000 image the same as a 200x100 image and just load and display it with no other changes needed. Looks almost the same on even a 6.5" mobile screen.

Tony's tutorial here is very instructive on where you can tidy things up. Every little helps.

https://tonyredhead.com/pano2vr

[Neal]

My first question is why you are having an issue with load speed? You shouldn't have to do any of that to have a good download speed. I just put up a high-resolution tour with 32 panos, ~60 photos, music, SVG floor plans and icons, and a thumbnail menu, both Yslow and Pingdom gave the page an 'A' rank for page speed. The online time is 1.8seconds. That's really good for an image page with caching turned off.

Well, it does depend on your target audience, but my response is: how are you not having problems?

Storing everything as PNGs and SVGs in the skin is one way to slow things down on more modest viewing hardware with less RAM, slower processors or a mobile or less-than-stellar landline connection.

I have fast fibre optic broadband, but I know more remote/rural viewers (based on the locations of the customers themselves) have internet speeds of 1/10th or less than what I have and dodgy mobiles/tablets that barely pick up a 3G connection, with no chance of 4G even when standing at the top of a hill. So I assume the worst: a 4 year-old mobile phone/tablet with a poor connection. If it works on that, it flies on anything else.

I have lightweight mobile versions with quarter-sized (half width/height), Single Res tiles (because I've seen the traffic of the Multi-Res) and I'm also considering adding a really light mobile version where the maximum tile size is 400, so like a 1600x800 panorama. All assets in the Images folder are also resized. Happily, P2VR will treat a 2000x1000 image the same as a 200x100 image and just load and display it with no other changes needed. Looks almost the same on even a 6.5" mobile screen.

Tony's tutorial here is very instructive on where you can tidy things up. Every little helps.

https://tonyredhead.com/pano2vr

Making sure that everything loads well on an old 3G device is a good goal. Now I might be wrong but based on your comments, I suspect that changes to your server would result in improvements many times greater than the changes you are making. Verify that you have compression enable and caching set up properly on your server. Also, make sure that you have the pagespeed mod enabled and configured properly.

Removing PNG and SVG from the JS is not a one size fits all solution, nor does it necessarily improve performance. Encoding the SVG does increase the file size slightly and does take a little bit extra CPU time to decode. On the flip size downloading the SVG file requires another HTTP connection. For small, simple images (2-3kb) it is generally better to inline it. For a page where the HTTP connection limit is reached and progress is blocked due to the limit, anything you can do to reduce the number of connections is a benefit. For poor connections, this can be magnified. Each HTTP connection may have to reconnect multiple times, each with an additional latency lag. Latency times for good 3G run around 120ms, poor 3G can be significantly more. The extra decoding time for a phone from 2012 with android 4.2 is around 100ms. Cut those times in half for newer phones.

Now, the "trimming the tree" does reduce the size of the skin.js file. The example he used reduced a 130kb skin into a 68kb skin plus 3 2kb svg downloads. A total of 73kb to download (56% of original) and 4 http connections. But did he improve speed? On a poor 3G connection (~100kb/sec, 120ms latency) That 130kb skin would take 1.3 sec + 120ms latency = 1.42 seconds. The 73kb + 3 2kb connection would take 0.73 seconds plus and an additional 0.48 second total latency time or 1.21 seconds. A total difference of 0.21 seconds.

Now my skin.js file is a huge 606kb, it has a lot of bells and whistles. Assuming I could get the same percentage, I could spend a few hours and reduce my skin.js to ~340kb plus 12 2kb svg files. A total of 364kb.
However, because of my server setup, the skin.js is only 81kb with the svg inline. Combining the two would result in a skin.js of 44kb plus 12 - 1kb svg files, 56kb total using 13 http connections. A saving of 25kb while tying up an additional 12 connections. 25kb across a poor 3G connection takes about 0.04 seconds.

Reducing image size should help significantly at the cost of lower image quality. However, on smaller devices, the reduction may not be significant, unless you try to zoom in. Again, proper server configuration will help significantly. The pagespeed mod adjusts the images server to better match the device. It will also serve WebP formats to a browser that supports it. So not only do you end up with a faster site, but also better quality images.

Look into the compression and the pagespeed mod, you may find out that you really don't need those lite versions.

[Branigan]

Look into the compression and the pagespeed mod, you may find out that you really don't need those lite versions.

All good points, I'm sure; but the Lite versions load noticeably faster both locally and via my server, and less RAM used is always a good thing, as I was previously having black screen crashes and dumps completely out of the browser on an old Android tablet before, which I no longer get. As there was apparently no setting to "not crap out and die" I'd missed; I had a fiddle with everything.

Extra Http calls tying up other resources? No idea if I've swapped one problem for another, but currently I've solved (most of) my issues. The rest are just bugs. I also have compression set quite high to just above the point where I can see the difference, so tiles are very small, sizewise. I also go in and hand recompress any that try to fight back, such as trees with lots of leaves, or grass/gravel, especially on the nadir. Previews are heavily blurred and compressed to near nothing. Not that they get displayed half the time (See above).

As to SVG files: reduce the Inline size from 10000 bytes to 10 bytes and see both PNGs and SVG files generated in the Images folder. Why does it need both? Because it's still interpreting the SVG files and not actually using the PNGs? Or just wasting time and RAM loading both and using... which one?

Was going to report this as a bug, but setting 'Convert SVG to PNG' does just that, so only PNGs are exported and therefore used. They're slightly softer looking to 'real SVGs' , but close enough to not worry about, and I moved on. Too many minor bugs to report all of them when the biggies are still in there.

[Neal]

Look into the compression and the pagespeed mod, you may find out that you really don't need those lite versions.

All good points, I'm sure; but the Lite versions load noticeably faster both locally and via my server, and less RAM used is always a good thing, as I was previously having black screen crashes and dumps completely out of the browser on an old Android tablet before, which I no longer get. As there was apprently no setting to "not crap out and die" I'd missed; I had a fiddle with everything.

Extra Http calls tying up other resources? No idea if I've swaped one problem for another, but currently I've solved (most of) my issues. The rest are just bugs. I also have compression set quite high to just above the point where I can see the difference, so tiles are very small, sizewise. I also go in and hand recompress any that try to fight back, such as trees with lots of leaves, or grass/gravel, especially on the nadir. Previews are heavily blurred and compressed to near nothing. Not that they get displayed half the time (See above).

As to SVG files: reduce the Inline size from 10000 bytes to 10 bytes and see both PNGs and SVG files generated in the Images folder. Why does it need both? Because it's still interpreting the SVG files and not actually using the PNGs? Or just wasting time and RAM loading both and using... which one?

Was going to report this as a bug, but setting 'Convert SVG to PNG' does just that, so only PNGs are exported and therefore used. They're slightly softer looking to 'real SVGs' , but close enough to not worry about, and I moved on. Too many minor bugs to report all of them when the biggies are still in there.

I should have been more specific. The compression and the pagespeed mod are both on your server. They communicate with the browser via headers and do several things, including dramatically improving downloading speed, improving website performance, and reducing RAM requirements. You can determine if a site is using them by looking at the headers for the index.html file.

It's very easy to tell what is being loaded by a webpage. Open up the Devtools, click on the network page and reload the site. It will list all the files used, when they are called, their sizes and much more. Just look down the list for svg files.

I check out my panos on an old Galaxy Tab E and a Samsung S7. They run very well on both of those. If they are using anything much older then those, there are photos of the home.