range check for vertex colors and normals in OBJ loader
This merge request adds explicit range checks and error reporting for the reading of colors and normals. The code is copied from texture coordinates, where a similar check already existed.
See merge request !92
Fixed broken indices for some cases of OBJ parsing by using two passes
(Continuing fixing / discussion from https://graphics.rwth-aachen.de:9000/OpenMesh/OpenMesh/merge_requests/51)
This merge request is fixing an issue that came up as a follow-up of the following merge request:
https://graphics.rwth-aachen.de:9000/OpenMesh/OpenMesh/merge_requests/51
The problem it fixes occurs for some kinds of OBJ data, where vertices and face data are stored interleaved and, at the same time, the mesh contains some non-manifold geometry. As non-manifold geometry triggers the on-the-fly creation of new vertices during parsing, the indices from the OBJ file do not match any more and the result gets messed up.
The straightforward solution applied on this branch is to parse to whole OBJ file in two passes, first the vertices and then the material data and faces. This way, possible extra vertices will always be added to the back, not interfering with indices from the OBJ file
I tested the performance on a 1.1 GB OBJ file. The loading time on my machine increased from ~59 seconds to ~65 seconds, so I believe the performance overhead could probably be considered acceptable.
Looking forward to your feedback!
See merge request !84
g++ 4.7 compile fix in vector11
With g++ 4.7, the following error occurs when trying to compile code that uses Vector11:
```
../OpenMesh/Core/Geometry/Vector11T.hh: In function ‘decltype ((_v1 % _v2)) OpenMesh::cross(const OpenMesh::VectorT<LScalar, DIM>&, const OpenMesh::VectorT<RScalar, DIM>&) [with LScalar = float; RScalar = float; int DIM = 3; decltype ((_v1 % _v2)) = OpenMesh::VectorT<float, 3>]’:
../OpenMesh/Core/Geometry/Vector11T.hh:89:19: error: ‘OpenMesh::VectorT<float, 3>::container OpenMesh::VectorT<float, 3>::values_’ is private
```
It looks like this version of g++ would not be able to deal with the decltype statement used when overriding the "%" operator, where the "this->values_" part is not working properly. This issue should be fixed with this merge request.
See merge request !87
As with ms compilers, the shared/static compilation depends on export macros.
Anyway this is inconsistent with the behavior for openmeshtools library.
Why did you add this ?
- Based on the macro provide partial specializations for std::hash<>
- for vertex,halfede,edge, and face handles.
- Add a free function hash_value(BaseHandle) for boost::unordered_set/map
