Abstract

Freepv is a part of the PanoTools Software Universe and it is an effort to make a universal viewer for the different VR file formats. Thus this project intends to add new features like basic support to some files and enhance the user interactive experience. Since Freepv is at an early stage of development other objectives are to get a stable OpenGL renderer and restructure some components to have a more intuitive extendible architecture.

Description

Freepv is intended to be a cross platform stand alone and plug in panorama viewer and to be able to support different type of files, freepv specially tries to fill some gaps for Linux and Unix user, where there are few support to QTVR, SPi-V and other panorama file formats. Thus this project intend to add new features like basic support to SPi-V file format and a better one for QTVR files.

Freepv is at an early stage of development. Thus there are a lot of improvements to do, like restructuring and cleaning up the code, adding comments and of course optimizing parts like the OpenGL renderer, I will help with this issues making a more stable renderer to work with.

Then I will have to extend or restructure the Scene and Camera class, which act like an interface between the QTVRdecoder and the renderer; these classes should be more flexible to handle different panoramic formats. With these enhanced class or classes, you will need just to implement the file decoder module, which you desire. These modules should fill these classes’ internal data structure and the renderer would work with the file data through these class or classes.

The next part of the project will consist in adding a basic SPi-V XML file format support, this will consist in adding an XML parser and implementing the SPIVdecoder, for this purpose I will need to read in detail the SPi-V XML file format specification. To the end of this part, the viewer should be able to display basic SPi-V panoramas; basically it will handle data from the meta node.

Other thing is to create a very basic freepv XML format, this as an alternative to read the different cubic faces JPEG images from the program argument list, it would be easier to specify just an XML file, that could be a Freepv file or a SPi-V file.

The last part of the project will consist in enhance the user interactive experience adding the support to hotspots; this will enable the user to make a virtual tour, switching from one scenes to another by just clicking over the hotspots. This last feature should be supported for both QTVR and SPi-V file formats, in order to this I will have to plan and design a component to handle the different scenes of a tour. Furthermore most of the hotspots in SPi-V are made with images that not necessarily are JPEG, so it will be needed to add support to files like PNG and GIF.

The hotspots could be points, squares or polygons, for the design of the hotspot interface, I should contemplate these three possible configurations. I’ll need to check the EventListener class and to implement a basic collision detection algorithm. The hotspots will support basic events, like roll over and click. Taking advantage of the new image readers formats and the SPi-V file format, it would be nice to be able to display flat images with the panoramic views, this images then could behave as buttons or external links to WebPages.

Planification

This planification is an estimation of the amount of time needed by each task:

OpenGL Renderer

Planification/Research: 1 week.

Design/Implementation: 2 weeks.

Testing period: 1 week.

SPi-V / Scene&Camera classes

Planification/Research: 1 week.

Design/Implementation: 2 weeks.

Testing period: 1 week.

Image loader

Planification/Research: 1 week.

Design/Implementation: 1 week.

Hotspots

Planification/Research: 1-2 weeks.

Design/Implementation: 2 weeks.

Testing period: 1 week.

Final Note

Some task could be overlapped, for example I could being coding and at the same time I would begin the planification of another task. This intend to make the process of developing faster and natural.

The approach of the project would be from bottom to the top, since the OpenGL need to be more stable to work with, then this should make easier other task like the implementation of Hotspots or the SPi-V decoder.

Every Friday a Report will be written to the mentors; it’ll have all the achieved sub-task, that were made in the week, the next task to be made in the following week and problems that I could be having.