Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [43428] trunk/blender: Carve booleans library integration
Hi Sergey, And here's an example (2 co-planar cylinders) where carve fails completely right now. http://www.pasteall.org/blend/11042 I think it's possibly because of the coplanar faces or the colinear edges. Blender trunk 43555, compiled by myself on Win32. Cheers, Martin Sergey Sharybin sergey@gmail.com Hi, Yeah, that's indeed not nice topology. Will look into this thing. On Wed, Jan 18, 2012 at 4:48 PM, Martin Bürbaum http://www.pasteall.org/blend/11020 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [43428] trunk/blender: Carve booleans library integration
Hello Sergey, first of all many thanks to you and Tobias for the work on the carve/boolean code. I know your request was directed at Carsten, but I can provide an example where the boolean code still has some issues. http://www.pasteall.org/blend/11020 The file was created with Blender trunk revision 43484. I used a default cube and a default cylinder and joined them with a boolean Union modifier. (The same problems exist when using Difference and Intersect.) The applied mesh looks quite nice on first glance, but the joint seam is composed of bad quads (e.g. zero surface polygons, 3 points in a row, concave). Some of these are marked with grease pencil arrows, but there may be more - I suggest following the seam and check every polygon (especially on the cube) to find strange behaviour. I'm not sure how easy it is to improve this, I just wanted to point out the things I've seen. Cheers, Martin Original-Nachricht Datum: Tue, 17 Jan 2012 22:52:03 +0600 Von: Sergey Sharybin sergey@gmail.com An: bf-blender developers bf-committers@blender.org Betreff: Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [43428] trunk/blender: Carve booleans library integration Hi, Well, if you'll provide some files where you think new booleans fails when they shouldn't it might help a lot. Me or Tobias (Carve's author) can try to improve something. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [43428] trunk/blender: Carve booleans library integration
Hi, Yeah, that's indeed not nice topology. Will look into this thing. On Wed, Jan 18, 2012 at 4:48 PM, Martin Bürbaum martin.buerb...@gmx.atwrote: Hello Sergey, first of all many thanks to you and Tobias for the work on the carve/boolean code. I know your request was directed at Carsten, but I can provide an example where the boolean code still has some issues. http://www.pasteall.org/blend/11020 The file was created with Blender trunk revision 43484. I used a default cube and a default cylinder and joined them with a boolean Union modifier. (The same problems exist when using Difference and Intersect.) The applied mesh looks quite nice on first glance, but the joint seam is composed of bad quads (e.g. zero surface polygons, 3 points in a row, concave). Some of these are marked with grease pencil arrows, but there may be more - I suggest following the seam and check every polygon (especially on the cube) to find strange behaviour. I'm not sure how easy it is to improve this, I just wanted to point out the things I've seen. Cheers, Martin Original-Nachricht Datum: Tue, 17 Jan 2012 22:52:03 +0600 Von: Sergey Sharybin sergey@gmail.com An: bf-blender developers bf-committers@blender.org Betreff: Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [43428] trunk/blender: Carve booleans library integration Hi, Well, if you'll provide some files where you think new booleans fails when they shouldn't it might help a lot. Me or Tobias (Carve's author) can try to improve something. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [43428] trunk/blender: Carve booleans library integration
Am 17.01.2012 17:52, schrieb Sergey Sharybin: Hi, Well, if you'll provide some files where you think new booleans fails when they shouldn't it might help a lot. Me or Tobias (Carve's author) can try to improve something. It is not that carve fails, but carve fails with tweaked objects that work with boolop. So more a matter of compatibility of old scenes with carve. Carsten -- Carsten Wartmann: Autor - Dozent - 3D - Grafik Homepage: http://blenderbuch.de/ Das Blender-Buch: http://blenderbuch.de/redirect.html ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [43428] trunk/blender: Carve booleans library integration
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 m...@mke3.net wrote: On Tue, Jan 17, 2012 at 6:44 AM, Campbell Barton ideasma...@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 m...@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@gmail.com wrote: Revision: 43428 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=43428 Author: nazgul Date: 2012-01-16 16:46:00 + (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
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [43428] trunk/blender: Carve booleans library integration
Am 16.01.2012 17:46, schrieb Sergey Sharybin: Revision: 43428 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=43428 Author: nazgul Date: 2012-01-16 16:46:00 + (Mon, 16 Jan 2012) Log Message: --- Carve booleans library integration == Merging Carve library integration project into the trunk. Hey Sergey, some of my work always was only (in Production constraints) possible with booleans (so I followed the carve branch closely). Imagine a jawbone I need to cut along a plane (ok Cube) and then visualize the drilling of a hole into it with a medical drill. So I am very happy with a boolean that is more robust. Some first tests showed that there are much (if any!) artifacts. However I had to learn that my old scenes are often need to be redone, thats because I used many times tricks to get the old booleans working at all... For example I made a planar cut then in this mesh the drilling difference modifier borked and I need to separate the cutted plane and then use the difference on this. This worked with the old booleans, this kind of open objects do not work anymore. But this is in most cases ok, if not I can still use a solidify mod. So thanks for this great addition to Blender! Is it the third boolean code or the fourth? ;-) Carsten -- Carsten Wartmann: Autor - Dozent - 3D - Grafik Homepage: http://blenderbuch.de/ Das Blender-Buch: http://blenderbuch.de/redirect.html ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [43428] trunk/blender: Carve booleans library integration
Hi, Well, if you'll provide some files where you think new booleans fails when they shouldn't it might help a lot. Me or Tobias (Carve's author) can try to improve something. On Tue, Jan 17, 2012 at 10:26 PM, Carsten Wartmann c...@blenderbuch.dewrote: Am 16.01.2012 17:46, schrieb Sergey Sharybin: Revision: 43428 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=43428 Author: nazgul Date: 2012-01-16 16:46:00 + (Mon, 16 Jan 2012) Log Message: --- Carve booleans library integration == Merging Carve library integration project into the trunk. Hey Sergey, some of my work always was only (in Production constraints) possible with booleans (so I followed the carve branch closely). Imagine a jawbone I need to cut along a plane (ok Cube) and then visualize the drilling of a hole into it with a medical drill. So I am very happy with a boolean that is more robust. Some first tests showed that there are much (if any!) artifacts. However I had to learn that my old scenes are often need to be redone, thats because I used many times tricks to get the old booleans working at all... For example I made a planar cut then in this mesh the drilling difference modifier borked and I need to separate the cutted plane and then use the difference on this. This worked with the old booleans, this kind of open objects do not work anymore. But this is in most cases ok, if not I can still use a solidify mod. So thanks for this great addition to Blender! Is it the third boolean code or the fourth? ;-) Carsten -- Carsten Wartmann: Autor - Dozent - 3D - Grafik Homepage: http://blenderbuch.de/ Das Blender-Buch: http://blenderbuch.de/redirect.html ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [43428] trunk/blender: Carve booleans library integration
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@gmail.comwrote: Revision: 43428 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=43428 Author: nazgul Date: 2012-01-16 16:46:00 + (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@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [43428] trunk/blender: Carve booleans library integration
Hi, I can't see why this second option might be useful atm. Restrictions described on wiki page seems to be reasonable. Probably it might be improved but it's not obvious for me hot it should behave when intersection isn't a closed loop. In other cases Carve made really good job and i'd rather improve Carve itself then add option to choose library to use (one of which isn't maintaining and where we can't give exact explanation when Carve or boolop should be used). On Tue, Jan 17, 2012 at 12:44 PM, Campbell Barton ideasma...@gmail.comwrote: Keeping the old code around as a compile option for testing IMHO is good so we can easily test any regression reports for a while (1-4 months). However booleans is the sort of feature where you want to have one good implementation, having a `good` and another `crappy-but-might-work-in-some-cases` option is weak IMHO. I'd want to see really good evidence that this is needed before having an 2 optional backends. 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. - Campbell On Tue, Jan 17, 2012 at 4:42 PM, Matt Ebb m...@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@gmail.com wrote: Revision: 43428 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=43428 Author: nazgul Date: 2012-01-16 16:46:00 + (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@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [43428] trunk/blender: Carve booleans library integration
On Tue, Jan 17, 2012 at 6:44 AM, Campbell Barton ideasma...@gmail.comwrote: 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 m...@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@gmail.com wrote: Revision: 43428 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=43428 Author: nazgul Date: 2012-01-16 16:46:00 + (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@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
