added code to write faceTexCoords to obj writer.
fixes#25
* Added accessor functions for HalfEdgeHandles and faceTexCoords to base exporter and exporter template.
* Added functionality to store FaceTexCoords to objwriter
* Added unittest to write and read faceTexcoords with a test obj file
See merge request !73
make all negative handles invalid, not just -1
Since opposite_halfedge_handle for a handle with idx -1 produces a handle with idx -2, it can be helpful to detect handles with -2 as index as invalid as well.
See merge request !96
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
Added unit test to trigger GCC alignment bug. See #32.
Merge this even if CI unit tests fail. Failed unit test expose a compiler bug.
See merge request !86
Stl type check
implemented the suggested changes from #24 by checking stl files for the keyword solid instead of computing binary file size.
closes#24
See merge request !83
