Improving documentation and technique more correct to reference images in doc
This commit is contained in:
parent
9658740974
commit
c43920bb2e
|
|
@ -17,7 +17,7 @@ vcg::face::FFAdj stores, for each edge e of the face f:
|
|||
FFp(e): a pointer to a face f' sharing e. If e is a border than points to the face f itself
|
||||
FFi(e):the index of e in the pointed face
|
||||
|
||||
\image html "../img/FF_Adj.png" "Indexing of vertexes and edges"
|
||||
\image html "FF_Adj.png" "Indexing of vertexes and edges"
|
||||
|
||||
f1->FFp(1) == f0
|
||||
f1->FFi(1) == 0
|
||||
|
|
@ -28,7 +28,7 @@ FFi(e):the index of e in the pointed face
|
|||
Note that we specified that FFp(e) point to a adjacent face, not to the adjacent face. The reason is that there could be more than two faces on the same edge, and this is seamlessly supported by VCG Lib. In the picture below is shown an example with 4 faces incident to the same edge
|
||||
|
||||
|
||||
\image html "../img/FF_nonmanifold.png" "Non manifold edge"
|
||||
\image html "FF_nonmanifold.png" "Non manifold edge"
|
||||
|
||||
In this case the adjacencies are set to form a circular list (not necessarily sorted with the angle around the edge). This is done by the VCG Lib function that update these values (UpdateTopology<MeshType>::FFTopology(MeshType & m)).
|
||||
In this way VCG Lib provides a way to check if a mesh is manifold on a specific edge because the FF adjacency relation is mutual, i.e. the face f0 points to the face f1 which points to the face f0, if and only if the mesh is manifold over the corresponding edge.
|
||||
|
|
@ -56,7 +56,7 @@ For example consider c1: there is only another pos which is the same as c0 excep
|
|||
|
||||
In the left of the table some other examples are shown just to make this point clear.
|
||||
|
||||
\image html "../img/pos_example.png" "Pos Example"
|
||||
\image html "pos_example.png" "Pos Example"
|
||||
|
||||
c2 = FlipV(c1)
|
||||
c0 = FlipE(c1)
|
||||
|
|
@ -136,7 +136,7 @@ vcg::vertex::VFAdj which is a vertex attribute containing a pointer to f0
|
|||
vcg::face::VFAdj which is a face attribute containing a pointer to the next face in the list v_star for each of its 3 vertices (4 in the case of tetrahedra)
|
||||
These two attributes are not only a pointers, they also contain an index referring the index of the vertex in the pointed face in the same style as the vcg::face::FFAdj does. The picture below shows a complete example:
|
||||
|
||||
\image html "../img/VertexStar.png" "Example of vertex-face adjacency"
|
||||
\image html "VertexStar.png" "Example of vertex-face adjacency"
|
||||
|
||||
v.VFp() == f2
|
||||
v.VFi() == 0
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ OUTPUT_DIRECTORY = .
|
|||
# source files, where putting all generated files in the same directory would
|
||||
# otherwise cause performance problems for the file system.
|
||||
|
||||
CREATE_SUBDIRS = YES
|
||||
CREATE_SUBDIRS = NO
|
||||
|
||||
# The OUTPUT_LANGUAGE tag is used to specify the language in which all
|
||||
# documentation generated by doxygen is written. Doxygen will use this
|
||||
|
|
@ -175,7 +175,7 @@ MULTILINE_CPP_IS_BRIEF = NO
|
|||
# member inherits the documentation from any documented member that it
|
||||
# re-implements.
|
||||
|
||||
INHERIT_DOCS = YES
|
||||
INHERIT_DOCS = NO
|
||||
|
||||
# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce
|
||||
# a new page for each member. If set to NO, the documentation of a member will
|
||||
|
|
@ -612,7 +612,7 @@ CITE_BIB_FILES =
|
|||
# The QUIET tag can be used to turn on/off the messages that are generated
|
||||
# by doxygen. Possible values are YES and NO. If left blank NO is used.
|
||||
|
||||
QUIET = NO
|
||||
QUIET = YES
|
||||
|
||||
# The WARNINGS tag can be used to turn on/off the warning messages that are
|
||||
# generated by doxygen. Possible values are YES and NO. If left blank
|
||||
|
|
@ -665,20 +665,22 @@ WARN_LOGFILE =
|
|||
# directories like "/usr/src/myproject". Separate the files or directories
|
||||
# with spaces.
|
||||
|
||||
INPUT = \
|
||||
../../vcg/complex/allocate.h \
|
||||
../../vcg/complex/algorithms/update \
|
||||
../../vcg/complex/algorithms/inertia.h \
|
||||
../../vcg/complex/algorithms/point_sampling.h \
|
||||
../../vcg/complex/algorithms/clean.h \
|
||||
../../vcg/complex/algorithms/refine.h \
|
||||
../../apps/sample/trimesh_base \
|
||||
../../apps/sample/trimesh_attribute \
|
||||
../../apps/sample/trimesh_smooth \
|
||||
../../apps/sample/trimesh_refine \
|
||||
../../apps/sample/trimesh_inertia \
|
||||
../../apps/sample/point_sampling \
|
||||
.
|
||||
INPUT = ../../vcg/complex/allocate.h \
|
||||
../../vcg/complex/algorithms/update \
|
||||
../../vcg/complex/algorithms/inertia.h \
|
||||
../../vcg/complex/algorithms/point_sampling.h \
|
||||
../../vcg/complex/algorithms/clean.h \
|
||||
../../vcg/complex/algorithms/refine.h \
|
||||
../../apps/sample/trimesh_base \
|
||||
../../apps/sample/trimesh_attribute \
|
||||
../../apps/sample/trimesh_smooth \
|
||||
../../apps/sample/trimesh_refine \
|
||||
../../apps/sample/trimesh_inertia \
|
||||
../../apps/sample/trimesh_sampling \
|
||||
. \
|
||||
../../vcg/complex/complex.h \
|
||||
../../vcg/simplex/vertex/component.h \
|
||||
../../vcg/simplex/face/component.h
|
||||
|
||||
# This tag can be used to specify the character encoding of the source files
|
||||
# that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is
|
||||
|
|
@ -763,7 +765,10 @@ EXAMPLE_RECURSIVE = YES
|
|||
# directories that contain image that are included in the documentation (see
|
||||
# the \image command).
|
||||
|
||||
IMAGE_PATH = ./
|
||||
IMAGE_PATH = ./ \
|
||||
../ \
|
||||
./html \
|
||||
./img
|
||||
|
||||
# The INPUT_FILTER tag can be used to specify a program that doxygen should
|
||||
# invoke to filter for each input file. Doxygen will invoke the filter program
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ It can be annoying when you see it but it is useful that every entity involved k
|
|||
- MyVertex1 also store a color value specified as 4 bytes
|
||||
- MyVertex2 store a long list of different components.
|
||||
|
||||
Many other compenents are implemented in VCG, their complete list can be found *here*. You can place any combination of them as a template parameters of your vertex (your entity) type (order is unimportant). Now we have all it takes for a working definition of MyMesh type:
|
||||
Many other compenents are implemented in VCG, their complete list can be found in the vcg::vertex and vcg::face page. You can place any combination of them as a template parameters of your vertex (your entity) type (order is unimportant). Now we have all it takes for a working definition of MyMesh type:
|
||||
|
||||
\dontinclude trimesh_base.cpp
|
||||
\skip complex.h
|
||||
|
|
|
|||
|
|
@ -20,21 +20,21 @@ In generale, the camera parameters can be divided in two groups:
|
|||
|
||||
If these group of values are put in a proper camera model, it is possible to transform any point in the space in the corresponding point on the image plane of the camera (and viceversa).
|
||||
|
||||
\image html "../img/shot-Camera_model.png" An example scheme of a perspective camera model
|
||||
\image html "shot-Camera_model.png" An example scheme of a perspective camera model
|
||||
|
||||
|
||||
In fact, given a simple perspective camera model like the one shown in figure, extrinsic parameters can be used to transform a point from its world coordinates {xw,yw,zw} to the camera 3D coordinate system {x,y,z}):
|
||||
\image html "../img/shot-Projection.png"
|
||||
\image html "shot-Projection.png"
|
||||
In this case the extrinsic parameters are a 3 X 3 rotation matrix R and a translation vector T, which define the orientation and position of the camera. In order to transform the 3D camera coordinate in 2D image plane coordinates (Xu,Yu) it's necessary to know the measure of the distance between the point of view and the image plane (OO1 in figure): this value, indicated with f, is usually known as the focal length. The relation between the camera and image coordinates of the point can be expressed as follows:
|
||||
\image html "../img/shot-Focal.jpg"
|
||||
\image html "shot-Focal.jpg"
|
||||
|
||||
Another aspect of the structure of a camera that can be characterized is the distortion introduced by the lenses: if we suppose that the distortion is radial (performed along the radial direction respect to the center of distortion) we can calculate the undistorted image coordinates
|
||||
|
||||
\image html "../img/shot-Distort1.jpg"
|
||||
\image html "shot-Distort1.jpg"
|
||||
where
|
||||
\image html "../img/shot-Distort2.jpg"
|
||||
\image html "shot-Distort2.jpg"
|
||||
and
|
||||
\image html "../img/shot-Distort3.jpg"
|
||||
\image html "shot-Distort3.jpg"
|
||||
|
||||
In conclusion, a quite accurate model of a camera can be described by:
|
||||
- A 3x3 rotation matrix and a translation vector for extrinsic parameters
|
||||
|
|
|
|||
Loading…
Reference in New Issue