gelsvn
bdplot
seema-scanner
BlueGrey
calm
Elegant
Català-Valencià – Catalan
中文 – Chinese (Simplified)
中文 – Chinese (Traditional)
Česky – Czech
Dansk – Danish
Nederlands – Dutch
English – English
Suomi – Finnish
Français – French
Deutsch – German
עברית – Hebrew
हिंदी – Hindi
Magyar – Hungarian
Bahasa Indonesia – Indonesian
Italiano – Italian
日本語 – Japanese
한국어 – Korean
Македонски – Macedonian
मराठी – Marathi
Norsk – Norwegian
Polski – Polish
Português – Portuguese
Português – Portuguese (Brazil)
Русский – Russian
Slovenčina – Slovak
Slovenščina – Slovenian
Español – Spanish
Svenska – Swedish
Türkçe – Turkish
Українська – Ukrainian
Oëzbekcha – Uzbek
Subversion Repositories
gelsvn
(root)
/
branches
/
cpp11-devel
/
src
/
Geometry
/
BSPTree.cpp
– Rev 630
Rev
Show changed files
|
Details
|
Compare with Previous
|
Blame
|
RSS feed
Filtering Options
From rev
To rev
Max revs
Search history for
Show All
Rev
Age
Author
Path
Log message
Diff
630
4347 d 23 h
janba
/branches/cpp11-devel/
Add branch for c++11 development
601
4591 d 14 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.
595
4595 d 3 h
jab
/trunk/src/
Merged version
541
5277 d 14 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.
451
5856 d 3 h
jrf
/trunk/src/Geometry/
the golden middle way with respect to precision for ray-triangle intersection distance check
450
5863 d 1 h
jrf
/trunk/src/Geometry/
increasing precision for ray-triangle intersection distance check
438
5897 d 1 h
jrf
/trunk/src/Geometry/
correcting a bug in placement of BSP planes and cleaning up a little bit
430
5915 d 21 h
jrf
/trunk/src/Geometry/
Minor correction to avoid numerical errors
429
5915 d 21 h
jrf
/trunk/src/Geometry/
Improving ray-triangle intersection implementation and removing unnecessary static variables.
428
5915 d 22 h
jrf
/trunk/src/Geometry/
Correcting major bug in BSPTree. It was clearing a vector and using it afterwards as if it hadn't been cleared. Unbelievable that we haven't seen problems because of this.
364
6212 d 16 h
jrf
/trunk/src/Geometry/
Corrections to have the ray tracer run properly in Visual Studio
354
6380 d 22 h
awk
/trunk/src/
350
6393 d 20 h
awk
/trunk/
Worked around bug in BSPTree. "intersect_fast_node" does not work with
GCC!
349
6393 d 20 h
awk
/trunk/
Misc fixed to make it compile on ubuntu 7.10
319
6663 d 15 h
awk
/trunk/src/Geometry/
Partitioned interface into public / private..
Changed all TriMesh* to const TriMesh*
Commented normal computation code in intersect in..
Fixed bug with normals (object space normals were returned, not world space)
314
6702 d 2 h
jrf
/trunk/src/Geometry/
313
6716 d 20 h
jrf
/trunk/
BSPTree ray tracing now works well !
The problem was a way too large epsilon causing triangles to appear unnecessarily in several different space division boxes. Precision has now been increased and the code has been made more robust. Try it out on the bunny.
311
6716 d 22 h
jrf
/trunk/src/Geometry/
310
6716 d 22 h
jrf
/trunk/
BSPTree corrections
304
6723 d 0 h
jab
/trunk/src/
I have made minor changes to ensure that GEL compiles on Linux.
←Prev
1
2
Next→
Show All