Re: [Bf-committers] Revision: 56704 compile error on MSVC
Hi Jürgen, Think Campbell fixed this in r56736. :) Bastien On 12/05/2013 18:06, Jürgen Herrmann wrote: Hi there, Revision: 56704 introduces a compile error on MSVC. 2d:\blender_src\blender\source\blender\bmesh\operators\bmo_utils.c(362): error C2220: Warnung wird als Fehler interpretiert, es wurde keine object-Datei generiert. 2d:\blender_src\blender\source\blender\bmesh\operators\bmo_utils.c(362): warning C4700: Die nicht initialisierte lokale Variable _fstack_index wurde verwendet. It seems that the definition of #define STACK_DECLARE(stack) unsigned int _##stack##_index On line 294 in BLI_utildefines.h should rather be #define STACK_DECLARE(stack) unsigned int _##stack##_index = 0 /Jürgen ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.67a proposed fixes
56597 (fix for node group user count): only needed if 56593 (setter callback on node group pointers to do sanity check) is also included. Not sure we need either of these, it's not actually a regression. 56581 (rna info for node input vector buttons to allow animation): This was not possible at all before, so not a regression either. Good to have it though. 56610 (small py fix for escaping ID name strings): suggest to include it, just to be safe. 56613 (prevent error message with reused operator settings): please include, it's not a showstopper, but very annoying and confusing to users On Mon, May 13, 2013 at 5:27 AM, Campbell Barton ideasma...@gmail.comwrote: Heres a list of (30+) revisions that I've collected for 2.67a release. Notes - Some of the changes are separated out because the authors better decide. They are listed under `maybe`. - blendix, OSX Ghost changes (fullscreen and keymap), not sure if we want to include these. ... also there are some changes to shading/nodes/compositing which I've listed under `maybe`. ... also UI fixes which could be left out but look safe. - nazgul, changes to camera tracking, probably best you pick changes to include (camera scaling fixes?). - lukastoenne, I've left out the API updates, if you think this should be included, best you collect revs. Revisions (56533 - 56738) - campbellbarton: 56539 56606 56620 56735 nazgul: 56572 maybe (camera tracking) 56632 56633 56634 56635 56636 56642 56726 blendix: 56651 56653 (56650 56663) 56668 56670 56673 56674 56682 56698 56700 56707 maybe 56655 56658 56662 56672 56676 maybe - 56575 56576 56577 56621 maybe (osx ghost) - 56601 (56683 56685 56728) lukastoenne: 56597 56611 56647 56648 56654 maybe - 56581 56593 56610 56613 dfelinto: 56605 moguri: 56639 56643 56679 56680 ton: 56688 56689 lockal: 56711 -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] select loop behavior
On Mon, May 13, 2013 at 2:12 AM, Yousef Hurfoush ba...@msn.com wrote: thanks,. Regards Yousef Harfoush ba...@msn.com Date: Sun, 12 May 2013 17:44:57 +1000 From: ideasma...@gmail.com To: bf-committers@blender.org Subject: Re: [Bf-committers] select loop behavior On Sun, May 12, 2013 at 5:21 AM, Yousef Hurfoush ba...@msn.com wrote: hi recently if you select a loop at the end of mesh that doesn't have perpendicular edges it select the whole face, see the attached image: http://www.pasteall.org/pic/show.php?id=51119 is this a bug or change of behavior? thanks Regards Yousef Harfoush ba...@msn.com Quite sure it's a bug, Ill check this week. On second inspection, This isn't a bug - See this image: http://www.pasteall.org/pic/show.php?id=51211 The way select loop works is that it detects edges of a face that have nothing connected, and treats this as a loop, then stops when other edge/faces are reached. Selecting the face and other edge are result of selection flushing and can't really be avoided. So we could have a special check for this case, but don't think its worthwhile since its not the purpose of this tool. - If you want to select an edge, use edge-select mode rather then loop select. - If selection flushing with verts is causing odd selections, use edge select mode. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.67a proposed fixes
Updated list of proposed revs to include: http://wiki.blender.org/index.php/User:Ideasman42/267a_bugfix ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] select loop behavior
This behaviour doesn't happen in 2.49b. Wouldn't this be counted as regression? Cheers, -Andy On 13/05/2013 09:25, Campbell Barton wrote: On Mon, May 13, 2013 at 2:12 AM, Yousef Hurfoush ba...@msn.com wrote: thanks,. Regards Yousef Harfoush ba...@msn.com Date: Sun, 12 May 2013 17:44:57 +1000 From: ideasma...@gmail.com To: bf-committers@blender.org Subject: Re: [Bf-committers] select loop behavior On Sun, May 12, 2013 at 5:21 AM, Yousef Hurfoush ba...@msn.com wrote: hi recently if you select a loop at the end of mesh that doesn't have perpendicular edges it select the whole face, see the attached image: http://www.pasteall.org/pic/show.php?id=51119 is this a bug or change of behavior? thanks Regards Yousef Harfoush ba...@msn.com Quite sure it's a bug, Ill check this week. On second inspection, This isn't a bug - See this image: http://www.pasteall.org/pic/show.php?id=51211 The way select loop works is that it detects edges of a face that have nothing connected, and treats this as a loop, then stops when other edge/faces are reached. Selecting the face and other edge are result of selection flushing and can't really be avoided. So we could have a special check for this case, but don't think its worthwhile since its not the purpose of this tool. - If you want to select an edge, use edge-select mode rather then loop select. - If selection flushing with verts is causing odd selections, use edge select mode. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] select loop behavior
On Mon, May 13, 2013 at 8:48 PM, metalliandy metalliandy...@googlemail.com wrote: This behaviour doesn't happen in 2.49b. Wouldn't this be counted as regression? It could, though 2.4x didn't support ngons, without this feature select all edges along an ngon wont work which IMHO is a more useful behavior then to only select a single edge. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] select loop behavior
Hmm, It really depends on what the target audience is for this I suppose. It plays havoc when doing subd work, for which ngons should only be used on flat areas that are surrounded by quad loops. How much do people select ngons in this way vs quads? On 13/05/2013 12:02, Campbell Barton wrote: On Mon, May 13, 2013 at 8:48 PM, metalliandy metalliandy...@googlemail.com wrote: This behaviour doesn't happen in 2.49b. Wouldn't this be counted as regression? It could, though 2.4x didn't support ngons, without this feature select all edges along an ngon wont work which IMHO is a more useful behavior then to only select a single edge. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] select loop behavior
On Mon, May 13, 2013 at 9:31 PM, metalliandy metalliandy...@googlemail.com wrote: Hmm, It really depends on what the target audience is for this I suppose. It plays havoc when doing subd work, for which ngons should only be used on flat areas that are surrounded by quad loops. How much do people select ngons in this way vs quads? Are you talking about the original post from Yousef? How to deal with mixes of NGons+Quads+WireEdges+BoundryEdges... is disputable and could be changed/improved. But I fail to see how a detail about the behavior of selecting the endpoint of dangling quad would cause havoc to your workflow. Can you give details as to why current behavior is so problematic? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] select loop behavior
this is something that also has annoyed me to no end when doing some strip modeling or retopology work. since i usually never leave vertex select mode it was the fastest way of selecting just the end of the poly strip. workaround... never work on a polygon strip that is just a single quad thick .. well or just select both verts manually its not that much extra work after all. From: Yousef Hurfoush ba...@msn.com To: blender foundation committers bf-committers@blender.org Sent: Saturday, May 11, 2013 9:21 PM Subject: [Bf-committers] select loop behavior hi recently if you select a loop at the end of mesh that doesn't have perpendicular edges it select the whole face, see the attached image: http://www.pasteall.org/pic/show.php?id=51119 is this a bug or change of behavior? thanks Regards Yousef Harfoush ba...@msn.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] select loop behavior
It's problematic because of the examples in the first post. If I am trying to select a loop similar to the picture in the first post then it selects the whole face, which means I have to either change to edge mode and deselect the offending edge or reselect the other verts. manually. As fredrik said, this causes workflow problems when working with single strip quads when doing things like retopo or in my case blocking out a high/lowpoly surface. Without trying to sound like a dick, I cannot imagine a real world example where any modeller who is at least relatively experienced would want to select the boundary of an ngon in the manner that you presented in your example...people just shouldn't model that way. Ngons should never be used as a boundary... only ever on flat, non deforming surfaces and only then if they are surrounded by a loop of quads. They can always inset the ngon and the problem is fixed for them. Cheers, -Andy On 13/05/2013 12:51, Campbell Barton wrote: On Mon, May 13, 2013 at 9:31 PM, metalliandy metalliandy...@googlemail.com wrote: Hmm, It really depends on what the target audience is for this I suppose. It plays havoc when doing subd work, for which ngons should only be used on flat areas that are surrounded by quad loops. How much do people select ngons in this way vs quads? Are you talking about the original post from Yousef? How to deal with mixes of NGons+Quads+WireEdges+BoundryEdges... is disputable and could be changed/improved. But I fail to see how a detail about the behavior of selecting the endpoint of dangling quad would cause havoc to your workflow. Can you give details as to why current behavior is so problematic? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] select loop behavior
although it's not a killer but annoyingly enough change, i could model without it, or select in edge mode, but surely it slows down the workflow, thanks anyway :) Regards Yousef Harfoush ba...@msn.com Date: Mon, 13 May 2013 13:15:17 +0100 From: metalliandy...@googlemail.com To: bf-committers@blender.org Subject: Re: [Bf-committers] select loop behavior It's problematic because of the examples in the first post. If I am trying to select a loop similar to the picture in the first post then it selects the whole face, which means I have to either change to edge mode and deselect the offending edge or reselect the other verts. manually. As fredrik said, this causes workflow problems when working with single strip quads when doing things like retopo or in my case blocking out a high/lowpoly surface. Without trying to sound like a dick, I cannot imagine a real world example where any modeller who is at least relatively experienced would want to select the boundary of an ngon in the manner that you presented in your example...people just shouldn't model that way. Ngons should never be used as a boundary... only ever on flat, non deforming surfaces and only then if they are surrounded by a loop of quads. They can always inset the ngon and the problem is fixed for them. Cheers, -Andy On 13/05/2013 12:51, Campbell Barton wrote: On Mon, May 13, 2013 at 9:31 PM, metalliandy metalliandy...@googlemail.com wrote: Hmm, It really depends on what the target audience is for this I suppose. It plays havoc when doing subd work, for which ngons should only be used on flat areas that are surrounded by quad loops. How much do people select ngons in this way vs quads? Are you talking about the original post from Yousef? How to deal with mixes of NGons+Quads+WireEdges+BoundryEdges... is disputable and could be changed/improved. But I fail to see how a detail about the behavior of selecting the endpoint of dangling quad would cause havoc to your workflow. Can you give details as to why current behavior is so problematic? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cycles performance on Windows
Hi Jürgen, You've been added now, and should have a welcome mail in your inbox. Thanks! -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 11 May, 2013, at 19:38, Jürgen Herrmann wrote: Hi Ton, I would be proud to be a part of the blender team. I actually had some patches in the Patch tracker that were committed by Brecht. He should be able to judge about their quality. Look here: http://projects.blender.org/tracker/?func=detailatid=127aid=35158 http://projects.blender.org/tracker/?func=detailatid=127aid=35131 http://projects.blender.org/tracker/?func=detailatid=127aid=35234 http://projects.blender.org/tracker/?func=detailatid=127aid=35019 http://projects.blender.org/tracker/index.php?func=detailaid=35153 I have a full set of x64 prerequisite libs freshly compiled and I am currently working on compiling the x86 libs. I've also extended the CMakeFiles to include the new libs and compiler settings. I always doublecheck all changes with VC2008 so I don't break compatibility. /Jürgen. -Ursprüngliche Nachricht- Von: bf-committers-boun...@blender.org [mailto:bf-committers-boun...@blender.org] Im Auftrag von Ton Roosendaal Gesendet: Samstag, 11. Mai 2013 18:43 An: bf-blender developers Betreff: Re: [Bf-committers] Cycles performance on Windows Hi Jurgen, You're very welcome to join the windows platform team as maintainer for MSVC 2012. Did you already have patches we should apply? We typically give people commit access after a couple of good patches. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 10 May, 2013, at 22:02, Jürgen Herrmann wrote: This sounds reasonable. So we need a lightning fast math library replacement for MS compilers... I'm just kidding, but the idea might be insane enough to try ;) I am very satisfied with the speed improvement that MSVC 2012 has brought to blender. I would love to see this in the wild. It could make some people very happy. I would volunteer to maintain this build platform if desired. /Jürgen Am 10.05.2013 um 20:17 schrieb Antony Riakiotakis kal...@gmail.com: According to the MinGW64 developers, the math library implementation is faster for gcc. The simulations use openmp which is disabled in MinGW64 due to their buggy pthread implementation which makes openmp hang when used during pthread execution. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] select loop behavior
+1 on finding this behaviour annoying. Since this behaviour was implemented with an N-gon use-case in mind, would it be possible/ make sense to have the behaviour vary depending on whether or not the selected edge belongs to an N-gon or not? Right now though, even for the N-gon purpose though it seems slightly unintuitive to me. Maybe I'm just over-thinking it now, but here's screenshot to help me explain: http://www.pasteall.org/pic/show.php?id=51228 I marked click positions that cause the selection shown orange. The red marks in the third picture show what I would expect to contribute to this selection, but don't currently. I would love to see the old behaviour back for quads and the new one used for Ngons only to allow easy selection. Again, I may just be over-thinking it (heck, and I hardly use N-gons, so power users in that regard may have a different idea on this) and it's potentially a very subjective preference, but just thought I'd chime in. Cheers, Patrick From: ba...@msn.com To: bf-committers@blender.org Date: Mon, 13 May 2013 14:31:02 + Subject: Re: [Bf-committers] select loop behavior although it's not a killer but annoyingly enough change, i could model without it, or select in edge mode, but surely it slows down the workflow, thanks anyway :) Regards Yousef Harfoush ba...@msn.com Date: Mon, 13 May 2013 13:15:17 +0100 From: metalliandy...@googlemail.com To: bf-committers@blender.org Subject: Re: [Bf-committers] select loop behavior It's problematic because of the examples in the first post. If I am trying to select a loop similar to the picture in the first post then it selects the whole face, which means I have to either change to edge mode and deselect the offending edge or reselect the other verts. manually. As fredrik said, this causes workflow problems when working with single strip quads when doing things like retopo or in my case blocking out a high/lowpoly surface. Without trying to sound like a dick, I cannot imagine a real world example where any modeller who is at least relatively experienced would want to select the boundary of an ngon in the manner that you presented in your example...people just shouldn't model that way. Ngons should never be used as a boundary... only ever on flat, non deforming surfaces and only then if they are surrounded by a loop of quads. They can always inset the ngon and the problem is fixed for them. Cheers, -Andy On 13/05/2013 12:51, Campbell Barton wrote: On Mon, May 13, 2013 at 9:31 PM, metalliandy metalliandy...@googlemail.com wrote: Hmm, It really depends on what the target audience is for this I suppose. It plays havoc when doing subd work, for which ngons should only be used on flat areas that are surrounded by quad loops. How much do people select ngons in this way vs quads? Are you talking about the original post from Yousef? How to deal with mixes of NGons+Quads+WireEdges+BoundryEdges... is disputable and could be changed/improved. But I fail to see how a detail about the behavior of selecting the endpoint of dangling quad would cause havoc to your workflow. Can you give details as to why current behavior is so problematic? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cycles performance on Windows
Hi Ton, Just got it ;-) Thank you very much! I'll read the rules completely first, promised :-D Thanks Jürgen Am 13.05.2013 um 18:00 schrieb Ton Roosendaal t...@blender.org: Hi Jürgen, You've been added now, and should have a welcome mail in your inbox. Thanks! -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 11 May, 2013, at 19:38, Jürgen Herrmann wrote: Hi Ton, I would be proud to be a part of the blender team. I actually had some patches in the Patch tracker that were committed by Brecht. He should be able to judge about their quality. Look here: http://projects.blender.org/tracker/?func=detailatid=127aid=35158 http://projects.blender.org/tracker/?func=detailatid=127aid=35131 http://projects.blender.org/tracker/?func=detailatid=127aid=35234 http://projects.blender.org/tracker/?func=detailatid=127aid=35019 http://projects.blender.org/tracker/index.php?func=detailaid=35153 I have a full set of x64 prerequisite libs freshly compiled and I am currently working on compiling the x86 libs. I've also extended the CMakeFiles to include the new libs and compiler settings. I always doublecheck all changes with VC2008 so I don't break compatibility. /Jürgen. -Ursprüngliche Nachricht- Von: bf-committers-boun...@blender.org [mailto:bf-committers-boun...@blender.org] Im Auftrag von Ton Roosendaal Gesendet: Samstag, 11. Mai 2013 18:43 An: bf-blender developers Betreff: Re: [Bf-committers] Cycles performance on Windows Hi Jurgen, You're very welcome to join the windows platform team as maintainer for MSVC 2012. Did you already have patches we should apply? We typically give people commit access after a couple of good patches. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 10 May, 2013, at 22:02, Jürgen Herrmann wrote: This sounds reasonable. So we need a lightning fast math library replacement for MS compilers... I'm just kidding, but the idea might be insane enough to try ;) I am very satisfied with the speed improvement that MSVC 2012 has brought to blender. I would love to see this in the wild. It could make some people very happy. I would volunteer to maintain this build platform if desired. /Jürgen Am 10.05.2013 um 20:17 schrieb Antony Riakiotakis kal...@gmail.com: According to the MinGW64 developers, the math library implementation is faster for gcc. The simulations use openmp which is disabled in MinGW64 due to their buggy pthread implementation which makes openmp hang when used during pthread execution. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] select loop behavior
While checking on these issues I found some other odd behavior with ngons (simple case fixed r56773). Id like to try address the issues posted, but more in the context of getting predictable results rather then just adding quick hack for this one case work as it did in 2.4x. On Tue, May 14, 2013 at 2:41 AM, patrick boelens p_boel...@msn.com wrote: +1 on finding this behaviour annoying. Since this behaviour was implemented with an N-gon use-case in mind, would it be possible/ make sense to have the behaviour vary depending on whether or not the selected edge belongs to an N-gon or not? Right now though, even for the N-gon purpose though it seems slightly unintuitive to me. Maybe I'm just over-thinking it now, but here's screenshot to help me explain: http://www.pasteall.org/pic/show.php?id=51228 I marked click positions that cause the selection shown orange. The red marks in the third picture show what I would expect to contribute to this selection, but don't currently. I would love to see the old behaviour back for quads and the new one used for Ngons only to allow easy selection. Again, I may just be over-thinking it (heck, and I hardly use N-gons, so power users in that regard may have a different idea on this) and it's potentially a very subjective preference, but just thought I'd chime in. Cheers, Patrick From: ba...@msn.com To: bf-committers@blender.org Date: Mon, 13 May 2013 14:31:02 + Subject: Re: [Bf-committers] select loop behavior although it's not a killer but annoyingly enough change, i could model without it, or select in edge mode, but surely it slows down the workflow, thanks anyway :) Regards Yousef Harfoush ba...@msn.com Date: Mon, 13 May 2013 13:15:17 +0100 From: metalliandy...@googlemail.com To: bf-committers@blender.org Subject: Re: [Bf-committers] select loop behavior It's problematic because of the examples in the first post. If I am trying to select a loop similar to the picture in the first post then it selects the whole face, which means I have to either change to edge mode and deselect the offending edge or reselect the other verts. manually. As fredrik said, this causes workflow problems when working with single strip quads when doing things like retopo or in my case blocking out a high/lowpoly surface. Without trying to sound like a dick, I cannot imagine a real world example where any modeller who is at least relatively experienced would want to select the boundary of an ngon in the manner that you presented in your example...people just shouldn't model that way. Ngons should never be used as a boundary... only ever on flat, non deforming surfaces and only then if they are surrounded by a loop of quads. They can always inset the ngon and the problem is fixed for them. Cheers, -Andy On 13/05/2013 12:51, Campbell Barton wrote: On Mon, May 13, 2013 at 9:31 PM, metalliandy metalliandy...@googlemail.com wrote: Hmm, It really depends on what the target audience is for this I suppose. It plays havoc when doing subd work, for which ngons should only be used on flat areas that are surrounded by quad loops. How much do people select ngons in this way vs quads? Are you talking about the original post from Yousef? How to deal with mixes of NGons+Quads+WireEdges+BoundryEdges... is disputable and could be changed/improved. But I fail to see how a detail about the behavior of selecting the endpoint of dangling quad would cause havoc to your workflow. Can you give details as to why current behavior is so problematic? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ 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
Re: [Bf-committers] Cycles performance on Windows
Congratulations, Jürgen! Gavin H. On Mon, May 13, 2013 at 12:20 PM, Jürgen Herrmann shadow...@me.com wrote: Hi Ton, Just got it ;-) Thank you very much! I'll read the rules completely first, promised :-D Thanks Jürgen Am 13.05.2013 um 18:00 schrieb Ton Roosendaal t...@blender.org: Hi Jürgen, You've been added now, and should have a welcome mail in your inbox. Thanks! -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 11 May, 2013, at 19:38, Jürgen Herrmann wrote: Hi Ton, I would be proud to be a part of the blender team. I actually had some patches in the Patch tracker that were committed by Brecht. He should be able to judge about their quality. Look here: http://projects.blender.org/tracker/?func=detailatid=127aid=35158 http://projects.blender.org/tracker/?func=detailatid=127aid=35131 http://projects.blender.org/tracker/?func=detailatid=127aid=35234 http://projects.blender.org/tracker/?func=detailatid=127aid=35019 http://projects.blender.org/tracker/index.php?func=detailaid=35153 I have a full set of x64 prerequisite libs freshly compiled and I am currently working on compiling the x86 libs. I've also extended the CMakeFiles to include the new libs and compiler settings. I always doublecheck all changes with VC2008 so I don't break compatibility. /Jürgen. -Ursprüngliche Nachricht- Von: bf-committers-boun...@blender.org [mailto:bf-committers-boun...@blender.org] Im Auftrag von Ton Roosendaal Gesendet: Samstag, 11. Mai 2013 18:43 An: bf-blender developers Betreff: Re: [Bf-committers] Cycles performance on Windows Hi Jurgen, You're very welcome to join the windows platform team as maintainer for MSVC 2012. Did you already have patches we should apply? We typically give people commit access after a couple of good patches. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 10 May, 2013, at 22:02, Jürgen Herrmann wrote: This sounds reasonable. So we need a lightning fast math library replacement for MS compilers... I'm just kidding, but the idea might be insane enough to try ;) I am very satisfied with the speed improvement that MSVC 2012 has brought to blender. I would love to see this in the wild. It could make some people very happy. I would volunteer to maintain this build platform if desired. /Jürgen Am 10.05.2013 um 20:17 schrieb Antony Riakiotakis kal...@gmail.com: According to the MinGW64 developers, the math library implementation is faster for gcc. The simulations use openmp which is disabled in MinGW64 due to their buggy pthread implementation which makes openmp hang when used during pthread execution. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Ready for first commit?!
Low free space might be a problem, but these libs still belong in our official svn I think. We can keep using visual studio 2008 forever. How big are the libraries? Also, can you show a patch for the CMakeLists changes? Thanks, Brecht. On Mon, May 13, 2013 at 11:01 PM, Alexandr Kuznetsov kuzsa...@gmail.com wrote: Hi. Blender svn server had low free space left. Also, blender svn is very slooow for libs. I think it is better to host them on separate svn like google code or sourceforge. On, the other hand, cmake/scons changes are always welcome! Make sure they for vc11. Btw, congratulations and welcome to the team. Best, Alex On 5/13/2013 3:51 PM, Jürgen Herrmann wrote: Hi ;-) I would like to do my first commit tomorrow. It will be a huge one. I'd like to upload the prerequisite libs for vs2012 and a little patch to CMakeLists. For the libs I wanted to put them in trunk/lib/windows_vc11 and trunk/lib/windows/win64_vc11 So I don't break the original vc2008 libs Is that ok? The CMake patch adds the appropriate paths. Best regards Jürgen ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Ready for first commit?!
Hi Brecht and Alex, thanks for the warm welcome ;) the libs have 3.25 GB in sum (both platforms). I can strip out the debug libs to save some space, as they are not needed for release builds of blender, will do that tomorrow. I'll post the patch here when it's done. There are some hacks in there I have done and I want it to be nice and neat. I am still learning scons right now, so that patch will take me 1-2 days to complete. /Jürgen -Ursprüngliche Nachricht- Von: bf-committers-boun...@blender.org [mailto:bf-committers-boun...@blender.org] Im Auftrag von Brecht Van Lommel Gesendet: Montag, 13. Mai 2013 23:24 An: bf-blender developers Betreff: Re: [Bf-committers] Ready for first commit?! Low free space might be a problem, but these libs still belong in our official svn I think. We can keep using visual studio 2008 forever. How big are the libraries? Also, can you show a patch for the CMakeLists changes? Thanks, Brecht. On Mon, May 13, 2013 at 11:01 PM, Alexandr Kuznetsov kuzsa...@gmail.com wrote: Hi. Blender svn server had low free space left. Also, blender svn is very slooow for libs. I think it is better to host them on separate svn like google code or sourceforge. On, the other hand, cmake/scons changes are always welcome! Make sure they for vc11. Btw, congratulations and welcome to the team. Best, Alex On 5/13/2013 3:51 PM, Jürgen Herrmann wrote: Hi ;-) I would like to do my first commit tomorrow. It will be a huge one. I'd like to upload the prerequisite libs for vs2012 and a little patch to CMakeLists. For the libs I wanted to put them in trunk/lib/windows_vc11 and trunk/lib/windows/win64_vc11 So I don't break the original vc2008 libs Is that ok? The CMake patch adds the appropriate paths. Best regards Jürgen ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] debug libraries for vs-2011/2012 (was: Ready for first commit?!)
Hi; Would it be still possible to build a debug version of Blender even when the debug libraries are not present ? In that case, is there a description how the debug libraries can be built ? Or even more general, maybe it is possible to setup a cmake file separately from the Blender cmake, which just builds the libraries on windows, so that everybody can create them easily? cheers, Gaia On 13.05.2013 23:33, Jürgen Herrmann wrote: Hi Brecht and Alex, thanks for the warm welcome ;) the libs have 3.25 GB in sum (both platforms). I can strip out the debug libs to save some space, as they are not needed for release builds of blender, will do that tomorrow. I'll post the patch here when it's done. There are some hacks in there I have done and I want it to be nice and neat. I am still learning scons right now, so that patch will take me 1-2 days to complete. /Jürgen -Ursprüngliche Nachricht- Von: bf-committers-boun...@blender.org [mailto:bf-committers-boun...@blender.org] Im Auftrag von Brecht Van Lommel Gesendet: Montag, 13. Mai 2013 23:24 An: bf-blender developers Betreff: Re: [Bf-committers] Ready for first commit?! Low free space might be a problem, but these libs still belong in our official svn I think. We can keep using visual studio 2008 forever. How big are the libraries? Also, can you show a patch for the CMakeLists changes? Thanks, Brecht. On Mon, May 13, 2013 at 11:01 PM, Alexandr Kuznetsov kuzsa...@gmail.com wrote: Hi. Blender svn server had low free space left. Also, blender svn is very slooow for libs. I think it is better to host them on separate svn like google code or sourceforge. On, the other hand, cmake/scons changes are always welcome! Make sure they for vc11. Btw, congratulations and welcome to the team. Best, Alex On 5/13/2013 3:51 PM, Jürgen Herrmann wrote: Hi ;-) I would like to do my first commit tomorrow. It will be a huge one. I'd like to upload the prerequisite libs for vs2012 and a little patch to CMakeLists. For the libs I wanted to put them in trunk/lib/windows_vc11 and trunk/lib/windows/win64_vc11 So I don't break the original vc2008 libs Is that ok? The CMake patch adds the appropriate paths. Best regards Jürgen ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender cannot compile without libmv (CMake)
I build Blender without libmv, but a recent commit broke this: lib/libbf_blenkernel.a(tracking.c.o): In function `BKE_tracking_distortion_update': /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1575: undefined reference to `libmv_CameraIntrinsicsUpdate' lib/libbf_blenkernel.a(tracking.c.o): In function `BKE_tracking_distortion_copy': /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1589: undefined reference to `libmv_CameraIntrinsicsCopy' lib/libbf_blenkernel.a(tracking.c.o): In function `BKE_tracking_distortion_exec': /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1605: undefined reference to `libmv_CameraIntrinsicsUndistortFloat' /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1610: undefined reference to `libmv_CameraIntrinsicsDistortFloat' /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1620: undefined reference to `libmv_CameraIntrinsicsUndistortByte' /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1625: undefined reference to `libmv_CameraIntrinsicsDistortByte' lib/libbf_blenkernel.a(tracking.c.o): In function `BKE_tracking_distort_v2': /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1655: undefined reference to `libmv_ApplyCameraIntrinsics' lib/libbf_blenkernel.a(tracking.c.o): In function `BKE_tracking_undistort_v2': /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1672: undefined reference to `libmv_InvertCameraIntrinsics' lib/libbf_blenkernel.a(tracking.c.o): In function `reconstruct_retrieve_libmv_intrinscis': /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:2932: undefined reference to `libmv_CameraIntrinsicsExtract' lib/libbf_blenkernel.a(tracking.c.o): In function `reconstruct_retrieve_libmv_tracks': /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:2979: undefined reference to `libmv_reporojectionPointForTrack' /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:2985: undefined reference to `libmv_reporojectionErrorForTrack' /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3009: undefined reference to `libmv_reporojectionCameraForImage' /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3012: undefined reference to `libmv_reporojectionErrorForImage' lib/libbf_blenkernel.a(tracking.c.o): In function `BKE_tracking_reconstruction_solve': /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3310: undefined reference to `libmv_solveModal' /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3316: undefined reference to `libmv_solveReconstruction' /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3322: undefined reference to `libmv_reprojectionError' lib/libbf_blenkernel.a(tracking.c.o): In function `detect_retrieve_libmv_features': /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3459: undefined reference to `libmv_countFeatures' /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3466: undefined reference to `libmv_getFeature' lib/libbf_blenkernel.a(tracking.c.o): In function `BKE_tracking_detect_fast': /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3523: undefined reference to `libmv_detectFeaturesFAST' collect2: error: ld returned 1 exit status ninja: build stopped: subcommand failed. I didn't see Sergey on the IRC, so I decided to post this here instead. --Mitchell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender cannot compile without libmv (CMake)
On Tue, May 14, 2013 at 10:13 AM, Mitchell Stokes moguri...@gmail.com wrote: I build Blender without libmv, but a recent commit broke this: lib/libbf_blenkernel.a(tracking.c.o): In function `BKE_tracking_distortion_update': /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1575: undefined reference to `libmv_CameraIntrinsicsUpdate' lib/libbf_blenkernel.a(tracking.c.o): In function `BKE_tracking_distortion_copy': /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1589: undefined reference to `libmv_CameraIntrinsicsCopy' lib/libbf_blenkernel.a(tracking.c.o): In function `BKE_tracking_distortion_exec': /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1605: undefined reference to `libmv_CameraIntrinsicsUndistortFloat' /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1610: undefined reference to `libmv_CameraIntrinsicsDistortFloat' /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1620: undefined reference to `libmv_CameraIntrinsicsUndistortByte' /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1625: undefined reference to `libmv_CameraIntrinsicsDistortByte' lib/libbf_blenkernel.a(tracking.c.o): In function `BKE_tracking_distort_v2': /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1655: undefined reference to `libmv_ApplyCameraIntrinsics' lib/libbf_blenkernel.a(tracking.c.o): In function `BKE_tracking_undistort_v2': /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1672: undefined reference to `libmv_InvertCameraIntrinsics' lib/libbf_blenkernel.a(tracking.c.o): In function `reconstruct_retrieve_libmv_intrinscis': /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:2932: undefined reference to `libmv_CameraIntrinsicsExtract' lib/libbf_blenkernel.a(tracking.c.o): In function `reconstruct_retrieve_libmv_tracks': /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:2979: undefined reference to `libmv_reporojectionPointForTrack' /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:2985: undefined reference to `libmv_reporojectionErrorForTrack' /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3009: undefined reference to `libmv_reporojectionCameraForImage' /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3012: undefined reference to `libmv_reporojectionErrorForImage' lib/libbf_blenkernel.a(tracking.c.o): In function `BKE_tracking_reconstruction_solve': /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3310: undefined reference to `libmv_solveModal' /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3316: undefined reference to `libmv_solveReconstruction' /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3322: undefined reference to `libmv_reprojectionError' lib/libbf_blenkernel.a(tracking.c.o): In function `detect_retrieve_libmv_features': /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3459: undefined reference to `libmv_countFeatures' /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3466: undefined reference to `libmv_getFeature' lib/libbf_blenkernel.a(tracking.c.o): In function `BKE_tracking_detect_fast': /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3523: undefined reference to `libmv_detectFeaturesFAST' collect2: error: ld returned 1 exit status ninja: build stopped: subcommand failed. I didn't see Sergey on the IRC, so I decided to post this here instead. --Mitchell Working again r56782. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] select loop behavior
@Mikhail, yep, we'll definitely keep the ability to select ngons sides as loops. Applied a fix for loop select r56784. This also improves on an annoyance I found with ngons connected to quad-loops, see before after. http://www.graphicall.org/ftp/ideasman42/edgeloop_select_fix.png On Tue, May 14, 2013 at 7:44 AM, Mikhail Rachinskiy mira...@ya.ru wrote: Just another point of view: altho is a bit annoying but select a loop around Ngon is more useful than select one edge. -- Mikhail Rachinskiy ___ 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
Re: [Bf-committers] debug libraries for vs-2011/2012 (was: Ready for first commit?!)
Hi Gaia, You won't be able to build a debug binary without the debug libs. But I can provide full documentation on how to build them, see here http://shadowrom.de/?page_id=73 ;) I think a CMake file could be done in theory but not with my knowledge of CMake ;) Bet regards Jürgen Am 13.05.2013 um 23:48 schrieb Gaia gaia.cl...@machinimatrix.org: Hi; Would it be still possible to build a debug version of Blender even when the debug libraries are not present ? In that case, is there a description how the debug libraries can be built ? Or even more general, maybe it is possible to setup a cmake file separately from the Blender cmake, which just builds the libraries on windows, so that everybody can create them easily? cheers, Gaia On 13.05.2013 23:33, Jürgen Herrmann wrote: Hi Brecht and Alex, thanks for the warm welcome ;) the libs have 3.25 GB in sum (both platforms). I can strip out the debug libs to save some space, as they are not needed for release builds of blender, will do that tomorrow. I'll post the patch here when it's done. There are some hacks in there I have done and I want it to be nice and neat. I am still learning scons right now, so that patch will take me 1-2 days to complete. /Jürgen -Ursprüngliche Nachricht- Von: bf-committers-boun...@blender.org [mailto:bf-committers-boun...@blender.org] Im Auftrag von Brecht Van Lommel Gesendet: Montag, 13. Mai 2013 23:24 An: bf-blender developers Betreff: Re: [Bf-committers] Ready for first commit?! Low free space might be a problem, but these libs still belong in our official svn I think. We can keep using visual studio 2008 forever. How big are the libraries? Also, can you show a patch for the CMakeLists changes? Thanks, Brecht. On Mon, May 13, 2013 at 11:01 PM, Alexandr Kuznetsov kuzsa...@gmail.com wrote: Hi. Blender svn server had low free space left. Also, blender svn is very slooow for libs. I think it is better to host them on separate svn like google code or sourceforge. On, the other hand, cmake/scons changes are always welcome! Make sure they for vc11. Btw, congratulations and welcome to the team. Best, Alex On 5/13/2013 3:51 PM, Jürgen Herrmann wrote: Hi ;-) I would like to do my first commit tomorrow. It will be a huge one. I'd like to upload the prerequisite libs for vs2012 and a little patch to CMakeLists. For the libs I wanted to put them in trunk/lib/windows_vc11 and trunk/lib/windows/win64_vc11 So I don't break the original vc2008 libs Is that ok? The CMake patch adds the appropriate paths. Best regards Jürgen ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ 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 [56784] trunk/blender/source/blender/bmesh /intern/bmesh_walkers_impl.c: fix for problem where edge loop select would select too m
Thanks so much for this fix!
Jonathan Williamson
http://cgcookie.com
On Mon, May 13, 2013 at 10:10 PM, Jonathan Williamson
jonat...@montagestudio.org wrote:
Thanks so much for this fix!
Jonathan Williamson
http://cgcookie.com
On Mon, May 13, 2013 at 9:55 PM, Campbell Barton ideasma...@gmail.comwrote:
Revision: 56784
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=56784
Author: campbellbarton
Date: 2013-05-14 04:55:21 + (Tue, 14 May 2013)
Log Message:
---
fix for problem where edge loop select would select too many vertices
(extend selection too far),
before after:
http://www.graphicall.org/ftp/ideasman42/edgeloop_select_fix.png
Modified Paths:
--
trunk/blender/source/blender/bmesh/intern/bmesh_walkers_impl.c
Modified: trunk/blender/source/blender/bmesh/intern/bmesh_walkers_impl.c
===
--- trunk/blender/source/blender/bmesh/intern/bmesh_walkers_impl.c
2013-05-14 04:09:02 UTC (rev 56783)
+++ trunk/blender/source/blender/bmesh/intern/bmesh_walkers_impl.c
2013-05-14 04:55:21 UTC (rev 56784)
@@ -428,6 +428,15 @@
*
* Starts at a tool-flagged edge and walks over the edge loop
*/
+
+/* utility function */
+static bool bm_loop_is_single(BMLoop *l)
+{
+ return ((BM_edge_is_boundary(l-e))
+ (l-f-len != 4)
+ (BM_edge_is_boundary(l-next-e) ||
BM_edge_is_boundary(l-prev-e)));
+}
+
static void bmw_LoopWalker_begin(BMWalker *walker, void *data)
{
BMwLoopWalker *lwalk = NULL, owalk, *owalk_pt;
@@ -444,7 +453,7 @@
lwalk-cur = lwalk-start = e;
lwalk-lastv = lwalk-startv = v;
lwalk-is_boundary = BM_edge_is_boundary(e);
- lwalk-is_single = (vert_edge_count[0] == 2 vert_edge_count[1]
== 2);
+ lwalk-is_single = (lwalk-is_boundary
bm_loop_is_single(e-l));
/* could also check that vertex*/
if ((lwalk-is_boundary == false)
@@ -639,6 +648,10 @@
} while (true);
}
+ if (owalk.is_single == false bm_loop_is_single(l)) {
+ l = NULL;
+ }
+
if (l != NULL) {
if (l != e-l
bmw_mask_check_edge(walker, l-e)
___
Bf-blender-cvs mailing list
bf-blender-...@blender.org
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
