Why are Cross Dissolve transitions fading to Black? Feature Request.

Q&A about the latest versions
Post Reply
Branigan
Posts: 209
Joined: Tue May 19, 2020 3:43 pm

Sun Oct 18, 2020 5:48 pm

I first had this with the Lite version, and I thought it had just been crippled to differentiate it from the Pro version, but it's also a problem in Pro.

In Lite, each node (actually separate URL) would fade to black, then the hotspots would appear, then bits of the cube would load and break the illusion of 360, then it would finally be complete and you could explore. Depending on platform, sometimes the hotspots would load after everything else, but mostly before. Maybe some HTML or DOM reason?

I had wondered why the cube sides didn't load in the order that would make most sense: i.e the way you were facing, so you didn't have to look at black space for so long, but figured I'd have to upgrade as Lite wasn't the priority and they just loaded in order 0,1,2,3,4,5, even when you were facing 4. Slower the bandwidth, the longer the wait for the 'box' to get fully drawn. The 'Loading' bar just emphasised the problem.

So I upgraded to Pro...
But Pro is just the same, when I had assumed it would be more coordinated when all the code was in a single pano .XML file rather than one for each 'Node' (URL) in Lite. Although I'd tested it locally, I'd never uploaded a mini-tour to my website.

Now it makes more sense why no one really noticed the broken Zoom In transitions pre v6.1.10; you'd never really get to see them anyway if not running locally on your own machine.

This is in Single-Res mode, where there are 390 files and directories in a 26 node tour.

Firstly I removed the loading bar, so there was less distracting the loader and it could get on with loading and I didn't want to be reminded of 'reality', but a simple cross dissolve first halves the resolution of the current image (so you see 'jaggies' appear in it) then it fades to black, then it loads the box in sequential order, so you see it happening, sometimes with a split second of the lower-res tile, but most often the full-res versions only. It semi-fades up from back to 100% while it's loading, but it's still very visible.

