[Bf-committers] BMesh operator questions

[Nicholas Bishop]

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
BM_EDGES_OF_MESH?
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.

Thanks,
-Nicholas

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
>> 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