[Bf-committers] BMesh operator questions
ideasman42 at gmail.com
Wed Mar 21 12:58:14 CET 2012
On Wed, Mar 21, 2012 at 8:51 PM, Nicholas Bishop
<nicholasbishop at gmail.com> wrote:
> Thanks for the info :)
> A couple more questions:
> 1. Is it safe to modify a set being iterated over with BM_ITER? E.g.
> can I create or kill an edge in the middle of iterating over
Interesting, killing may in fact work - since the mempool iterator
should just skip them if it runs into them, but it could cause random
problems if it happens to kill enough to free an entire chunk in
generally I try to avoid this - and copy to an array first.
> 2. Is there an API to remove a loop from a face? Thought this would be
> easy but couldn't see how to do it other than maybe splitting a face
> and deleting the unused triangle.
This is the main way I've seen - in some cases vertex/edge collapse
may work IIRC (see commented code in BM_vert_collapse_edge).
> On Sat, Mar 17, 2012 at 7:06 AM, Howard Trickey
> <howard.trickey at gmail.com> wrote:
>> On Sat, Mar 17, 2012 at 1:10 AM, Campbell Barton <ideasman42 at gmail.com>wrote:
>>> On Sat, Mar 17, 2012 at 2:09 PM, Nicholas Bishop
>>> <nicholasbishop at gmail.com> wrote:
>>> > A couple of BMesh questions I could use some guidance on:
>>> > 1. Is it safe to hang on to element pointers after running an
>>> > operator? E.g. if I have a BMFace pointer, then run a BMesh operator
>>> > that can add faces, but never delete them, is my BMFace pointer still
>>> > guaranteed to be valid?
>>> Yes the pointers remain valid, but worth noting - the way BLI_mempool
>>> works it can add faces in free slots of existing chunks - so a face
>>> may be added *before* existing faces.
>>> The pointer will be valid but the index may change.
>>> > 2. Can operator slots of type 'buffer' be filled without using oflags
>>> > or hflags? Something akin to BMO_slot_map_insert() I guess, but for
>>> > buffers. I ask because it seems like using flags will force a lot of
>>> > operations to be linear (relative to the number of elements) where
>>> > they might otherwise be constant. E.g. maybe I already have an array
>>> > of the three edges I want to put in a buffer slot, but instead I have
>>> > to set a flag for the three edges, then internally all edges' flags
>>> > must be checked? Unless internally it is doing something to avoid
>>> > checking all edges?
>>> Its not done much (at all?) but think it would be fine to just add
>>> elements with BMO_slot_map_insert() directly, probably some parts of
>>> our code could be optimized by doing this.
>>> The bmesh operator code is not totally optimal anyway - the way it
>>> allocates flags and frees per call, and uses flags - seems like its
>>> intended for convenience more then speed.
>> But I agree with the implied sentiment that one of the goals of bmesh was
>> (I think) to add local neighbor information so that, as far as possible,
>> operations should take O(f(n)) rather than O(f(N)) where n is the size
>> of the affected and/or selected mesh and f is some reasonable function.
>> The code is far from there now, but would be good to try to get it there
>> some day, so that editing a mesh with many millions of vertices will
>> feel snappy. But it would require a bunch of work on how selections
>> and visibility information is kept and cached to make this a reality.
>>> > Thanks,
>>> > -Nicholas
>>> > _______________________________________________
>>> > 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
>> Bf-committers mailing list
>> Bf-committers at blender.org
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers