| Age | Commit message (Collapse) | Author |
|---|
|
SCons is currently broken on my laptop, so can't test if it works for sure,
so please do tests of that.
|
|
The issue was caused by the wrong attributes maps in certain
circumstances after union intersections.
Namely issue might have happen when more than one iteration of
union was happening and it was caused by the fact that new faces
might be allocated on the same address as freed face from the
old mesh.
Didn't find a nicer fix for this apart from correcting the whole
attributes map after each union step.
We could try removing attributes for the meshes which are getting
deleted, but in asymptotic it's gonna to give exactly the same
complexity as the current approach.
|
|
The typos didn't cause any bug, but the mis-ordered parameter names in CarveExporter_InitGeomArrays were confusing.
Reviewers: sergey
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D709
|
|
This brings new copyright header which supports GPL2 and 3.
It wasn't really an issue before because we had agreement with
Tobias, but now it's all documented in sources.
|
|
In the future i'd rather have this reported to an
upstream instead of adding local changes. It's really
easy to override this changes if patchset is not added
and this is to be fixed in upstream. Also the function
was never used so it was rather totally harmless warning
for us.
|
|
|
|
Mapping to original face was never working 100% reliably actually,
now use more robust method for this.
|
|
build the matrix directly rather then calculating with axis/angle
also remove unused function calc_poly_plane
|
|
This was a nasty bug which was caused by specific of how face-edge
attributes are stored in Carve.
Face pointer is used in the map key which works just fine in all
cases except for the cases when some face is getting freed after
it was stored in the map.
This might give real issues when new face is allocating because
it's possible new face would have the same address as the freed
one.
Such cases used to happen when union of separate manifolds is
needed for the operands AND jemalloc is enabled.
Solved by dropping attributes for the freed faces from the map.
Maybe not the fastest ever approach, but not sure how to make
it faster actually. Should work just fine. It only happens for
complex setups with intersecting manifolds in the operands.
|
|
Based on D420
|
|
This re-applied patch from 25cbd13 which was lost at some point
since missing patchset in series.
This revision is to be back-ported to the final release.
|
|
In fact we had this change a while ago, not sue what happened.
|
|
Also added a patchset for Carve's memory leak fix.
|
|
|
|
There were loads of issues in the code still which are mow likely fixed:
- Hole resolver hook had memory leak -- it didn't free face with holes
when triangulating it.
- Original edge mapping didn't work correct. old code related on the fact
that loop order is not changing when constructing the MeshSet class, but
in fact it does change.
Currently used edge map for this because it was easiest way to do it now,
but after the release we're to change it. Main reason is that face mapping
is not correct as well (and it was never correct actually). So we'll need
to construct Mesh structures by our own to be sure we're using correct
original index mapping.
- Carve might produce faces with ears, which is forbidden in Blender.
it wasn't an issue in old integration because triangulation will remove
the ears. So for now simply added ears removing back as a hook.
But actual reason of the ears is to be investigated really.
This hook will only work for NGons, quads are assumed not be able to
have ears. So this additional hook shouldn't slow down things much.
- Carve's hole resolver produces duplicated faces in some cases. Still not
sure what is the reason of this. Code here is not so much straightforward,
this is to be investigated later.
For now solved the issue as own hole resolver which checks for duplicated
faces after the hole resolving.
The additional checks here will only run if the mesh actually have hole
and wouldn't introduce slowdown for faces which doesn't have holes.
- Made it so if edge user triangulation gets a split (for example, in cases
when this edge intersects with the second operand) it wouldn't be dissolved.
This prevents cases of crappy topology after dissolving in several cases.
- Edge dissolver didn't check for whether edge is a non-manifold. We couldn't
really dissolve open manifold edges.
The bad thing about this is that mesh triangulation might produce non-manifold
edges and they wouldn't be dissolved. Not worst case in the world, but would
be nice to have it solved somehow.
- Exporting mesh form Carve to Blender might have produced duplicated edges
in cases when several non-manifold faces shared the edge. This is also fixed
now.
- Mesh triangulation might have produced duplicated faces, which is really bad.
Fixed by keeping a track on which faces we've created and skipping adding new
triangle if we already have one.
This all might introduce some slowdown, but we're too close to the release now,
so would rather have it slower but robust. After the release we might look into
ways to speed things up.
|
|
|
|
|
|
This commit implements dissolving of edges which were used
to triangulate non-flat faces. This slows things down a bit
(around 5% on heave mesh with all faces triangulated).
We could improve speed of dissolve a bit here (so not a bell
to add an option for triangulation yet).
Also fixed wrong edge origindex mapping.
|
|
Simple fix -- use CarveHoleResolver hook for CSG which will split faces
containing holes.
|
|
Own mistake in edges carve->blender export, didn't count them correct.
|
|
|
|
Patch by wutzi (Benedikt Bergenthal), thanks!
Reviewers: sergey
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D314
|
|
Goal of this commit is to support NGons for boolean modifier
(currently mesh is being tessellated before performing boolean
operation) and also solve the limitation of loosing edge custom
data layers after boolean operation is performed.
Main idea is to make it so boolean modifier uses Carve library
directly via it's C-API, avoiding BSP intermediate level which
was doubling amount of memory needed for the operation and which
also used quite reasonable amount of overhead time.
Perhaps memory usage and CPU usage are the same after all the
features are implemented but we've got support now:
- ORIGINDEX for all the geometry
- Interpolation of edge custom data (seams, crease)
- NGons support
Triangulation rule is changed now as well, so now non-flat
polygons are not being merged back after Carve work. This is
so because it's not so trivial to support for NGons and
having different behavior for quads and NGons is even more
creepy.
Reviewers: lukastoenne, campbellbarton
Differential Revision: https://developer.blender.org/D274
|
|
|
|
|
|
|
|
|
|
Fixes some issues with NaN vertices in special cases.
Also adds edge interpolation routines which are currently
unused but which are requires to implement edge CD interpolation.
|
|
Based on the patch from Joerg Sonnenberger.
|
|
Based on the patch from Marcus von Appen, thanks!
|
|
|
|
- random.hpp was only removed from actual include
directory, but not from patches/files.
- Files list generator didn't ignore config.h file
which in fact is not needed.
|
|
remove MEM_sys_types.h which was a duplicate.
|
|
Stupid mistake by my own with recent Carve update which
undid fix for MSVC STL library.
|
|
Perhaps some warnings could be silenced, but not in mood of writing
local patches at this moment. They're all harmless anyway.
|
|
which could happen in cases of degenerated faces.
|
|
The issue was caused by passing start iterator larger than end iterator
to std::copy in triangulation module. It'll do nothing on linux but will
throw an exception on windows. Now behavior will be identical on both
platforms.
Proper solution would be to figure out why exactly this happened, but it's
easier to be forwarded to Tobias and we'll need to get rid of triangulation
anyway.
This should solve issues:
#30100: boolean intersect crashes blender
#33001: Crash on applying Boolean difference modifier
#33045: Boolean modifier crash with mirrored objects
|
|
|
|
reported: http://code.google.com/p/carve/issues/detail?id=33
|
|
|
|
|
|
cleanup
|
|
slight modifications.
Thanks!
|
|
issues with clang
|
|
|
|
Crash was caused by error in Carve triangulator. Fixed by upgrading Carve library.
|
|
|
|
|
|
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.
|