It seems to be down to timing of the loaded tiles, and rather than wait for the next image tiles to load before making the transition (and setting the 'Wait for Transitions' flag makes no difference, when that's only connected to Zooms before or after the Cross Dissolve), it displays what it's got when it gets it, whether it looks good or not.

That might work 'better' if it loaded tiles in 'most likely to be seen first' order, but not if just 0-5 order; whichever way you're facing.

This might also explain why Cross Dissolves are fairly random in length (from 1 to 0 seconds) when testing this out locally. They sometimes load too fast to show the Transition and the code just doesn't wait.

Single vs Multi?
I prefer using Single-Res tiles, but thought maybe Multi-Res would be better, as it could load up the smaller versions of the tiles and Cross Dissolve those more quickly, then fade in the Higher-Res versions over them.

Multi-Res produced 10,001 files and folders (quite a jump from 390) and the data size went up from 40.7Mb to 198Mb. It also took a long, long time to ftp to my website.

But, was it better? No. Actually worse. Now it still fades to black, but fades up from it to a low(er)-res version of the tiles, then refreshes them piecemeal with higher-res versions over the next second or two. May be slightly less obvious that it's drawing a box - as slightly faster loading of the low(er) res tiles - but still visible where you are facing 'the wrong way' and the tiles you're looking at are loaded last. Also still does the 'jump to half-res' of the current set of tiles before it does the fade through.

Re-exploring locations works better, as the image data is cached somewhere, so the transitions more often do actually do the cross Dissolve, but that jump to 'half-res' before it does them is quite jarring.

So, Feature request: an option to Load in the next panorama, then always wait to do the Cross Dissolve between the images, as any extra delay on slower connections is only a second or so and I'd rather it was showing the old panorama for a second longer than what it's doing now.

Also, if it's a bug: not to quickly flip the currect location to half-res before the transitions, so the transition looks smoother.

If it's not a bug, why is it doing it? Can that be changed with a setting anywhere?
Neal
Posts: 160
Joined: Thu Dec 12, 2013 11:14 am

Mon Oct 19, 2020 7:19 pm

Transitions under a slow connection do tend to be rough. instead of a cross dissolve, the first pano dissolves to the black background with the second pano appearing after the transition is complete. Increasing the transition time will help mask that. It should be possible to delay the start of the transition until the second pano has loaded, but it is generally considered a poor user experience when you click a button and nothing happens.

I don't know if the script is set up to prioritize the loading of the tiles currently in view or not. I do know that such prioritization comes with a trade-off. The first is that as soon as you start moving around, those other areas come into view as either black areas or low-resolution tiles. Since the purpose of a 360 is to be able to move around, I'm not sure how much is gained by loading the initial view first. The second trade-off is a longer total load time. Instead of grabbing tiles as fast as you can, you calculate which tiles to grab first. Those calculations are quick but do take some amount of time.

The randomness of the tile loading is caused by different file sizes. Smaller files are just loaded faster.

Single vs Multi has nothing to do with loading. It had to do with zooming in and out. The going from low or high resolution is due to the use of progressive jpg files. Low and high resolution is including in the same file. The file format allows the browser to use the low-resolution information while the higher resolution information is still downloading. The transition from low to high is solely dependent on download speed and the processing speed of the device.

FTP connections suck when downloading a large number of small files. It is the nature of FTP. SFTP does better. If you have access to the server-side, you can do a lot better with packaging all the images into a single file that gets unpackaged on the server. But you have to have access to the server directly to do that. You can however manually set the number of resolution levels for the panos, fewer levels mean fewer files.
Branigan
Posts: 209
Joined: Tue May 19, 2020 3:43 pm

Mon Oct 19, 2020 9:30 pm

Neal wrote:
Mon Oct 19, 2020 7:19 pm

Single vs Multi has nothing to do with loading. It had to do with zooming in and out. The going from low or high resolution is due to the use of progressive jpg files. Low and high resolution is including in the same file. The file format allows the browser to use the low-resolution information while the higher resolution information is still downloading. The transition from low to high is solely dependent on download speed and the processing speed of the device.
Single Vs Multi does make a difference. You can test by overwriting the larger size tiles with a completely different pano. It loads in the panorama up to 4 times in increasingly higher resolution. It's also chopped up in 'interesting' ways, so it populates in a piecemeal way. Little by little the res gets higher. Very obvious when running the demo, as the 'PanoVr Demo' text (or whatever it was) drawn on everything would skip about and get overwritten several times, but you'd never actually end up with any of it joining up, even though the highest level tiles all should have come from the same pano image.

You can change the 'Level Tile size' from Auto to Manual, which I thought was only to do with the number of different resolutions you can set: phone, , tablet, desktop etc. in settings, but apparently not? Or it is, but not how I understood it. Docs are non-existent. I was trying to get it to automatically load lower resolutions tiles only for mobile, but it still seems to load in the higher ones afterwards as well? Although maybe it skips a few? Change to Manual and put your own tile values in and breaks like an own-brand cheese straw. Gets hopelessly mixed up and loads tiles in semi-random order and wrong positions, so the ground is part of the wall and parts of the sky repeat on the floor.

Even left on Auto it seems to attempt some kind of 'just in time' for viewing direction when you rotate quickly, you see a flicker of black, then little low-res amd higher-res tile sections being filled in on the leading edge. Always a little too late. Especially bad on slower hardware. So, it could do the sorting order for Single Res. It would be cheap as anything. It's literally only 6 files per panorama. But I stick with Single Res, do my own test for platform and go to a different URL with the mobile sized tiles in it exclusively. Also means I can tweak the skin and have it use smaller resources for buttons etc. Max 600x600 tiles with 150x150 previews seems to be the sweet spot for smaller screens.

Martin says the code is such that no chance the FoV bugs will be fixed before V7. Rolled back to 6.1.9 to get half a working Transition as 6.1.10 completely FUBAR'd them. Hard coding a default FoV of 70 in there as target or destination, when it's wrong for 90% of 16:9 panoramas? Doh! but as 6.1.9 couldn't even manage the originals: back to Cross Dissolve. :(
Neal
Posts: 160
Joined: Thu Dec 12, 2013 11:14 am

Mon Oct 19, 2020 10:58 pm

The tiles are not being used in the manner you think. Those tiles are being loaded into the background for use during zooming, not to overwrite what is on the screen. What you are describing is how a progressive jpg acts, starting at a lower resolution and adding in details.

The documentation you are looking for is here: https://ggnome.com/doc/output-html5/#html

The levels manual set the width of the tiles. I created a pano using some random number and didn't see what you described.

The loading images slower than you can scroll is typical for slow connections on slow hardware.
Branigan
Posts: 209
Joined: Tue May 19, 2020 3:43 pm

Tue Oct 20, 2020 1:18 pm

Neal wrote:
Mon Oct 19, 2020 10:58 pm
The tiles are not being used in the manner you think. Those tiles are being loaded into the background for use during zooming, not to overwrite what is on the screen. What you are describing is how a progressive jpg acts, starting at a lower resolution and adding in details.

The documentation you are looking for is here: https://ggnome.com/doc/output-html5/#html

The levels manual set the width of the tiles. I created a pano using some random number and didn't see what you described.

The loading images slower than you can scroll is typical for slow connections on slow hardware.
Hmmm...I can't go back and check now I've registered, but I'll concede it's possible that it was only the Preview images with 'Pano2Vr Demo' text in one place overwitten by the High-Res with it in another. Still always didn't quite link up correctly though, even when complete. Maybe it was just a few very slow High-res tiles leaving their Previews visible for a long time before I moved on to the next view. File that under 'false memory' syndrome. ;)

They're also chopped up into such small pieces (by default) that it was very visible as the overlapping 'PanoVR Demo' text showed where the tiles were being overwritten and there could be 10 or more smaller tiles, rather than the left/right/top/bottom of Single Res. Maybe that 'overwritten text' just emphasised the mechanism, but: basically Multi-Res was underwhelming in every way, so I moved to Single-Res.

Setting Single-Res tile sizes to 1400, 1300 and 1200 (rather than 1520) to reduce data (before finding that fine tuning the quality gave better results; 78 seems to be the size/visible artifacts sweet spot) often had it chop them up wrong so they didn't line up correctly. This was frustratingly random and deleting the tiles and trying again would usually fix it on a second attempt.

Thanks for the docs link, but not intending to use Multi-Res anyway because it just takes more time on all tests I've tried to get to the final result - even locally. All those requests for lots of smaller tiles might be more efficient at one level (data requests through multiple links?), but the actual drawing of them still takes a finite amount of CPU/GPU, and 10x smaller tiles takes longer to draw and probably can't be compressed as well for the same quality and is therefore (slightly?) more data to manage.

Set it to Multi-Res , Manual: 2000. That should force the tiles to be pretty large rather than the 510 I get as the default (for the size of my pano) and it see what it does. :)

