[Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [43428] trunk/blender: Carve booleans library integration

Sergey Sharybin sergey.vfx at gmail.com
Tue Jan 17 09:01:21 CET 2012


I don't think booleans were used much. And to setup such procedural setup
which is animated.. Think it was quite difficult to setup really useful
setup with that topology generating by boolop. Another thing which makes me
believe such procedural setups weren't used is than even in static scene
with cubes and spheres boolop fails and gave artifacts. In scene for
screenshot on wiki page (
http://wiki.blender.org/index.php/User:Nazg-gul/CarveBooleans) boolop kept
segments of some spheres attached to cube instead of just subtract them in
the same nice way.

Anyway, i'd suggest to collect more artists opinions and if it'll be
something like "oh no, you killed boolop and now my scene fails AT ALL!!!!"
then we can think about ways to resolve this. Until this i don't think
we'll want to add extra options here :)

On Tue, Jan 17, 2012 at 1:48 PM, Matt Ebb <matt at mke3.net> wrote:

> On Tue, Jan 17, 2012 at 6:44 AM, Campbell Barton <ideasman42 at gmail.com
> >wrote:
>
> >
> > IMHO its a weak solution unless there is some intent to maintain the
> > older (currently unmaintained) booleans code, or someone can show
> > examples where the older code consistently wins out.
> >
>
> After having used the old boolean modifier, I can't imagine the older code
> winning out on a quality level at all ;) The reason I mention this is not
> to promote the idea of having two options for people to actively choose
> from, but mainly for compatibility when loading up existing setups.
>
> If you're using booleans for simple modelling (eg. sphere + cube) then
> there's not really much difference and you can happily proceed. However, if
> you're using booleans as part of a more complex procedural setup - eg.
> followed by shrinkwrapping or array merging, or any other things that
> depend on topology, then if you load up your file and the topology output
> by the boolean modifier has changed, then it can break existing setups.
>
> This breakage could be obvious, or it could be the sort of thing you only
> notice at certain frames after it's been sent off for render. Either way,
> you have no way of fixing it by going back to the old backend that you have
> have created your procedural setup to work with/around. In pipelines using
> other apps that put a greater emphasis on procedural modelling, people
> generally avoid changing geometry modifying tools in-place (which can have
> unexpected results), but rather use versioning so that old setups remain
> identical.
>
> If you guys have the burden of maintaining the code, I understand your
> reluctance - in this case IMO it's a case of judging where the balance is
> between code maintenance effort vs likelihood of blender users getting
> screwed by procedural setups that involve the existing boolean modifier.
> Maybe you'll judge it's not that likely - it's your choice.
>
> Either way, I'm trying to bring up the point that it's not just about what
> is 'better', it's also how much potential disruption it can cause by
> forcing the change for all existing instances of the modifier.
>
> cheers
>
> Matt
>
>
>
>
> > On Tue, Jan 17, 2012 at 4:42 PM, Matt Ebb <matt at mke3.net> wrote:
> > > Sounds really good!
> > >
> > > One thing though - is the old code going to be kept around? If it is,
> it
> > > would be good to make the choice of backend optional in the UI, and
> > default
> > > old files to the old backend. If someone's tweaked the old modifier to
> > give
> > > acceptable results, it could potentially cause an existing setup to
> freak
> > > out when the new backend is used giving different output and topology.
> > >
> > > IMO better to 'deprecate' by making it optional for a while, than
> change
> > > behaviour in all existing files with no recourse.
> > >
> > > cheers
> > >
> >
> > > Matt
> > >
> > >
> > > On Mon, Jan 16, 2012 at 4:46 PM, Sergey Sharybin <sergey.vfx at gmail.com
> > >wrote:
> > >
> > >> Revision: 43428
> > >>
> > >>
> >
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=43428
> > >> Author:   nazgul
> > >> Date:     2012-01-16 16:46:00 +0000 (Mon, 16 Jan 2012)
> > >> Log Message:
> > >> -----------
> > >> Carve booleans library integration
> > >> ==================================
> > >>
> > >> 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
> > >>
> > >>
> > > _______________________________________________
> > > Bf-committers mailing list
> > > Bf-committers at blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> >
> >
> > --
> > - Campbell
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin


More information about the Bf-committers mailing list