Garden Gnome Software

I just released the (from some people here long awaited) Pano2VR 2.2 beta.
New features are:

• Flash 10 export; Flash 9 panoramas are using the new Flash 10 rendering
• Inline Hotspots; the next panorama is loaded inside the current Flash player
• Point Hotspots; you can add point hotspots and QuickTime style area hotspots
• Extended Skins. New properties like angle and several new actions
• Designer point hotspots in the Skin editor
• Hotspot Proxies; trigger events from hotspots in the skin

Some features didn't made it in the first beta because lack of time and some guys here put so much pressure so I decided to make this early release.
Features like domain lock, expire time, mouse wheel lock,.... will follow in one of the next 2.2 betas.

To see and download a demo you can go to the Pano2VR Flash tour example.

You can download the new beta version as always from the Pano2VR download page.

Ahhh! Great! From one pano to the next withour leaving the fullscreen!

Some questions:
- how proxies are used?
- how does the pano-to-pano-while-in-fullscreen-feature does work?
- how do i create point hotspots? (i tried to understand the example, but i didnt...)
- maybe a bug: when i try to edit an older project with a big 16bit tif as source image, the editing of the existing hotspot gives me an out of memory error, resulting in a crash of pano2vr

maybe not a complete tutorial, but some words on how to use the new features would be great!

Hi Thomas!!

Great work my friend!!!!, the hotspots I have added, now work in the Flash player alone!! Perfect, thank you so much. I still want to know why Firefox, Chrome, and most other browsers EXCEPT Internet Explorer, allow for the quicktime-style hotspots to work online with flash output, but your new version is just the breath of air to save my huge project.

thanks ever so much for your efforts, Glenn

Jan_T wrote: Some questions:
- how proxies are used?
- how does the pano-to-pano-while-in-fullscreen-feature does work?
- how do i create point hotspots? (i tried to understand the example, but i didnt...)

The example I posted is maybe a bit too complicated to understand without explanations. A tutorial for it is on its way. In the meantime I will try to explain it with just words.
If you open the hotspot editor you now have a "point hotspot" tab. With a double click you can add point hotspots to the panorama. On top of the screen you can add the parameters like the ID (only useful if you use proxies), skin id (to have more then one hotspot symbol), title, url and target. The later 3 are the same as for area hotspots so if you want to create a simple tour just add the name of the next panorama into the field. If the file name ends with ".swf" Pano2VR assumes it is another panorama (works also for area hotspots!).
In the case of a new panorama this new pano is loaded internally and the images and parameters like hotspots are taken out and loaded into the original player. The skin of the new panorama will be ignored! If you are generating a tour only the first panorama needs a skin! The result is that for the browser sees still the same swf file and nothing has changed. Also a nice consequence is that this method avoids the problems discussed some time ago.
You can also design your own point hotspots within the skin editor. To do that you just need to add a "hotspot template" as parent and everything below that object in the tree is ignored in the normal skin but instead used as the point hotspot display object. You can use the hotpots title information with $hs, the url with $hu and the target with $ht in text fields and gotoURLs. You can address different templates with "ID" in the Skin and the "Skin ID" field in the point hotspot.
The proxy property brings back the hotspot events into the skin. Just use the hotspot ID (which is just the number for area hotspots). This avoids the need to generate a separate hotspot template for each hotspot to do trigger different skin based actions. The proxy receives the same events (currently only click, mouse enter and mouse leave) as the hotspot in the panorama so in the example a click on the point hotspot triggers the same event as a click on the dot within the map because the dot is a proxy for the point hotspots. For that reason there are no urls attached in the point hotspots and everything is manged in that point object. The result is that the "code" for moving the radar, url of the next pano, correcting north,... is only in the dot and not in each point hotspot.
I hope this long explanation makes at least a little sense to you. As said, tutorials will follow soon.

Verrrry nice, I'll dive into the new features soon!

Thanks again Thomas!

What exactly is a point hotspot? Is it based on an external bitmap which defines each spot? If so, can it be toggled on and off?

Pat L

makiedog wrote:What exactly is a point hotspot? Is it based on an external bitmap which defines each spot?

Point hotspots are defined by a pan and tilt angle within a panorama. This information is stored in XML.

If so, can it be toggled on and off?

Not at the moment.

very nice, the "creature" grows! for me these features are perfect. software good, I am content of to have bought.

Too bad Flash10 cilindricals didn't make it in this beta yet.
Even so it looks like some cilindrical-related things in Pano2VR did change, but apparently not all for the better.
A cilindrical I made in december 2007 with beta3 in Flash9 was 3,224 kB in size; with exactly the same settings in 2.2 beta1 (also Flash9) it now becomes only 1,642 kB, quite a difference indeed! Sadly rendering quality (in Stand Alone Player 10) has been reduced by about the same amount as well. Something to be aware of I think.

Cheers!

Erik Leeman

ps I forgot to mention that the new one also loads a LOT faster than the old one!

erik leeman wrote:Too bad Flash10 cilindricals didn't make it in this beta yet.

Yes they did, but unfortunately a cylinder is a curved surface and Flash 10 (and all 3D graphics cards) provided only distortion free rendering for flat textures so this is a fundamental problem that can not be solved this way. I may investigate in an alternative rendering method for cylinders to make them also completely wavy free.

Even so it looks like some cilindrical-related things in Pano2VR did change, but apparently not all for the better.
A cilindrical I made in december 2007 with beta3 in Flash9 was 3,224 kB in size; with exactly the same settings in 2.2 beta1 (also Flash9) it now becomes only 1,642 kB, quite a difference indeed!

I guess this is the effect of the bitmap limit Flash 9 introduced at some point. A bitmap can not be larger then 2880 in one dimension so I need to reduce the size to be on the safe side. This limiting is implement in Pano2VR for some time now so this has nothing to do with Flash 10.

Direction true...

thnx

I guess this is the effect of the bitmap limit Flash 9 introduced at some point. A bitmap can not be larger then 2880 in one dimension so I need to reduce the size to be on the safe side. This limiting is implement in Pano2VR for some time now so this has nothing to do with Flash 10.

Hmmm, if that is so, and I have no reason to doubt you, then why is it still possible to open those BIG old Flash9 panos with the newest plugins and standalone players?

My own, rather crude workaround for smaller cilindricals was/is to simply enlarge the canvas to 2:1 and then treat them as equirectangulars in Pano2(QT)VR, limiting the vertical view to suit the panorama. I'll see what happens if I try this with those very large ones.

Erik Leeman

Hi Thomas

Quick question, is it possible to change the font for the hotspots ALT text?

I cant see it in Pano2VR, is there a Flashvar?

Thanks, Glenn

this aging disease... if "Scaling: none" ...this stays up?

I do not [generally] take ground / ceiling shots, thus I rely on the ability to set the view area limits.

When using the ability to load panoramas directly, the entire sphere is available, meaning that a large white area displays at the top and bottom.

Are the view area limits not being taken into consideration? I would have assumed that at the very least, the view area limits of the first panorama would be preserved.