The flickering images loading slower on rotation is on my main PC locally. It's not that slow (had been playing with tile sizes though at the time). On a rickety old iPad I test things on: nope^2. :shock: Does show it can - and does - check direction you're facing, which it could do for Single Res, but was perhaps not considered as '"it's only 6 tiles"? Well, ideally it would just not show anything until it's all loaded and it can make up a full cube with any combination of tiles..

Doesn't have to be all Full-Res tiles before it moves on. It might be that due to how the data arrives, it could get Preview and Full tiles in random orders, with some Full arriving before their Preview versions. ( Can you abort a request of a Preview tile if you no longer need it? ) If it could make up the whole cube (or the direction you are facing) with any tiles it could do the transitions with no Blackness. Fading in any latecoming High-Res tiles as they arrive, as it does with no transitions.

As it is: for the 4 of 6 (Single-Res) tiles you might see (looking into a corner on arrival, so: left, right, floor and ceiling - you'll get maybe 50% black, a (early loading) High Res and a Low-Res, which are then all replaced by the High Res tiles. If it even waited for half a second and used only the Low-Res to all load before showing anything it would be a massive improvement. If some High-Res arrived before their Preview versions, use them, discard the Previews and go with a mixture. Any combination of random tile qualities is better than fading to Black.

It might be doing part of this, as you do see some High-Res tiles before the Low Res arrive, but it's still showing the Blackness then overlaying it with anything it has to hand, which is the biggest problem.

Also, found that on that iPad my 'Cross Dissolves' don't fade to black first, they fade to 90% white - like a nuclear whiteout - with traces of the original image. Evidently browser specific (very old Safari), so being able to at least be consistently awful and only black would be a better option.

You know Javascript. :D Anywhere that we can manually nail in a "Set background to BLACK!" rather than 'Random(?)' when the screen buffer is cleared? :wink:
Post Reply