On Sun, 2010-03-21 at 22:44 +0100, Darko Makreshanski wrote:
> The 3D panosphere mode would have very little in common with the current 
> projection mode. So it will not use the current projection techniques to 
> display the result (rectilinear for inside and orthographic for outside 
> look) but rather create a 3D sphere in OpenGL, and then texturized 3D 
> meshes for each image which would lie on the panosphere. So it will not 
> use the 2D "GL_PROJECTION" mode, but the 3D "GL_MODELVIEW".

GL_PROJECTION and GL_MODELVIEW are enumerations used for glMatrixMode,
which sets the matrix the other matrix manipulation functions use.

The projection matrix and the model-view matrix are used simultaneously
to draw anything, 2D or 3D.

> This means 
> that the remappers would need to be refactored or reimplemented to 
> return a 3D texturized mesh.

You should set up an equirectangular projection that is 360 degrees by
180 degrees, then either:
      * Make a variation of MeshManager::MeshInfo::CompileList() [1]
        that uses the 2D coordinates as angles in spherical coordinates,
        then converts it the spherical coordinates to 3D Cartesian ones,
        or
      * Make something remapper-like that produces the 3D mesh directly.
        Since spherical coordinates from an equirectangular projection
        do not exhibit weird behaviour at poles or seams, this should
        work without duplicating too much effort. It could be more
        efficient than going several layers of the fast preview. This
        would also mean you have more control of the layout mode.

> You are right about the linear panoramas.
> But I believe the linear panoramas are a totally different type of 
> panorama, and they are represented by a plane.
> In that case, as some changes are required for processing, this would be 
> a totally different mode of creating panoramas (I believe this was Dev 
> Ghosh's GSOC project last year, but I don't know in which state it is now)

It has been merged into Panotools trunk. It provides the X, Y, and Z
variables in Hugin trunk. All variables are used together so we can get
lens correction and perspective correction in linear panoramas for free.
The only difference in processing linear panoramas and spherical ones is
which variables you optimize (X, Y, Z instead of yaw, pitch, roll).

> > I think the best way to understand most projections is with a good
> > diagram. The panosphere view could include some of the properties of the
> > projection in a diagram. For example, something like [1] could be used
> > for cylindrical projections. For diagrams to make sense, the view must
> > be from outside the panosphere; and it must be at an angle to the centre
> > of the projection used, since the shapes will not be seen head on.
> >   
> Yes, this was basically the idea with the corresponding grids on the 
> projection and the sphere
> > Unfortunately this could be a lot of work, as each projection would
> > require its own diagram drawing code (and some projections would still
> > look weird). I think just covering rectilinear, equiangular, and
> > cylindrical projections would be enough to cover the main use cases
> > though.
> >   
> Why is this so? I was just thinking of projecting the grid of the sphere 
> the same way all the other projections are generated.

I was thinking about visualising the mathematics of the projection:
      * Rectilinear projects the sphere onto a plane, so it would be
        nice if I could see a plane for the panorama's field of view on
        the diagram. The way the plane changes size when adjusting the
        field of view would make it clear that a field of view of 180
        degrees or more is impossible.
      * Cylindrical projection projects the sphere onto a cylinder which
        is then unrolled, so I would like to see the part of cylinder
        used for the panorama's field of view drawn around it. Similarly
        to the rectilinear projection, I would see that the vertical
        field of view cannot be near 180 degrees because the cylinder
        would get too tall; but I can wrap around the whole sphere
        horizontally.
      * Equirectangular projection could just shade the field of view on
        the sphere directly. The curved top will help identify where the
        distortions come from, and it would be obvious I can get the
        whole sphere by increasing the field of view in both directions.
      * Biplane works like a rectilinear projection, but should show two
        planes instead of one.
      * Triplane is similar, but with three planes.
I don't know a good way of representing every projection. I think
several would end up with a generic cylinder diagram or nothing special
at all.

> > An extension (maybe a bit much for your summer of code project) would be
> > to use the XYZ properties in 3D space instead of just the spherical
> > projection. To visualize this well you would need to be able to move the
> > camera around as well as rotate it.
> >   
> Yes, I didn't take into consideration that hugin can also estimate 
> translation.
> 
> All I can think of are two models. That is the sphere and plane model.
> A generalized model which would show irregular cloud-shaped model of the 
> panorama is currently a science-fiction for me :)

I think restricting to sphere or plane models is enough. Technically
panoramas could work in a mixture of the two models, but picking one or
the other should be good enough for display purposes.

> The closest thing I can think of is just a layout mode in which images 
> wouldn't originate from the same point as in the panosphere and, the 
> origins of each image (the apparent camera position) would be rendered 
> as well, e.g. in a form of a camera :)

I think it is possible to draw the images in one sphere, but mark an
image's camera position in the Outside Panosphere View's identify mode.
Drawing all the cameras at once will be confusing since the images
should overlap lots.

> About the translation, I actually have no idea how it currently affects 
> the projections. I will need to look more into the code, since I 
> couldn't understand the effects of it on the preview.

I don't really understand what it does either!

-James

[1]
http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/src/hugin1/hugin/MeshManager.cpp?revision=5076&view=markup#l_176


-- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

To unsubscribe from this group, send email to 
hugin-ptx+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Reply via email to