bool FaceType::IsXXXAvaialble() ,must be defined in the XXX ocf type and not in the info type otherwise it would be defined also for non ocf components.
now we have
static bool FaceType::HasXXX() // statically says if a certain type is present
bool FaceType::IsXXXAvaialble() // NON STATIC (always true for non ocf objects)
So now ImportData works for face ocf component.
The vertex and face component (natural and optional) have been cleaned and reordered.
Particular care has been devoted to have common behaviour in the import, const access, and so.
If you get compilation errors probably it is due to the fact that if you really need constant access to a member you have to use the "c" prefixed member (e.g. if you access to normal of a constant vertex you should use the cN() member.
No more need of including them.
It was needed to avoid the issue of wrong inclusion order that could trigger a failure in the partial specialization of the reflection functions that should say if a component is present or not...
- Cleaned up include order: Now you only need to include <vcg/complex/complex.h> (no more vertex/base.h etc)
- Added official VN() EN() FN() const members for knowing number of vertexes etc...
- Added exceptions (at last!)
Now instead of:
assert(HasPerVertexNormal(m))
you should write:
if(!HasPerFaceNormal(m)) throw vcg::MissingComponentException();
Corrected the name of the function allocating a user bit among the flags of the simplexes.
Changed in ALL the simplexes (vertex, edge, face, etc) and updating functions.
Note that the LastBitFlag should never be used by common users...
About the point to mesh distance functionalities
Now the two different 'path' for this distance computation (with or without the precomputation of planes and edges for triangular faces) are well distinct and with different names:
PointDistanceEP and PointDistanceBase
See the sample/trimesh_closest sample for more details
Changed the basic reflection mechanism: Instead of having a function templates over all the four containers now we template over Trimesh and we rely on a second function templated on face/vert that wants a vector<face> ; this second function only is eventually overloaded by another function that needs a vector_ocf of faces.
That is Before we had:
- in complex.h
template < class CType0, class CType1, class CType2 , class CType3>
bool HasPerFaceVFAdjacency (const TriMesh < CType0, CType1, CType2, CType3> & /*m*/) {return TriMesh < CType0 , CType1, CType2, CType3>::FaceContainer::value_type::HasVFAdjacency();}
- in the component_ocf.h
template < class VertContainerType, class FaceType, class Container1, class Container2 >
bool HasPerFaceVFAdjacency (const TriMesh < VertContainerType , face::vector_ocf< FaceType >, Container1, Container2 > & m)
{
if(FaceType::HasVFAdjacencyOcf()) return m.face.IsVFAdjacencyEnabled();
else return FaceType::FaceType::HasVFAdjacency();
}
While now we have:
- in complex.h
template < class FaceType > bool FaceVectorHasPerFaceVFAdjacency (const std::vector<FaceType > &) { return FaceType::HasVFAdjacency(); }
template < class TriMeshType> bool HasPerFaceVFAdjacency (const TriMeshType &m) { return tri::FaceVectorHasPerFaceVFAdjacency (m.vert); }
- and in component_ocf.h
template < class FaceType >
bool FaceVectorHasPerFaceVFAdjacency(const face::vector_ocf<FaceType> &fv)
{
if(FaceType::HasVFAdjacencyOcf()) return fv.IsVFAdjacencyEnabled();
else return FaceType::HasVFAdjacency();
}
It has a bug that could return a nan in some degnerate case where an almost null face has different vertices but the squared distance between them could be zero.
Now it should handle also these cases.
Paolo Cignoni
Nico Pietroni
ganovelli