Forum Moderators: not2easy
>bandwith
Hm, depends ... You can compress panoramas so they don't use more bandwith than a simple jpg file. And using QTVR (Quicktime), you can build multi data rate panoramas to deliver panos appropriate to the visitor's connection speed:
- You'll have a flat preview file which is 2k
- Then you can include as many different versions (sizes/resolutions) of each pano as you like. Depending on the bandwith settings in the quicktime control panel on the client (browser, visitor) machines, a different version gets loaded.
ie, you can have three versions:
- 1 small version for slow modem users = file size <100 k
- 1 medium version for single isdn = file size <300k
- 1 fat version for t1 = file size ~1mb
Depending on the original quality of the panorama photos, you *can* compress a qtvr movie down to below 40k and still have a reasonable quality. However, this depends on some more factors like: how many details are in the pano, what is the playback size / dimensions of the pano etc.
Is bandwidth not an issue for applet driven VR Tours?
Wow, 1,000 people sounds pretty oversized. However, you'll need a fast (standard) web server. If you have a web server that can handle 1,000 sim connections without going down, you won't have a problem with serving vr either. I have no numbers at hand but one qtvr site i did a few years ago had a press event and a simultanous tv news on the biggest german tv station. I never heard of nor noticed any server load issues ...
>Is bandwidth not an issue for applet driven VR Tours?
I don't think there's any bandwidth difference between qtvr and applet driven tours. Both are loaded to the client machine. So the procedure and server load should be the same.
What are the underlying bandwidth costs involved for hosting a VR tour?
Are you suggesting this or are they asking for it? I have yet to see a virtual tour that was worth the time, expense, and end-user trouble compared to still images.
