Hi Brecht, Thanks for breaking my dream of using CDDM and EDBM the same way! :D
Seriously, yes, now I realize EDBM needs a specific handling in most cases... Didn't noticed that modifiers never actually get such one, it is always converted first into a CDDM. So as I'd rather avoid adding any loop normal code in BMesh for now, I simply enforced this EDBM -> CDDM conversion in case the object uses loop normals. Obviously not a trunk-valid solution, but will allow me to finish the DM part of the work, before diving into bmesh one. ;) Bastien On 19/10/2013 02:18, Brecht Van Lommel wrote: > Hi Bastien, > > The problem is that we have two ways of storing customdata. For > regular Meshes each layer will be stored in its own array with size > equal to the number of elements. For BMEditMeshes each element stores > its own data from all layers in a little memory block. > > For Meshes it's quite easy to add a layer with CustomData_add_layer, > as it will just allocate the array. For BMEditMeshes this is more > complicated and would involve resizing all element memory blocks. > Calling CustomData_add_layer will not do this. For this particular > case I would also not suggest to add things that way. > > If you look at the definition of EditDerivedBMesh, you can see it has > a number of arrays like vertexCos, vertexNos, polyNos and polyCos. > That's probably the right place to add this normal layer, as an array > there, rather than storing it as a customdata layer. This may not be > ideal, but I don't know of a simpler solution at the moment. You > aren't actually allowed to modify the BMEditMesh in EditDerivedBMesh, > so you can't resize the little memory blocks for each loop (and it > would be too slow anyway). > > Brecht. > > On Fri, Oct 18, 2013 at 1:06 PM, Bastien Montagne<[email protected]> > wrote: >> Hi devs, >> >> This mail is mainly addressed to Campbell, who is our bmesh expert, but >> I think it may interest others as well? Anyway, I’m facing currently a >> bug in my loop normals work that I can’t really understand. I suspect >> I’m doing something wrong, but could not find examples in similar code >> to understand what to do, and if we do have some doc about bmesh, I >> found nothing about how CD layers are handled - looking to the code, it >> seems pretty complex (esp. the interactions between bmesh, editbmesh and >> editderivedbmesh)... :/ >> >> So, this two-lines patch (against trunk) is enough to crash Blender in >> Edit mode as soon as you add or remove geometry: >> http://www.pasteall.org/46610/diff >> >> Note that all 'array-like' layers (normal, but also sticky, mcol, >> shapekey…) crash, while all single-values (be it int or float - bweight, >> crease etc.) do not crash. Crash happens in mempool >> (BLI_mempool_alloc(), pool->free->next has aberrant values), so this is >> likely a mem overwrite, yet gcc's sanitize build does not say anything >> until the segfault. >> >> So questions are: >> 1) Is adding a CD layer this way over an EditDerivedBMesh illegal? In >> which case, how are we supposed to process? >> 2) Does anyone know if we have written doc about CD layers handling in >> the bmesh area? >> >> Regards, >> Bastien >> _______________________________________________ >> 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
