| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 651 |
4210 d 17 h |
janba |
/branches/cpp11-devel/src/Geometry/ |
Added the XForm and Implicit classes. |
|
| 632 |
4347 d 12 h |
janba |
/branches/cpp11-devel/ |
Had fun rewriting ArithVec.h |
|
| 631 |
4350 d 8 h |
janba |
/branches/cpp11-devel/ |
Many C++11 features added to this branch |
|
| 630 |
4350 d 8 h |
janba |
/branches/cpp11-devel/ |
Add branch for c++11 development |
|
| 622 |
4576 d 22 h |
jrf |
/trunk/src/Geometry/ |
adding functions for texture coordinate transformation to TriMesh (and coding style change: tabs -> spaces) |
|
| 621 |
4578 d 21 h |
jrf |
/trunk/src/Geometry/ |
Bug: error when reading 3ds Max mtl-file export. Fix: new fstream loader is more strict, so we have to be more careful when reading input. |
|
| 612 |
4585 d 11 h |
jrf |
/trunk/src/Geometry/ |
correcting bug in last commit |
|
| 610 |
4585 d 11 h |
jrf |
/trunk/src/Geometry/ |
removing VS warnings |
|
| 609 |
4585 d 12 h |
jab |
/trunk/ |
I have added some patches to make cmake work for Unix Makefiles on Mac.
The old Makefile system has been removed.
Slight change to XCode project
Minor changes |
|
| 607 |
4587 d 20 h |
jrf |
/trunk/ |
removing Visual Studio warnings and some CMake problems |
|
| 606 |
4587 d 20 h |
jrf |
/trunk/src/Geometry/ |
ensuring compatibility with code based on pre-merge trunk version |
|
| 605 |
4591 d 7 h |
jab |
/trunk/ |
|
|
| 601 |
4593 d 23 h |
jab |
/trunk/ |
The include statements for header files have been changed. Instead of including, like say
#include <CGLA/Vec3f.h>
we now use
#include "../CGLA/Vec3f.h"
for all files in the GEL library source tree (i.e. apps and test are not altered).
The point is that if GEL is used as an OSX framework and I include a GEL header, I have to do it like this:
#include <GEL/HMesh/myheader.h>
Now, inside myheader.h I may include CGLA/Vec3f.h, but how should this file be found? If I just add the GEL
framework as a framework, the path to the GEL headers is not added to the header search path because the
framework name (in this case GEL) is part of the header path. If all headers had been in one directory that
would not have mattered, since Vec3f.h would be in the same directory as myheader.h. But it is not. So, I
have made things more relative and it works well. |
|
| 600 |
4596 d 6 h |
jab |
/ |
Build system. I have both edited the bespoke Xcode project file, played with a premake4 build generator and our cmake system. Nothing works perfectly, but cmake might end up as the best solution. The cmake file now automatically finds the GEL files, but this entails that cmake is run when a new file is added.
Functions were added to Manifold: remove_face, remove_edge, remove_vertex. These do as advertised. I also added an add_face function (not tested but very simple ... hmmm famous last words)
the cpp/h file pairs close_holes and caps_and_needles were merged into "cleanup". To cleanup I added some functions that stitch meshes together, i.e. edges which share geometric end points are stitched. |
|
| 595 |
4597 d 12 h |
jab |
/trunk/src/ |
Merged version |
|
| 567 |
4852 d 19 h |
jrf |
/trunk/src/Geometry/ |
adding area information to TriMesh |
|
| 554 |
5088 d 11 h |
jrf |
/trunk/src/Geometry/ |
Ray::reset() has been updated to include reset of more recently added ray properties. |
|
| 541 |
5279 d 23 h |
jrf |
/trunk/src/Geometry/ |
Using references instead of copying vectors when not necessary. And fixing some iterator code in the BSPTree that doesn't work in VS2010. |
|
| 510 |
5466 d 0 h |
jrf |
/trunk/src/ |
Enabling load of wavefront .mtl files without an associated object, and correcting the Material class slightly (ior instead of ior_in and ior_out). |
|
| 492 |
5592 d 8 h |
jrf |
/trunk/ |
Repairing and cleaning the OBJ Viewer app:
- load.h and load.cpp were missing in the cmake list of the Geometry package (causing the viewer not to compile in VS).
- It was previously illegal to include draw.h after including gel_glut.h (the problem was inclusion of glew.h in header files included by draw.h. This is undesirable as an application does not necessarily need glew.h when using draw.h).
- A lot of unnecessary header files were included here and there. |
|