Hi Timmy,
Firstly apologies for the late reply, other Gnome duties have taken priority over the last few days, testing new betas as well as starting to gear up for September as its going to be a busy month for us. I will be at the Pano Tools meeting in the Hague from the 10th until the 12th and then both Thomas and I will be at Photokina in Cologne from the 18th to the 23rd. Thomas will also be giving a Talk on the 17th at the IVRPA conference a day before Photokina. So if you or anyone else is going to be around at any of those dates please pop over and gives us a look, got sone new things on the go with Object2VR at Photokina.
Ok, back to business, and lets see if I can better answer your questions.
The load bar is used when downloading the SWF, so the larger the SWF the longer the viewer has to wait to see anything.
Think of a circle which you are standing in the middle of. While looking in a given direction and zoom level you can see about 20% at any one time.
Ok, now think of your Panorama and the same rules apply.
The next statement is an overview of what goes on.
For small files it is better to have them embedded as the latency between computer and server will play a big part in the speed of the player asking for tiles and them actuary getting served up and displayed on your screen.
However web browsers are geared up for parallel downloads, so for the higher resolution tiles it is better to have them fetched from the server as the latency plays a less part when asking for larger files sizes.
You download a full 360 x 180 low resolution image, may be Embedded or set to Decode and Load at start up but in either case it will display very quickly.
Then in your field of view the tiles change for the correct resolution for your screen/field of view. This means you are only downloading the 20% you can actually see so not having to download the full 360 x 180 at that resolution.
Then as you zoom in you are seeing less of the panorama, say only 5% so you will download higher resolution tiles but only for your field of view, maybe now only 5% of the complete panorama.
This means you only need to download a low resolution image to start with then the tiles for what you actually see and at what zoom level/Field of View you use.
This will probably still be only a small percentage of all the tiles at all the levels available to the viewer.
The settings in the advanced section can be changed to taller the performance of the download from a given server, as already said latency, connection speed and so on. In practice you would only want to change these if 1, you know exactly what you are doing and 2, you know the performance of your server, the performance of your viewers internet connection and speed of their graphics card.
One more thing which I have not yet mentioned but should now be clear why, is the thing about trying to keep the tile size equally divisible in to all the cube face sizes.
If you have small odd sized tiles then the latency will be an issue and slow down the downloading.
So with that all said, and IMO it is better to have your tiles divisible in all your cube faces, set the lower resolution level as embedded and don't mess the any other settings unless your host server is from the dark ages.
From my Canon 60D Sigma 8mm fisheye and using PTGui I can produce 10,752 x 5376, equirec.
I set the size to 10,400 x 5,200 so my levels are easy to work with, Example:
Cube face size for each level.
2,600
1,300
650
325 Embed this level and make it your level tile size.
Regards,
Hopki