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 <[email protected]> wrote: > On Sat, Mar 17, 2012 at 1:10 AM, Campbell Barton <[email protected]>wrote: > >> On Sat, Mar 17, 2012 at 2:09 PM, Nicholas Bishop >> <[email protected]> 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 >> > [email protected] >> > http://lists.blender.org/mailman/listinfo/bf-committers >> >> >> >> -- >> - Campbell >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
