James Legg wrote:
On Sun, 2010-03-21 at 22:44 +0100, Darko Makreshanski wrote:
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.
Yes, the equirectangular would be most suitable to convert to a 3D mesh.
Basically I was thinking of projecting all of the images separately,
each with its center as the center of projection. Then to convert each
projection into a 3D mesh, and finally join the meshes based on the yaw,
pitch, roll parameters. This would be to avoid any problems with the
poles, however I am not sure if it would be necessary.
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.
The approach you describe is similar to what I had in mind for the
animation part of describing the projections.
This approach would require rendering the projection and panosphere in
the same opengl scene (canvas).
What I was thinking of, apart from this, is also to provide a connection
between the overview and the projection while they are in separate
canvases. The alignment of the canvases would be adjustable in the sense
that the user can choose to see either one at a time or both aligned
either vertically or horizontally. This I believe should be the default
mode of preview of the panorama.
I mentioned the grid as the solution to this connection. The grid would
be perfect because it will clearly show the distortions on the
projection, and with the interleaving colors it will also provide
uniqueness to every part on the grid.
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.
Yes, just the problem remains of how to represent yaw and pitch in a
planar model, and x,y,z translation in the sphere model. About the
sphere model I proposed something below.
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!
The only logical explanation I could think of, which is consistent with
the result in the preview, is that the images with non zero x,y,z
parameters are represented on a sphere with a shifted center, however
the projection is still done from the original center.
This actually could also be represented in the overview, in which case
the overview would no longer be a sphere but rather images projected on
spheres with different centers.
The grid that I was talking about would also be suitable to explain the
effects of the x,y,z parameters as well.
This might be tricky to explain, but I'll try:
A grid 'B' is a grid that needs to be displayed on an image with some
x,y,z parameters that is projected on a sphere 'B' with a shifted center
of x,y,z.
This grid 'B' would actually be a mapping of another grid 'A'. The grid
'A' is a grid which lies on the sphere 'A' with its center at zero x,y,z.
The grid 'A' would actually represent the portion of the sphere 'A' that
covers the image as it is seen from zero x,y,z (center of sphere 'A')
If my model for what happens with the x,y,z parameters is right, then
this proposed solution I think would be perfect to visualize an overview
which would explain the effects of x,y,z as well.
-James
[1]
http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/src/hugin1/hugin/MeshManager.cpp?revision=5076&view=markup#l_176
Cheers,
Darko
--
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.
