Issue was caused by union policy needed to deal with cases when operand intersects
two or more intersecting meshes of another operand.
Changed this policy to run union operation only if there's actual intersection
between two meshes of the same object. Should work in general but it's still
possible to make it behave incorrect -- for example object consist of two groups
if concentric cubes which intersects each other.
Issue was caused by left boolean operand consist of several intersecting manifolds
which make Carve triangulator confused and which can't be resolved in general case.
Added mesh pre-processing before actual applying boolean operator on it. This
preprocessing applies union operation on intersecting manifolds of the same object
so intersection edge loop with second object wouldn't confuse tesselator and correct
result would be returned.
Detecting of intersecting manifolds is based on AABB intersection check which leads
to some extra union operation called, but it's possible to speed things up from
Carve side so union operation of two not intersecting meshes would work faster.
Additional condition for running union for manifold is this manifolds intersects
AABB of second operand, so mesh topology wouldn't be changed at all in areas
where there's definitely no intersection between operands. It might be improved
so only manifolds which actually intersects second operand would be joined
together, but it'll slow things down a bit and prefer to do it only if it'll
be really a problem.
Additional change is fixed memory leak when boolean operation fails to run -
it was missed "delete" call if exception happens in Carve library.
From side effects of this change might be named boolean operation between
suzanne and another object: suzanne is consist of three intersecting open
manifolds, so this new meshes preprocessing leads to missed eyes in result
because of failure of merging two open manifolds. Don't think making suzanne
work for all setups should really be a goal, it's a bit crappy mesh for CSG
algorithms.
Error was caused by boost library (which doesn't seem to be working with Cycles too
when compiling with mingw). Switched mingw to use TR1 unordered collections. Also,
there was re-declaration of strcasecmp when mingw is used.
Additional changes are related on using own process spawning when BF_TOOLSET is set to
mingw. Seems to be working fine now (i've got too long command line error) and no
warning are supressing now (as it was told in comment for commented own process spawning).
==================================
Merging Carve library integration project into the trunk.
This commit switches Boolean modifier to another library which handles
mesh boolean operations in much stable and faster way, resolving old
well-known limitations of intern boolop library.
Carve is integrating as alternative interface for boolop library and
which makes it totally transparent for blender sources to switch between
old-fashioned boolop and new Carve backends.
Detailed changes in this commit:
- Integrated needed subset of Carve library sources into extern/
Added script for re-bundling it (currently works only if repo
was cloned by git-svn).
- Added BOP_CarveInterface for boolop library which can be used by
Boolean modifier.
- Carve backend is enabled by default, can be disabled by WITH_BF_CARVE
SCons option and WITH_CARVE CMake option.
- If Boost library is found in build environment it'll be used for
unordered collections. If Boost isn't found, it'll fallback to TR1
implementation for GCC compilers. Boost is obligatory if MSVC is used.
Tested on Linux 64bit and Windows 7 64bit.
NOTE: behavior of flat objects was changed. E.g. Plane-Sphere now gives
plane with circle hole, not plane with semisphere. Don't think
it's really issue because it's not actually defined behavior in
such situations and both of ways might be useful. Since it's
only known "regression" think it's OK to deal with it.
Details are there http://wiki.blender.org/index.php/User:Nazg-gul/CarveBooleans
Special thanks to:
- Ken Hughes: author of original carve integration patch.
- Campbell Barton: help in project development, review tests.
- Tobias Sargeant: author of Carve library, help in resolving some
merge stoppers, bug fixing.
blender_add_lib now takes a separate include argument to suppress warnings in system includes (mostly ffmpeg & python).
also only build wm_apple.c on apple+carbon configuration.
globbing vs explicit is discussed here.
http://www.cmake.org/pipermail/cmake/2008-December/025694.html
Practical implications are:
- developers need to keep CMakeLists.txt files up to date.
- Users wont get strange linking errors if they build after a file is added, since CMake detects CMakeLists.txt is modified and automatically reconfigure.
I did a very drastic cleanup for the different libgroups, there's now only a few left. It compiled with scons/msvc, will be testing in a bit on linux, too.
If you get any problems, please reply to this commit message on the taskforce ML.
BOP_Merge2.cpp
had same variable name at different scopes so I renamed a couple.
resources.c
added include that was missing. (This maybe was going to move? the old one
was commented out)
ed_markers.c
initalized a var that needed it.
Kent
svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r12987:17416
Issues:
* GHOST/X11 had conflicting changes. Some code was added in 2.5, which was
later added in trunk also, but reverted partially, specifically revision
16683. I have left out this reversion in the 2.5 branch since I think it is
needed there.
http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=16683
* Scons had various conflicting changes, I decided to go with trunk version
for everything except priorities and some library renaming.
* In creator.c, there were various fixes and fixes for fixes related to the -w
-W and -p options. In 2.5 -w and -W is not coded yet, and -p is done
differently. Since this is changed so much, and I don't think those fixes
would be needed in 2.5, I've left them out.
* Also in creator.c: there was code for a python bugfix where the screen was not
initialized when running with -P. The code that initializes the screen there
I had to disable, that can't work in 2.5 anymore but left it commented as a
reminder.
Further I had to disable some new function calls. using src/ and python/, as
was done already in this branch, disabled function calls:
* bpath.c: error reporting
* BME_conversions.c: editmesh conversion functions.
* SHD_dynamic: disabled almost completely, there is no python/.
* KX_PythonInit.cpp and Ketsji/ build files: Mathutils is not there, disabled.
* text.c: clipboard copy call.
* object.c: OB_SUPPORT_MATERIAL.
* DerivedMesh.c and subsurf_ccg, stipple_quarttone.
Still to be done:
* Go over files and functions that were moved to a different location but could
still use changes that were done in trunk.
When using BF_SPLIT_SRCS as a hack to get some of the larger libs compiled, there were some problems linking Blender related to some boolean calls. This commit tweaks the priorities for the boolean libs for the 'intern' group so that they get linked before the src libs are.
-----
New boolean merge algorithm. The current code often does a poor job of merging tris and quads after the operation, resulting in many unnecessary faces. This commit add a new algorithm which takes advantage of topology information saved in the interal BOP structures.
The file intern/boolop/intern/BOP_Misc.h has two #defines which control which algorithm(s) are compiled. They are set now to compile both, with the new algorithm as the default. The original algorithm can be enabled by setting the "rt" debugging button on the Scene panel (F10) to 100.
One note: the current boolean code still occasionally creates a non-manifold mesh from an operation on two manifold meshes. The original merge algorithm would sometimes "close" these meshes and sometimes not. The new algorithms behaves the same way, but sometimes closes a mesh the original would not and sometimes leaves open a mesh the original would close. My fairly extensive tests did not indicate any significant difference in the percentage of final non-manifold meshes.
-----
Minor changes to boolean code; add an new include file to gather various
#defines global to the boolean system. Currently, this just allows control
of whether some debugging code is compiled or not.
This is a precursor commit for some other boolean optimizations/cleanups.
But in case that commit is later reverted, this code should still remain.
-----
More improvements to boolean tools. The main change (although very little in
code) is changing fuzzy comparisons of floating point values. For testing, a
new define is added in intern/boolop/intern/BOP_MathUtils.h called
VAR_EPSILON, which enables better comparisons. This is turned on by default;
undefining it will revert to using the previous comparisons. The downside of
these new comparisons is a loss in speed, but the resulting meshes are more
likely to be manifold (although still not always).
The other changes include speed improvements based on profiling results and
fixes for the improper creation of triangular faces with only two vertices.
------
Bugfix #6847: Previous fix for "spikes" when using booleans caused creation
of faces with only two unique vertices ("eekadoodles"). This patch cleans up
the test for triangles with near-colinear vertices so PHANTOM faces can be
used again, and also adds a hack for now which removes any eekadoodle faces.
I haven't figured out yet exactly how the faces are being created; if I can
do so and fix it the hack will be removed.
-----
Bugfix #6847: Boolean code was marking some valid faces as "PHANTOM" when the
three vertices were nearly co-linear (according to its tests). This
introduced holes into one or both meshes which could then result in either
holes in the final results and/or spurrious faces which should have been
split.
This commit removes the code in question until either an alternative test is
coded.
which caused faces of convex objects to be classified wrongly. Also removed
some dead code. For convex objects, the BSP trees would also be literally
orders of magnitude larger than they were supposed to be (one test with a
5000 face torus reduced the BSP tree size from 5.96 million nodes to just 72.1
thousand).
I should have talked to joeedh before committing last time...
This is an another attempt to fix the mingw long commandline
issue on all versions of windows (I didn't realize that the
2k in Win2k refered to the length of the commandline).
In this version, I break libsrc.a up so that no archive has
more than 30 object files (adjustable with one line of
code). I also fudge the priority numbers to ensure correct
linking. This was done in a "guess the number" way until
it worked, so please test and please check for correctness.
